I have dabbled with game development in the past, without very much success. However, I have never finished a project. Most of my past projects have gone something like this:
- Get excited about a game without thinking it through entirely
- Build a very barebones prototype of the game
- Burn out and move on to the next project...
That being said, I haven't taken on a real game development project in a few years. Since my last real attempt at making a game in early 2019, I have improved at finishing other projects or at least seeing them to a reasonable conclusion. In addition, I have a few years of enterprise software development under my belt now.
I still wasn't convinced that I could finish a full game. So my friend and I decided to join Ludam Dare 48, making Eat Fishies over the weekend. Now I wouldn't consider Eat Fishies to be a fantastic (or maybe even good) game by any means. We received some good feedback and more importantly, it meant I had finished a game.
Riding the high of Ludam Dare, I wanted to dive into making another game. I knew it needed to be somewhat small in scope, and not be overly complicated. A few friends and I started bouncing some potential ideas around. We ended up on the idea of a Hide and Seek or Tag-based party game.
While still in the process of nailing down all of the mechanics and ideas, our discussions here are a few things I know I want to include in the game.
I wanted to dive right in, so I could get a prototype up and running. So I decided on using Godot, it was fresh in my mind since I used it when working on our Ludam Dare game. I like Godot for several reasons. It's easy to get started, lightweight, and has great documentation. In addition, the Node and Scene system the engine uses is very intuitive to me. I considered using Unity and Pico8 but decided against them. Unity has always seemed like a bit too much for me. To me, it's an overwhelming engine. On the other end of the spectrum, I decided against Pico8 because I think its too small for what I'm looking to make (and I also really don't like Lua_).
I started working on making a very barebones prototype. I wanted to have 3 things mostly working for the prototype:
So I got to work top-down on that list and started working on a prototype. I opted to use C# instead of the Godot-specific language
gdscript. The main reason for this was that I have some level of familiarity with C#, as well as C# can be considered a "marketable skill" that has use cases outside of the Godot game engine.
Before I got started I wanted to do some research. I found three resources that were instrumental in getting the basic networking done so quickly. Firstly I read through the high-level multiplayer docs on the Godot site. That gave me a great overview of how peer-to-peer multiplayer works, and some basics steps for implementation in Godot. Next, I reviewed the code in the multiplayer_bomber repo, this is an official Godot example and gave me a great understanding of how to structure the project. Then to reinforce what I learned in going through that repo, I read through the MonoHighLevelMultiplayer example, to get a better idea of how to structure my code in C#. All in all research and development took me about four days.
With that done I had two red squares moving around the screen over my network, and I decided to get started on my player character. This wasn't too bad as I have done similar things in the past, just a bit of a refresher getting the player controller setup watching some videos, and reading the Godot docs. I did run into a small issue getting the player animations to sync over the network. The issue ended up being that I was using an
AnimationTree node to control the animations of my player based on their
InputVector. So I needed to pass the players
InputVector to their puppets across the network.