# How do I prototype an online game? [closed]

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.

• Well, I've heard that Unity is capable of creating MMO style games, however it is an Engine that focuses on 3D, you can do 2D but you just have to get a bit creative (like make a plane that contains the 2D sprite as a texture and set the camera to look down.) I know 3D buzz made a tutorial on Unity MMO programming, but I don't think it is available to the public. I suggest you being with Paper Prototyping, which is where you try to create a game using paper cut outs and move things on your own, it is a good way to get feedback without creating the full game, just handle online events yourself. – Benjamin Danger Johnson Jan 25 '13 at 17:22
• ZMQ is awesome for reducing networking boilerplate. – Anko Jan 25 '13 at 17:43
• @BenjaminDangerJohnson I've used Unity, but their networking components are too specific for sharing object positions. You have to write your own engine on top of it if you want to use it for something else, and that defeats the entire purpose of prototyping. – Panda Pajama Jan 26 '13 at 5:00
• @Anko 0MQ seems interesting, and I'll give it a try. I'm worried it that it tries to simplify the transport layer, which most likely means that eventually, you're going to have to write your own application protocol, which is precisely what I want to avoid for the prototyping phase. – Panda Pajama Jan 26 '13 at 5:08
• Based on the rewrite, 0MQ (or RabbitMQ) will work fine. No messaging system can automate your game's data replication, the contents of the message will always be up to you to create and interpret. Heck, on a LAN you could simply spam broadcasts and anyone listening could pick out packets meant for them, data could be XML or JSON or an easy key-value text pair stream because for prototyping locally you're guaranteed to have tons of bandwidth. But you still have to do code work. – Patrick Hughes Jan 26 '13 at 7:34

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. :)

• When doing this, I recommend having at least one person acting as an observer; not taking part in the game itself, and another person whose job is to keep notes about who did what and when. That data about what actually happened during each game can become tremendously useful while adjusting the rule set between games.

Pen, paper, dice, cards, boards, tokens. That's really all you need. And for prototyping a game design, it's better than anything else.

• On the contrary. If your workmates refuse to do what's demonstrably the fastest and most economical way for the company to rapidly iterate on a prototype game design, then you are not in a professional environment. – Trevor Powell Jan 26 '13 at 10:32
• Let's not turn this into a workplace discussion. Certainly physical prototyping is very good, but it's not always possible, and not all games are trivially physically playable. I can usually hack single player 2D game ideas in a few hours, and modify them to see if they're interesting. I just want to be able to do the same for multiplayer games. – Panda Pajama Jan 26 '13 at 10:54
• You're the one who brought up work environments, not me. If you don't want to talk about them, that's fine. But don't expect me to stay silent while you make claims that physical prototyping somehow can't work in "professional" work environments. Because that's simply not true. – Trevor Powell Jan 26 '13 at 12:38
• Also, not all games are trivially physically prototypable. Puzzle and strategy games are easy to do with your proposal, but action, musical, racing, sports and simulation games may not be so. – Panda Pajama Jan 26 '13 at 12:50
• No method will magically make prototyping 'trivial' for any type of game (much less for every type of game). Doubly so when networks are involved. That it's 'not trivial' is not a reason to dismiss any method of prototyping, because you're never going to find a method that is trivial. – Trevor Powell Jan 26 '13 at 15:05

relatively simple rule changes such as "let's try this in real time instead of turn-based" That sounds like a pretty fundamental change to me, not a simple rule change. I think fundamental design choices like that should be made before you even get to writing any networking code, either with offline prototypes or even paper prototypes.

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."

• Not really, if it's not networked, changing a turn based game into real time is not very difficult. The problem with trying on the same computer is that you're limited to two, or maybe up to four users at the same time. Anyways, that was one example, but there are many other things I want to test that can definitely be made easier to test if they are actually networked... – Panda Pajama Jan 26 '13 at 4:58
• Not understanding the point of your first sentence. That's exactly what I'm getting at, that making that gameplay change is easy if the game isn't networked. And if there are other things that can only be tested once networking is actually in place (eg. syncing over the internet) then make as many decisions as possible before you start worrying about that. – jhocking Jan 26 '13 at 13:40

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:

• the Python programming language
• 0MQ for messaging (via pyzmq)
• the pickle module to send arbitrary data (as given in an example here)

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.