6
\$\begingroup\$

Especially for game designers or software engineers, I was wondering how significant of an increase in difficulty/frustration/workload it would be for multiplayer to be an afterthought of a singleplayer game, as opposed to putting in all of the work for the game to be "multiplayer ready" from the start.

This question is especially important when the question of "Will there be multiplayer?" is up in the air until after the game is developed.

I only ask because coding with multiplayer in mind from the start, I assume, is a hefty chunk of extra difficulty that one could otherwise skip. Of course adding in such a engine-changing feature, I assume, would be quite frustrating given a game already close to being finished. Both strategies seem burdensome, but if the extra workload of implementing a big feature after a game is already completely is extraordinary compared to the heavy workload of engineering it from the start, then obviously one would nearly always want to prepare for multiplayer.

I am also curious on a personal level as I have seen a few indie projects declare they will never add multiplayer, and then months later after the game has over a year in development, change their mind and say they will be adding it as a high priority feature due to the large demand for what is probably the most common core feature of any game.

Improve this question
\$\endgroup\$
4
  • \$\begingroup\$ Online multiplayer, LAN, or split-screen? \$\endgroup\$
    – tyjkenn
    Jun 21 '13 at 19:02
  • 2
    \$\begingroup\$ Related: gamedev.stackexchange.com/q/34064/18913 \$\endgroup\$
    – Pureferret
    Jun 21 '13 at 22:46
  • \$\begingroup\$ Online Multiplayer or LAN \$\endgroup\$
    – user32182
    Jun 22 '13 at 6:39
  • 1
    \$\begingroup\$ You could write the singleplayer as one man multiplayer, e.g. so that the client starts a server running on the players computer and connects to that when a singleplayer game is started. Even then, the networking required is non trivial. \$\endgroup\$
    – Exilyth
    Jun 24 '13 at 19:43
2
\$\begingroup\$

There are software architecture patterns which make it quite easy to add multiplayer later. One is the Model-View-Controller pattern.

In a game, the model is the current game state (which game object is where and does what right now), the view is the graphic engine which visualizes the game state, and the controllers are the game mechanics and the player inputs which change the game state.

To add networking or multi-controller support to a game built around MVC, you just need to add a new controller (network input / 2nd player controls) and a new view (network output / 2nd player screen).

Improve this answer
\$\endgroup\$
7
  • \$\begingroup\$ Thank you very much, this is a very detailed and specific answer. \$\endgroup\$
    – user32182
    Jun 22 '13 at 6:28
  • 4
    \$\begingroup\$ -1 A good multi player is far from easy. It opens a new dimension of problems, design patterns will be the smallest of the problems. Testing and debugging is a pain and timing critical, Qa-ing, bug-reproduction, a new wall of TRCs and TCRs or whatever your platform's compliance tests are if any. \$\endgroup\$
    – Maik Semder
    Jun 22 '13 at 18:20
  • \$\begingroup\$ Definitely the best answer. Very sad it has the least upvotes, but you probably don't spend enough time on the website to be friends with the group of users who pat each other on the back with upvotes regardless of the answer's quality. \$\endgroup\$
    – user32182
    Jun 23 '13 at 22:26
  • \$\begingroup\$ @MannyTotem there is no conspiracy - my answer was just too late. Late answers always get fewer votes, because most people overlook them and only vote on the answers which are already on top. \$\endgroup\$
    – Philipp
    Jun 24 '13 at 7:55
  • \$\begingroup\$ Too late by 1-2 hours? \$\endgroup\$
    – user32182
    Jun 24 '13 at 17:41
12
\$\begingroup\$

If you were to compare a list of all the systems that could be affected by the addition of multiplayer with a list of all the systems that need to be in the game, the lists are likely to be the same.

