Getting started

When I started coding Subveillance, a key decision was which game engine (if any) to use. I didn’t have prior experience with game engines but coding everything from scratch seemed like a non-starter. That would lead to a lot of time spent in low level details like rendering rather than making a game.

Unreal and Unity are the big players for game engines. As a programmer this meant using C++ for Unreal or C# for Unity. I’ve used both in the past but focusing again on productivity of development put C# ahead for me, and hence I picked Unity.

Oh dear. I could write a long rant about how poor the programming experience in Unity is at the moment but I won’t bore you. I gave up after a frustrating week.

I went searching to see if others had the same experience as me. Maybe I just wasn’t up to this. Many threads on Reddit reassured me Unity was a mess for programmers, although this appears to be a decline in the last few years; it was good once.

A comment caught my eye with a recommendation for the Godot game engine. I remembered hearing about it on The Ubuntu Podcast a couple of years back. With solutions for rendering and networking, complete and up-to-date documentation, compatibility with Git version control, and good support from an active community, it looked very promising.

Rather than C++ or C#, Godot has its own Python-like language called GDScript. I was happy to learn something new because of its deep integration into the engine. C# and other languages can also be used but I liked the idea of getting everything done in a single integrated environment.

With an engine picked, where should I start building?

I needed to find out if the core gameplay idea made for a fun game. I decided to build a rough prototype where two or more players traverse a simple map and have to cooperate to do so.

When it comes to programming, I like to explorer the risky, unknown areas early to avoid nasty surprises later on. This prototype would force me to take on network multiplayer code, something completely alien to me. I could address a design question and a technical question at the same time.

After looking through my notes on possible game mechanics, I settled on having areas of a map covered by CCTV cameras that players could not pass through unless temporarily deactivated. With deactivation controls located elsewhere I should be able to design the map such that it could only be navigated by two or more players cooperating.

I underestimated how much there was to learn and get coded. Draw a map of tiles. Import textures. Handle keyboard input. Turn input into character movement. Set up a collision system so that characters couldn’t walk through walls. Detect when CCTV areas were entered. Play alarm sounds. Turn input into deactivation. Detect if the player was near enough to activate a control. Set timers so that the deactivation was temporary. Clone repeated interactive elements in the scene. So much!

And only then did I get to the network code. But a multiplayer game, even a prototype, needs a lobby. So on top of everything else, I learned how to build a UI.

And then I got to the network code.

As a web developer I found it quite mind bending to run a simulation (the game) on each player machine in parallel, share around the inputs from the other players, and… everything just worked! It’s not the only way, but I was sent in this direction by the Godot tutorials and for the purposes of a prototype: If it ain’t broke, don’t fix it.

With prototype finally in hand, my mind turned towards play testing. I wanted to see how easy it was for players to work out and execute the mechanic but I knew given the state of the UI I’d need to give them a helping hand. Building any kind of tutorial would be way too much. What was the simplest thing I could do? Could I just write some instructions directly on the map? Yes.

Jack and Ozric from my Elite Dangerous squadron kindly agree to test for me, one Friday night in mid October.

First finding: The networking code functioned over the internet. Such. A. Relief. It would have been a very short play test otherwise.

Second (meta) finding: I need to take more exhaustive notes during play tests because at the point of writing this I can’t remember who said what in some cases. Apologies for the mis(sing)appropriations.

They gave me very helpful feedback. The text in the UI needs to be bigger. I need to account for players who are not on voice chat, i.e. some text-based comms. It reminded them of Among Us, which frankly I take as high praise!

There were also questions and suggestions. Would there be class-based characters? Would players always have to retrace their steps or could they exit the map at a different location? Would the maps be fixed or procedurally generated? Short answer to all of those at the time was: I don’t know yet but great food for thought.

Success! I was very happy with the results. However, rather than press on I decided to take the opportunity to build a different game, Undead Farmstead. This has its own devlogs if you’d like to understand my motivation for a change of direction.

What I gained from that experience was a much improved understanding of Godot and GDScript, which I can now put into use back on Subveillance. I look at some of the prototype now and cringe.

While I was “away” I also decided that the maps would be procedurally generated and that’s what I’ll talk about next time.