• interested in more? sign up to the newsletter

     

Multiplayer interaction and camera

Tweet about this on TwitterShare on RedditShare on Facebook

As game developer there are times where you have to figure out stuff that you have never coded or figured out before.  For me this was the Multiplayer aspect of Gunslugs.

The core game code was up and running with the player being able to jump, run, and blow up almost everything. The way I usually code interactive game stuff is having what I call a “Monster” class where all the objects live in.

So enemy soldiers live in the Monster class, but also bouncing bombs, mines, oil-drums, and even buildings that you enter and exit from. A pretty important class, and I know, everyone will tell you to split it up in more manageable and smaller classes.. and you really should! but I’m used to this, so I just dump it all into one big class of various “monsters”. I’m pretty sure it has advantages somewhere..

Anyway, many of these monsters need to have a bearing of the player: where is the player, what is he doing, what direction is he moving in, is he shooting? on an elevator? god mode? etc.

Here started my main problem: what if there are TWO player objects running around?  Do I duplicate all those conditional stuff ? meaning a lot more code but also double the amount of time needed to process it?  I think not!

Having no experience in this area, I just decided to go for the most optimized solution I could think of and it feels a little bit like cheating, and probably is, but it turns out that it works PERFECTLY.

What I do is before I update a monster I check which of the two players is the closest, and then I will use THAT player for any other conditional stuff I have to do. The other player is completely ignored. This means I added a couple of lines of code that did the checking of who is closest; where horizontal location mattered more then vertical. And all the other code was kept the same.

The good: it’s almost as fast as the original one player code
The bad: it’s cheating, cause one of the two players is “not there” for the monster. Luckily because players are moving around, this shifts around a lot, unless you have one player who keeps sitting “at the back” letting the other player do all the hard work.. pretty realistic I guess !

Buildings are pretty simple, taking my queu from the New Super Mario game on Wii: if one player enters a door, the other player is automagically entering the door also.. you can try to run away or hide, but you will be sucked into that other room.  So the first player to trigger our building, is simply triggering the level load and taking the other players with him.

Camera

The second problem with two players is the camera! At least, I thought it would be a problem. However I found another pretty simple solution for this one.

Normally the camera makes sure the player is in the center of the screen by taking the player location, and subtracting half of the display width.  Again.. how do you do that with two players?

Simple: take the center point between the two players, and subtract half the display width to make it the center point on the screen.

All you have to do then is make sure the players can’t move further left then the world offset, and they can’t move further right then the world offset + the display width.

 

Bookmark the permalink.