Daily Dev Feb 21 – Multiplayer Maps

I noticed something troubling shortly after sitting down to work on my game – my new map generation code was working splendidly, but new players connecting to my server wouldn’t get any map data and would be stuck wandering a black void! Aside from the amusement factor of seeing other players and being able to apparently walk through walls (on the server’s end, since the client saw no walls there was no collision – one downside of a non-authoritative server) this represented a major issue.

I put off my plans for working on monster spawning and combat today and focused on fixing that particular snafu, and fix it I did! The solution didn’t come easily – at first I thought I could just attach a network view to my TileMap (a construct from the 2D Toolkit) but of course that didn’t do anything since there’s no good having something listening to you if you’re not saying anything, and I couldn’t pass along the TileMap data object to new players since as a GameObject datatype, it can’t be transmitted as an argument using remote procedure calls. RPCs will, however, accept more simple data types such as string, integer and most importantly, Vector3.

For the uninitiated, a Vector3 is three float values typically used to describe a position in 3d space; an X, a Y and a Z co-ordinate. Ultimately though they’re just a three element array and the numbers can be used for anything, which made me a very happy camper.

I created RPC versions of two methods my Dungeon Manager uses to build the map – SetTile and Build. SetTile accepts four integer arguments, X and Y co-ordinates, a layer number and a tile ID. Build is called after you’re done setting tiles with SetTile and will update the TileMap allowing you to see the results. Can you see where I’m going with this? Every time the server placed a tile it calls the SetTileRPC I created, using a buffered RPC mode. When it’s finished generating the map, it calls the Build RPC, again in buffered mode.

The important part here is making the RPC calls in buffered mode – as the name suggests, in this mode all rpc calls are recorded in a buffer, which played back to new players in the order they were received. ¬†Essentially, the server’s Dungeon Manager records every tile it places while generating the map and tells newly connected players’ Dungeon Managers to place all the same tiles, build the map and then pop the player into existence.

Wonderful stuff, wish it didn’t take so long to figure out. Networking is hard!

I didn’t have the energy or inclination to go back to the day’s planned work so instead I played around with adding lighting to the map – it looks pretty cool! For some reason player sprites aren’t being lit properly though, so there’s something to start on tomorrow!

Daily Dev Feb 17 – Multiplayer!

Alright so ‘Daily’ may not be the right word, I’ve been busy!

The past few days have been an adventure of experimenting with what’s possible using the basic multiplayer libraries provided in Unity. Long story short, making an authoritative (read my other posts for more info on what that is) server in basic Unity is… challenging. I spent a good few hours today trying to get that working and to put it gently, I made a bollocks of it. Oh well! It’s all valuable experience.

Eventually I decided that authoritative servers aren’t really needed for my game, at least not at this stage in development, and -any- multiplayer is better than none, so I put together what you see in the video below – the new system essentially lets the clients manage their own player data (movement, stats etc) which is simpler for me as a developer, but is more vulnerable to cheating. Not a big concern right now.

What you don’t see in the video is that there’s a new character controller class in the background which acts similarly to the one Dev Vlog #1 – it handles input and moves the character around, as well as telling the animation handler (largely unchanged from the original version) what to do. The big difference is that it now works with a new class, the Client Data Manager, which takes snapshots of your character data (your position as well as other stats for the animator such as are you walking and which direction you’re facing) and sends all that up to the server, which in turn sends it to all the other connected clients. This way, when you move, you tell the server “I’m moving!” and the server tells your friends that you’re moving, which makes your friends’ copy of your character do his running animation while traipsing around your screen.

S’pretty simple on paper!