At work (myDropWizard or MDW), we started doing psuedo-monthly gamejams a few months ago. This past weekend was the 3rd one, and this time I decided I wanted to take what I'm learning from creating "Battle Pong", and make a network multiplayer game that might actually be fun. :-)
So, I created "Battle Tanks", a 2-4 player game, that pits tanks against each other in a 2D, top-down battle to see who will be the last one standing.
I used the great "Top-down Tanks Redux" asset kit from Kenney.nl.
It was a really interesting experience, and while not yet at its full potential, the game has the seeds of a fun experience that I think I'm going to continue to develop, at least for a little while.
Read more for the deets!
Another networked multiplayer game?
While I used what I learned from "Battle Pong" and that definitely made this project go a lot faster, I did end up doing the networking a little different in "Battle Tanks" which led to some interesting new learnings.
In "Battle Pong", we do the physics simulation exclusively on the server, and just receive inputs from the clients, and the server sends them the new ball position. This is essential in "Battle Pong" because we're using pure physics for the bouncing ball, and so don't want to run the physics in multiple places and have the clients get out of sync with each other. This is also probably a good way to do it for learning because in a real multiplayer game you need to prevent cheating, and so you want to make the server the ultimate authority.
Also, "Battle Pong" has no real "lobby phase" because it's only two player. As soon as the 2nd player connects it starts the ball moving, but otherwise the game is always "in session". There's also no loading of the players or setup since the elements in the scene never change (it's always two paddles and a ball) and so everything is loaded up right when the game starts.
In "Battle Tanks", I did things a little differently. I followed the High level multiplayer docs a lot more closely, and have a lobby phase, and a setup phase where the player scenes are instantiated in each client before starting the game. I also have each player's client as the master for their individual tank, which then lets the server and all the other clients know where its current position is.
I'm pretty conflicted about this last point. On the one hand, this is just a dumb gamejam game, and so no one is really gonna make the effort to cheat, so who cares. But I do want to learn how to do stuff for real games! On the other hand, having the player's client be the master of their tank will make the game feel much more responsive, since there is no delay in pressing inputs and seeing your own tank respond. And this is also how the docs do it, so it'd be nice to learn the pro's/con's of this approach, since it's at least partially the "official" way to do it.
In any case, I was again super surprised with just how quick and easy it is to make a networked multiplayer game with Godot! I had networking done to the point that all four players could connect and move their tanks around, in about 4 hours. It's just crazy!
Multiplayer is hard to test
One of the things I learned from developing this game, is that multiplayer games are really hard to test. And I don't mean testing to verify that stuff works technically (I can start 4 clients myself and switch between them easily enough), but that the gameplay works the way I think it does.
By 5pm on Friday, I had the networking in place, with shooting, the ability to take damage and die, and then restart a new session. Basically, the absolute minimum to win, lose and start over, which is the first milestone I'm always trying to get to with a new game.
But the play area was just an empty grassy space, and the the tanks are all identical in speed as well as firing rate and range. So, my assumption was that the game was not going to be fun, because how could their be any strategy or technique? You'd just try to get close enough to fire some shots, and then move back before the other tank gets you. Or hope the other person chases you and you can run away while firing behind you (this is the superior position because you'll out run your opponents bullets, but they'll drive right into yours).
However, the first time I managed to test it with another player, it was actually quite fun! And I had no idea because I hadn't yet played it with another real person.
Of course, after enough time, it would get boring without more mechanics. But the point is that on my own I just had no clue what the gameplay of my game was, or if the game design was any good, whereas with a single player game, it's much easier to see.
It also means that I'm wary of making too many gameplay changes at once, because I can't know the effect of them until I can get 1-3 people to have a tank battle with me! I worry that if I change lots of stuff, I won't know which change had what effect. Or if two changes are reversing each other. So, I'm trying to take it slow, making a change, then playtesting it, before moving on to the next change.
Streaming is exhausting
I streamed the first 5 hours of development on Twitch.tv, which was fun for the most part. Unfortunately, I forgot to record locally, so the videos are just up on my Twitch page for the next 1.5 weeks, and not preserved forever on YouTube. Turns out you can download your Twitch videos! So, these's are now on YouTube too:
Anyway, this is the longest stream I've ever done, and after a while, it just got tiring and I really just wanted to be "alone" again. :-) I also found that I had no patience for the folks who showed up towards the end of the stream. There was one person who actually totally threw me off!
I was testing some changes to a scene, and put in some debug testing stuff that I intended to remove later. A new person dropped in and asked what I was working on, so, I stopped and explained. Then, they said, "hey, your debug tab is filling up with messages!" So, I dropped everything to try and work that out - it took at least 30 minutes - and in the end I realized it was the debug testing changes I made, but had forgotten about because I stopped midway to explain what I was working on. :-) By the time I fixed that issue, that particular viewer had already left the stream. Had they not shown up, I wouldn't have forgotten what I was doing and not wasted 30+ minutes.
Oh, well! I'm learning lots from streaming and so I'll continue to experiment with it.
Developing for a couple extra days led to new game dev experiences!
Previous MDW gamejams have been for a single day (but a work day where we get work time to gamejam ;-)) whereas this one went the whole weekend. I didn't work on it much over the weekend, maybe an extra 4 hours of development, but it meant I did a lot of things I haven't done before.
After getting the core mechanics in, there was actually a "content phase", where I added a bunch of objects and powerups to the game, and then built a more interesting stage for the battle to take place.
This was really cool! In the past, I just barely get the core mechanics done on time, and so there's just the bare minimum of content to make the thing work. This time I made a bunch of interesting things, including some objects with the same mechanical properties which only looked different, and purely cosmetic objects.
Frequently, my gamejam games aren't very fun largely due to the the crappy level design, and so more experience in this area is super good for me.
What's next?
Since the jam, I've been thinking about the game more and even some changes and bug fixes. And it's quite fun to play with my kids and co-workers. :-) So, I think I'll keep tinkering with it for a while.
There's more network stuff I want to learn with "Battle Pong" which I'll go batck to sooner or later, but perhaps I'll take those lessons to into "Battle Tanks" too!
You can grab the code, and even Linux, MacOS and Windows builds, from the GitLab project page here:
Comments