Wednesday, April 3, 2013

BlitzBotz : Multiplayer - Proof of Concept

When I woke up this morning and went through my work email, it was quickly apparent that I was going to have to work late at night and well into the morning, so I dedicated the early parts of my day to finishing up my proof of concept for the BlitzBotz multiplayer system. After finishing the Loadout system (featured in this post), I wanted to bring the settings for each bots loadout into the arena I had already assembled and programmed. In all honesty, the process went much smoother than I had anticipated, so I had time left over to wrap a few other things up... starting with handling player spawns when a user enters a non-empty arena. For example, if I had two guest accounts playing in the Free4All arena, and a third player entered, the two original players would receive spawn requests from the new player, but the new player would not receive them from the existing players... they are already in the room and have no need to send out another spawn request. The solution, while seemingly simple, turned out the be a test of my familiarity with my own smartfox server-side code. After trying a few different ways to skin the same cat, I found a solution that was both optimized and required little code to implement... the result is featured in the video below.

This video is four instances of the Unity Web Player version of the game running in chrome. Using the two top players, I login with two different accounts: the first account has a pre-set custom loadout, and the second account (em0r0b0t) actually had no loadout record in the database upon logging in. If a player ever logs into the system and there is no loadout found for them in the database, a default loadout is automatically created for the player, which is the loadout you see in the video for the upper-right instance.

The two lower videos showcase the guest login system. I wanted to ensure that potential players could start playing the game as quickly as possible, and I am always very appreciative when a game allows me to try it out before requiring me to register with an email address. Guest accounts are stored in much the same way as registered users accounts, the only difference being that guest accounts are completely temporary... guests have the option to register and save their progress before exiting, but if they opt out of registering, their data will be wiped out with the next server restart.

The frame rate for the video is terrible, as I desperately need to go video card shopping (I'm still operating with integrated graphics right now). Considering my machines limited graphics capabilities, I still managed to run 4 instances of the game at an average of 45-50 FPS; the framerate of the screen, however, left a lot to be desired.

I have to admit, I'm psyched to have all of these different systems come together in what is really starting to look like the foundations of a video game. I am also happy that the majority of the foundation work is completed, which means within the next week or two I should be able to get to working on the actual gameplay design, rather than just the framework that supports it. My goal is to have multiple instances of the game battling in a 4 player Free4All, complete with attack animations, damage calculations, deaths/respawns and stats tracking. Once that is complete, with just a little work on the website, I should be able to bring this to the Unity WIP section and, if the community is willing, start taking registrations for Open-Alpha testing.

I'm not sure if anyone reads this blog actively, but if you do and would like to be one of the first included in the Open-Alpha, feel free to contact me via and I'll be sure to add you in the list before all the slots get filled up, as I am only releasing small batches of alpha-keys intermittently during development.

No comments:

Post a Comment