Continuing on my quest to gain knowledge of networked multiplayer systems, I wanted to spend this week working on a system where players could seamlessly drop in/out of a game revolving around one host player. Ultimately, I decided that a re-make of Asteroids would be the best way to go about this.
The plan was to have one player be the ‘host’ of a room and act as the ship while allowing for another player to join the room and take over control of the asteroids. While there was no second player, the asteroids would behave normally, but otherwise, the direction of the asteroids’ movement would be controlled by the second player.
What went right
Two player Asteroids works surprisingly well. Having one player in charge of altering the movement of the asteroids added a pretty interesting element to an otherwise consistently un-changed classic.
What went wrong
I didn’t budget time well this week. Between having to leave the Schengen Area of Europe due to visa issues, contract work, and the ending of Ramadan (basically meaning that I was hungry and tired all of the time), I couldn’t quite find the free time/motivation to do nearly as much as I wanted to on this game. Most disappointingly, I didn’t have a chance to really delve into the networking part of this game. As that was one of the biggest parts of this week’s idea, I’m incredibly bummed about that. This was going to be a really wonderful learning experience in the type of networked multiplayer that I am hoping to achieve, and I essentially blew it.
What I learned
Honestly, I didn’t learn all that much this week that I haven’t learned before (see: any week I’ve said I need to budget my time better). I learned a lot about visas and Ramadan – but I’m going to save those lessons for a non-Game a Week related post 🙂