The MultiPlayer Problem

When designing a game, if there’s intent to make it a multi player game, it really needs to be decided before a single line of code is written. That way, all code is designed with a mind that there are more than one potential ‘players’ interacting with resources.

For some games, like GTA 5, there is a distinct separation of single player games/quests/game play from the online/multiplayer aspect. The quests are different, the ‘feel’ is different, the way a player initiates games that will involve other players is different. Single player tracks the one individual through the quests, while multi-player quests are created with a mind to track all the players. In fact, the only thing that is really ‘shared’ between the two is the game world, with the logic of the cars, pedestrians, and cops all generally behaving the same way (although the cops technically are modified to only chase after players who are blowing stuff up).

For a more streamlined game like mini golf, where Occam’s razor dictates the ball on the course expects only one person to hit it and therefore only one scorecard needs to be kept track of, and so on… making it multi-player really requires that the code be designed that way from the ground up.

When I created Autumn Park Mini Golf, it was meant to be single player and I had no intention of making it multi-player. I never advertised plans to do so, and was explicit in the game description that it was only single player.

But the reviewers bitched. A lot. “But this game has multi player! Why doesn’t yours?”

Simple answer: I was charging 99 cents for my game. Games that included multiplayer were charging way more, and their style of game design/play was counter to the relaxing atmosphere Autumn Park was intended to provide.

I’ve spent the last couple of weeks revisiting and revamping code, to streamline behavior and to make specific processes more efficient. The sound system got a full overhaul, and the last couple days I’ve been reworking the game completion reward system (the initial version of the code was downright spaghetti while this version is a A->B->C clear process).

I decided to go looking into the other VR Golf games that exist (and becoming rapidly concerned about how many are out there… I need to stop ‘stalling’ on releasing my game) and are noticing in the reviews the people have, unsurprisingly, a common complaint. “Make this multiplayer!”

Face-desks repeatedly…

So. I could make my game stand out. I could make it multi player. Give the gaming population what they want.

But at what cost?

The amount of code that would have to rework would be … excessively more than I planned on tweaking with my optimization tasks.

But I’m also at a point where I honestly feeling like I have a complete game ready to ship and I’m just stalling to add ‘just one more little thing’ or make ‘one tiny improvement here’ and while I’m doing this… fully designed games are being released and the longer I wait, the more games flood the market.

I don’t want to be yet another mini golf game.

I want this game to be a unique take on a stunning environment and a unique concept. I question if the complexity involved with reworking everything to make it multi-player would be worth the time sacrificed to bring it to market.

But… well… I did implement hats. At least players could see each other.

As far as the to-do list -> to-done list

Well, there were a couple things I wanted to hash out and I got a couple of milestones completed. The one major thing I was working towards (and still tweaking, hence the need to revamp the reward decorations code) was my save-load feature.

This was also heavily requested for Autumn Park but I never got around to adding it to the code. I’m intending on releasing Pirate Island with this feature (and plan to circle around back to AP to add it as a small update).

I’m also adding more ‘rest areas’ to the game which are locations off the beaten path that provide some reasonable reason to hang out and just admire the scenery. Little Easter Eggs will be hidden here and there, which will hopefully invite exploration and I now have quite a few extra little items the player can just find and carry around.

One such item is the Compass. I realized that the player could theoretically not be able to figure out where the next course is located. This is especially true for the third game, where there is some holes are not… intuitively placed.

I considered creating a GUI icon showing where the next game was, but it really broke immersion. So I came up with the compass. It will always point towards the next ‘active’ ball, so the player can find the next course.

I’m toying around with a couple other ‘odds and ends’ items (see that bit above about ‘stalling’…) but now, honestly, I need to put on the thinking cap and see if multiplayer is feasible at this point.

I hope everyone is having a great week and look forward to giving the next update.