At first, implementing a multiplayer system beyond the network code itself seemed a rather trivial task – I had been given a game concept already proved to work quite well. But the further this project progressed, the more complex did the actual implementation of multiplayer turn out to be, and I’d like to mention a few of the difficulties that I faced (and still am facing) related to this.

Excessive co-operation

Imagining a bunch of players standing at the far end of the ice, each covering a portion of the screen in minigun fire, made me rather aware of this relatively big problem at an early point, and sadly I haven’t been able to test this very extensively as of yet. The current plan is to allow a maximum of four active players at once, so as to not crowd the icy field too much.

Difficulty scaling

In the original game, the difficulty in co-op mode was ramped up by increasing the rate at which seals appeared. This is currently the same method I am using as well, but finding the exact formulae for this is not an easy task, and would also require thorough testing. The problem with having many enemies is that splash weapons such as the M79 or the grenades may easily become overpowered and possibly greatly impede the money income of a merry grenadier’s companions. Since the actual field of play in Seal Hunter is bigger than that in the original, modifying the height of the field dynamically based on the number of players is also an idea that I’ve been meaning to look into – for example, keep the field the original size with 1-2 players but increasing it to its maximum as the player count increases further.

Round structure

Before a round can start, all players ingame must signal that they are ready, and only then will the actual game start. But what happens if a player joins while a round is still in progress? What happens if a player leaves? The current solutions to those issues are to force a joining player to spectate until the round is over, and if a player leaves mid-game the enemy spawn timers will dynamically adjust to suit the number of players still there. And any money the leaver earned, or any weapons that he bought, will be lost forever. I’m not entirely happy with this second solution, but it’s simple. Again, further testing will prove just how good this concept might be.

If any readers would have any alternative ideas to the problems listed above, feel free to give me your input below. Thanks!