I would like to know if you guys know of any libraries, engines, or even simply design patterns that heavily simplify the task of sharing information and sending of messages between networked programs, so one can focus on tweaking gameplay instead of rewriting networking code, while prototyping networked games. Since this is meant for prototypes, ease of use and flexibility is much more important than speed and security.
|
|
That is, prototype the gameplay without doing any networking. That would mean writing a game that is multiplayer locally (ie. both players are on the same computer) in order to test gameplay ideas. I mean, at my job we once took a game that was already halfway developed turn-based and converted it to real-time, and yeah that involved a massive rewrite of the networking code. In retrospect, that was a really inefficient way to approach things, and we pretty much decided "never again." |
|||||
|
|
The easiest way to prototype an online game, which allows you to quickly change almost anything in the game (even factors such as real-time vs. turn-based), is to implement the prototype as a physical game. Get all the designers together in a room, get a bunch of cards, or dice, or board game components, or whatever is necessary to prototype the general game interactions. Then play the game. You can do this without needing to pay programmers or artists. Trying different variations of game rules takes only a minute or two instead of requiring hours or days (or weeks!) of programming work, and you can know whether or not your game works by actually playing it, instead of having to design ahead of the implementation and make guesses about what will or won't work. Plus, your programmers will still like you at the end of the process. :)
Pen, paper, dice, cards, boards, tokens. That's really all you need. And for prototyping a game design, it's better than anything else. |
|||||||||||||||||||
|
|
I can't imagine a need for such a tool because I believe network logic is best done through a solid analysis of what information needs to go where. But, if I were forced to create such a thing for someone who wanted one, I would use:
This covers all the problems of reliable transport, message delineation, and serialisation/deserialisation. (Pickle is not safe for anything other than intranet use however.) You will still need to set up the logic to decide what to do with the data, make and implement the decision of which computers connect to which other computers, and so on. And it doesn't support unreliable messaging, or remote procedure calls, or automatic state replication, etc etc. That's why it's usually better just to plan out what you want and write it that way. |
|||
|
|

