I don't think the devs are up to redo all their years of work.Of course. But GML is horrible
I don't think the devs are up to redo all their years of work.minus beta testing, map making, tweaks, bugfixes and fapping, it wouldn't take more than a week.
Why is gml so horrible? It's easy to understand, almost as reading a normal text.Sure, so are other languages.
I guess it depends where we would like to go with it.C#. Or Python. Or Java. Or Ruby or Lua or something. But NOT C++. No.
I feel like Java would be our best bet, since we can easily port it to other platforms, but C++ probably has good points.
You can't just ask everyone to PLZ REWRITE GAME TO BE BETTER, KTHXBAI, most of the developers have lives of their own and development is compulsiveI'm not asking. I want to do it, meh.
What's wrong with a C++ port?
You're thinking with too direct of a port, we don't need to create specific functions to mirror the convenience of GML.I know I don't need to create GML analogous functions. But it might help.
You're welcome to try, you don't need permission, if you get a good project going, other people may be able to hop on board and help
Most people on the development team (read: not me) have experience in other programming languages, as for the community---Python syntax is not very hard to learn. The big difference with python syntax is whitespace denotes code blocks (no {}), e.g.:
That does sound interesting and useful, don't know a thing about python syntax though
if x == 2:
print ("stuff")
if y == 3:
print ("more stuff")
else:
print ("other stuff")eh, gtg now. will discuss more later/actually do something
I understand. I think, for that reason, if I do this, I should plan it out thoroughly in advance.
Also, set a list of goals. For instance, my personal first goal is "working client and server where player can join as red querly and move around, visible to other players". That alone requires quite a bit of code, but is the important first step.
Meh. If I can get there in a not-too-long period of thime, this yet-another-rewrite project might go somewhere.
Python is both development-friendly and beneficial. Java is neither.I understand. I think, for that reason, if I do this, I should plan it out thoroughly in advance.
Also, set a list of goals. For instance, my personal first goal is "working client and server where player can join as red querly and move around, visible to other players". That alone requires quite a bit of code, but is the important first step.
Meh. If I can get there in a not-too-long period of thime, this yet-another-rewrite project might go somewhere.
Start with the server, it would be easiest to test and if you ever decide to give up, you're still left with a functioning non-gml server :D
What reason do you want to use python for? Of course any language is probably better than gm, but I would think we would want to choose a language that is both development-friendly and also beneficial. Other than being faster, Python doesn't have much over what we have now.
I think we should use Pygame.That's my thoughts too.
Python is both development-friendly and beneficial. Java is neither.
Python has very concise and powerful, easily human-readable syntax. It also has great cross-platform compatibility.Python is both development-friendly and beneficial. Java is neither.
Way to elaborate/ not answer the question.
Java works well cross platform, how is that not beneficial? Its syntax is much more legible than Python as well.
dict = { "a": 1, "b": 2 }
for key, value in dict.items():
print(key, value)
if key == "a":
print("Look mom, no braces!")vsDictionary dict = new Dictionary();
dict.put("a", 1);
dict.put("b", 2);
for (Enumeration e = dict.keys() ; e.hasMoreElements() ;) {
String key = e.nextElement();
System.out.println(key + " " + dict.get(key));
if (key == "a") {
System.out.println("Look mom, braces!");
}
}
Map<String, Integer> dict = new HashMap<String, Integer>();
dict.put("a", 1);
dict.put("b", 2);
for (Map.Entry<String, Integer> entry : dict) {
System.out.println(entry.getKey() + " " + entry.getValue());
if (entry.getKey().equals("a")) {
System.out.println("Look mom, braces!");
}
}
Way better documented than Python?Code: [Select]Map<String, Integer> dict = new HashMap<String, Integer>();
dict.put("a", 1);
dict.put("b", 2);
for (Map.Entry<String, Integer> entry : dict) {
System.out.println(entry.getKey() + " " + entry.getValue());
if (entry.getKey().equals("a")) {
System.out.println("Look mom, braces!");
}
}
ftfy.
Yes, Java is quite verbose, partly because it is a statically typed language, and we could discuss the drawbacks and benefits of that for weeks. It has its advantages though, not least of which is that it's significantly faster (around half as fast as C++, as far as I know), and way better documented than Python. I think it's in fact one of the best documented languages / standard libraries around, which is worth a lot.
Well how about an "ambassador" for each of the different coding languages recreate GG2 in single player in their language, then we ask everyone which one works best (not a poll). Once a winner is decided, we can work on adding multiplayer, custom map support, and all that good stuff.>adding multiplayer
y/n?
Don't get me wrong, I do think Python would be a good choice. I just don't like it when people bash Java :DWhat Java programmer doesn't? :P
The problem is that does anyone here have enough experience in programming video games in any other language to have a fully functioning graphics/multiplayer engine?We're working in 2D here. Writing a 2D game engine is not a complex task. I'll probably create a new one for this project.
Unless we start off working from anothe video game engine, that's a start at least
I'll skip pages and askWhy rewrite GG2 in another language?
Why
Hey, we could make a parody source engine :DYes, the sauce engine.
On another note, if we make our own engine, we can make new games and actually sell them.Yep.
Or we can just code GG2 in source engine. It would be possible, wouldn't it?
interesting more like valve decides to swoop in and eat the cash cow before it's too big to chew on properlyOr we can just code GG2 in source engine. It would be possible, wouldn't it?
Haha that would be interesting.
I honestly see no future in this. It starts with lots of talking but ends up with nothing.lol, nice metaphor.(click to show/hide)
[ ] rewrite the netcoding to be in a more quake-like udp snapshot system, and ditch the old tcp system in favor of a more lossy, but less bandwidth intensive and latency inducing way.
in quake 3, the networking system basically works like this:
Everything is disposable. The only thing important is making sure that the clients get the most current game state, and they get it as fast as possible.
This opens up alot of new possibilities. Firstly, there's the movement away from tcp into udp, which is very fast and doesn't require port forwarding in some cases (socket punching) though that's irrelevent tbh to the whole decision as a whole
Basically when a missed packet is missed in the current system, tcp must freeze the socket, ask the server to resend the packet, and then unfreezes the socket. That's very slow and induces alot of latency.
In a udp based system we wouldn't need to pause for everything. If something is missed last frame, such as the position of a player, it doesn't really matter. The next frame will be updated so quickly that you won't even notice the brief decync. This makes the game artificially much much smoother
Everything is disposable, because I can't really imagine how we should change what.
simple: we don't compensate packetsI fell very dumb, but what do you mean by that? Do we not expect packets, and just take those that appear? Do we try to guess how the game will go, and just take any packet that chances our way, without really expecting any?
Send snapshots of the current game stateOh.
if anything's lost, it'll be in the next update so it doesn't matter
:I
class GameObject:
"""
Class all game objects inherit from.
"""
def __init__(self, environment):
self.environment = environment
class MyFancyObject(GameObject):
"""
A fancy game object!
"""
def __init__(self, environment, x=0, y=0):
GameObject.__init__(self, environment)
self.x, self.y = x, y
self.sprite = load_sprite("lol.png")
self.environment.register_event("draw", self.draw, zindex=20)
self.environment.register_event("step", self.step)
def step(self):
self.x += 2
self.y += 3
def draw(self, canvas):
canvas.draw(self.sprite, self.x-self.enviroment.viewport[0], self.y-self.enviroment.viewport[1])
I just randomly noticed that there is a LUA wrapper for Game Maker, unsurprisingly called gmlua. It can apparently call into GML functions by using the dark magic of GMAPI, so a relatively tight integration between LUA and GML is possible. However, GMAPI only works with GM up to version 8.0 and doesn't seem very active, so if we did use it, we might not be able to switch to GM 8.1. GMAPI is LGPL licensed, so we could always do the porting ourselves, but I don't really feel like taking on yet another GM extension projekt at the moment.I hear GM 8.1 is awful, anyway.
On the upside, having coroutines could dramatically simplify the netcode. If I understand them correctly (I never actually used coroutines yet), they would allow writing netcode almost as if the calls were blocking. That is, you could have a function receiveOrYield(socket, size) that will only return once the requested ammount has been read, and in the meantime it wouldn't block the thread, but allow the game to continue running. It would also improve the possibilities of script-based modding. And if done well, the game logic might be translated to LUA bit by bit, until we only have the bare "engine" in GML, which could then be recreated in a different host language to migrate completely away from Game Maker.
I didn't spend any time actually planning this so there might be glaring flaws. Just putting it here as an idea. I still won't have time to do this kind of thing for a while now.
hey
a language change that means none of the years of work has to be lost now?
and might result in more efficient program structure?
in fact eventually so ridiculously efficient that we'll wonder why we used the slow buggy crap of today?
wow i hate this the old ways are better everyone knows that new things are bad
You obviously have never traveled herehey
a language change that means none of the years of work has to be lost now?
and might result in more efficient program structure?
in fact eventually so ridiculously efficient that we'll wonder why we used the slow buggy crap of today?
wow i hate this the old ways are better everyone knows that new things are bad
Just because there's a checkbox that says "Enable Something" doesn't mean everything will magically become super efficient without us doing anything.
I just randomly noticed that there is a LUA wrapper for Game Maker, unsurprisingly called gmlua. It can apparently call into GML functions by using the dark magic of GMAPI, so a relatively tight integration between LUA and GML is possible. However, GMAPI only works with GM up to version 8.0 and doesn't seem very active, so if we did use it, we might not be able to switch to GM 8.1. GMAPI is LGPL licensed, so we could always do the porting ourselves, but I don't really feel like taking on yet another GM extension projekt at the moment.I'm supposed to be retired, but I'm visiting for 5 minutes again.
On the upside, having coroutines could dramatically simplify the netcode. If I understand them correctly (I never actually used coroutines yet), they would allow writing netcode almost as if the calls were blocking. That is, you could have a function receiveOrYield(socket, size) that will only return once the requested ammount has been read, and in the meantime it wouldn't block the thread, but allow the game to continue running. It would also improve the possibilities of script-based modding. And if done well, the game logic might be translated to LUA bit by bit, until we only have the bare "engine" in GML, which could then be recreated in a different host language to migrate completely away from Game Maker.
I didn't spend any time actually planning this so there might be glaring flaws. Just putting it here as an idea. I still won't have time to do this kind of thing for a while now.