Daniel Brewer Game AI

Building games. Documenting the journey.

Dev-Log 1

We’re taking a break from our perception system to look at the current status of the game I am making.

The game is an arcade action space-ship looter shoot-‘em-up with co-op multiplayer. It will feature a bit of a push-your-luck extraction mechanic, where you balance the risk of staying out longer and collecting more loot vs returning to a space-station to bank your goods.

For this game, I’m focusing on the mechanics first. I’m working on it on my own, in my spare time, and I want to actually ship it in just over a year’s time! That’s some heavy self-imposed constraints! With that in mind, I want to focus on something fun and simple enough that I can actually complete and ship it, but challenging enough to be interesting to work on and fun to play.

It is quite solidly in the early prototyping phase: testing out the movement and attacks, building the foundation for the minute-to-minute game loop etc. My immediate goal is to get enough of the systems working so that I can get a few trusted play testers to give feedback.

So, what’s working right now?

Basic multiplayer is functioning. Co-op multiplayer is a core feature, so I wanted to make sure that everything I build, is built with networking from day 1! One player can host a session and other players can join.

The basic foundation of the spaceship flight model is in. The movement is all client authoritative, which means the movement feels good and responsive for the local player, without having to wait for the server to confirm or correct the movement. Since the game is fast-paced and co-op based, I’m not concerned about players potentially cheating to get an advantage. The details of this are quite interesting and I may expand on it in a future post.

The handling can be tuned for individual ships, so fighters can be fast and agile, bombers a bit slower and larger frigates or freighters are slow and ponderous. But the larger ships make up for it with more resilience and more firepower!

Speaking of firepower, a few different basic weapons are implemented and functional. Players can equip weapons to weapon-mounts on their ship and mix and match their load-out. Lighter, faster ships will allow fewer weapons to be equipped, while heavier ships can be loaded up with several weapon systems, each with their own, independent firing arcs and targeting. Upgrades can be applied to weapons, which can meaningfully change the weapon behavior.

A very basic damage system is in place, allowing ships to be destroyed. When a player dies, they lose all their currently carried loot and respawn at a space station. To bank your loot, you have to return to a space-station willingly. So the longer you stay out, the more you risk losing!

So it’s all coming together for a first playable. This stage is all about getting the functionality in place. Later on, these will be expanded and tuned and allow for much more player customized load-outs and combat style expressivity.

Is this what will ship? Very likely not. But it’s a starting point. And that’s the whole point of iteration and agile development. Start with an idea, implement it as quickly as possible. Evaluate the idea in game. Make changes to improve what works, fix what doesn’t, add more feedback. And iterate again.

What’s next on the todo list? Implementing some basic enemy ships to fight against to really put the flight controls and movement feel to the test!

The views, thoughts, and opinions expressed on this website are my own and do not reflect those of my employer or any affiliated organizations.