For example, adding multiplayer to a single player game can/will affect:

  • Enemy AI (now the enemies have multiple enemies!)
  • Rendering/animation (if you had a FPS before, now you need to also draw a character where the camera is, animations that look fine in first person may look horrible to another player in 3rd person)
  • UI (lobbies, chat windows, etc.)
  • World structure (that chunking system now needs to support multiple locations)
  • Save/load data (changes to the world can come from other players and need to be saved)
  • Sound (local multiplayer now has two listeners and Maik's other examples in comments)
  • And so on...

So, how significant? Very significant.

However, I would purpose it's better to finish a single player game than to never finish a multiplayer game. If you have doubts about the added difficulty of completing a game that includes multiplayer, don't include it. You can find a middle ground along the way, by trying not to make architectural decisions that will shoot you in the foot later, if and when you update the game to be multiplayer.

Improve this answer
\$\endgroup\$
8
  • 2
    \$\begingroup\$ I am not sure your list is entirely accurate. It would be extremely archaic if multiplayer networking effected something as client-based as Sound. I won't go into why I think other things on the list are not very relevant to multiplayer, as that can sometimes be true depending on how you design the game. However something as simple as sound would definitely be almost entirely on the Client, and would be the result of an event, not actual network data telling players to play a sound. I suggest an edit to clarify why these things are listed, or to delete a good chunk of them from the list. \$\endgroup\$
    – user32182
    Jun 22 '13 at 6:16
  • \$\begingroup\$ @MannyTotem Thanks for the suggestion. I believe that as you say "it depends". The point being it has the possibility to affect all those things. Perhaps not for your game or the way you're designing it, but it's possible with another game with a different play mechanic. I'll leave the answer as it stands to be more generally applicable. Feel free to ignore any of the items on the list you don't think fit your game. Just understand that the point is: it's significant. \$\endgroup\$
    – House ♦
    Jun 22 '13 at 6:57
  • \$\begingroup\$ I would still love to see the list have explanations for how it can affect the listed components. Note that I said "clarify why or delete" as opposed to simply "Erase that answer ya fool!" lol :P It would give more insight as to how networking could work, more credibility to the answer, and just create a better answer to what can only be a very commonly asked question. \$\endgroup\$
    – user32182
    Jun 22 '13 at 7:15
  • 1
    \$\begingroup\$ @MannyTotem I've added examples and removed sound (couldn't think of a scenario for that one :p). \$\endgroup\$
    – House ♦
    Jun 22 '13 at 14:28
  • 2
    \$\begingroup\$ Sound changes in fact with local multiplayer, now you have 2 listeners. Another scenario is calculate shooting and collision on the server, but the impact sounds must be triggered on the client. \$\endgroup\$
    – Maik Semder
    Jun 22 '13 at 15:08
11
\$\begingroup\$

This is one of those "it depends" questions. Does your game have a lot of physics objects that would be hard to replicate? How much would high latency bother your game? What kind of libraries are you using?

And on top of that, does the design of your game allow for multiplayer? Shoving co-op into a single player corridor shooter where you have your designers making assumptions about the numbers of players for things like traps and puzzles isn't likely going to work even if you solve the technical problems.

Some games go so far as to have separate single player and multiplayer executables and just share art content and style. So you can have multiplayer but you basically have two separate code bases.

Suffice to say, it can be incredibly difficult or fairly easy. Obviously the better you can plan the more you can do.

Improve this answer
\$\endgroup\$
9
  • \$\begingroup\$ The design aspects that Tetrad points out are most keys. Solving the technical hurdles is often quite doable, especially if building on an engine that already has it, but making the actual game fun and engaging with both single and multiple players is a massive design challenge. \$\endgroup\$
    – Sean Middleditch
    Jun 21 '13 at 19:47
  • 3
    \$\begingroup\$ @MannyTotem I'm answering the implied question of "how do you determine how hard it would be to add MP to an existing product." If you actually asked how to add MP to a specific product it would probably be too localized to generate generally useful answers. Plus you gave no details so it would be hard to really answer your question. The upvotes show that other people agree with my assessment. \$\endgroup\$
    – Tetrad
    Jun 22 '13 at 7:30
  • 2
    \$\begingroup\$ Plus, if I were being pedantic, is there an actual problem to be solved by your question? It feels like a "why do other game developers say this" instead of "I am having a problem". \$\endgroup\$
    – Tetrad
    Jun 22 '13 at 7:34
  • 2
    \$\begingroup\$ @MannyTotem: not quite the same. Adding multiplayer to a game doesn't just require a little refactoring in design; it can require completely redoing the whole game. At the AAA level this is completely unfeasible which is why you usually see it tacked on as an extra mode, quite often by an outsourced company that has no input or control over the single-player mode. \$\endgroup\$
    – Sean Middleditch
    Jun 22 '13 at 18:24
  • 1
    \$\begingroup\$ I admit to nothing :) I think Tetrad's answer is the best one here. Though, I guess I'm just part of the high-rep-conspiracy ;) \$\endgroup\$
    – House ♦
    Jun 24 '13 at 3:59
5
\$\begingroup\$

If your game architecture doesn't support info coming in over the wire, it is a real hassle to add MP later. Make the decision early whether or not your first published version will have MP or not, then develop toward that goal.

It's always easier to drop the MP later if it's going to be too expensive than to tack it on if you decide you want it.

Improve this answer
\$\endgroup\$
1
  • 1
    \$\begingroup\$ +1 vote for "It's always easier to drop the MP later if it's... too expensive..." However, I would love to read a more in depth reasoning for WHY it is a "real hassle to add MP later" or a personal experience as to the level of headache caused by such a hassle. Some more meat to this answer would be very beneficial to anyone reading. Thank you. \$\endgroup\$
    – user32182
    Jun 22 '13 at 6:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy