Crafting a Military Logistics Simulation Game

Context

I designed and developed this game in Unity Game Engine throughout 2022.

I'm an amateur military historian, lifelong RTS fan, and used to work in logistics. This combination of interests gave me an idea: create a game that highlights the challenges inherent in supplying a war effort that often get overlooked in media.

This... gave me an idea: create a game that highlights the challenges inherent in supplying a war effort that often get overlooked in media.

Games, movies, and books about the military usually focus on the front lines. While this is worth showcasing, we can't forget about the massive portion of the military that supports them.

For example: in Iraq in 2005, it's estimated that only 11% of the US Army consisted of pure combat forces. Compare that to the 60-75% of noncombat forces, of which 60% were logistics focused.

Only 11% of the US Army [in Iraq] consisted of pure combat forces.

Building Version 0.1

The initial build was created in 20 hours over the course of 2 weeks. This timeframe was specifically designed as a challenge to myself.

I had previously tried 2 week sprints on projects, but found that the first week would be front-loaded with work, while the 2nd week would be notably lighter. I wanted to get ahead of this pattern by providing a deadline while also limiting the amount of hours I could work.

This had mixed success. I still followed that exact pattern, putting 15 hours into the project in the first week.

I was very discouraged going into the second week. I didn't think I had time to finish the game in 5 hours, and I even considered scrapping the whole project.

There was good news. Since I only had 5 hours to finish the project, it meant that I basically had 1 option: ruthlessly prioritize the remaining work.

This resulted in a finished project, at least in terms of this challenge. I had to scrap a feature (helicopters) that I had spent a couple hours on, which hurt, but ultimately made the (un)finished project more enjoyable.

This version was complete and playable. It had fun aspects that could be developed further later on, and I was satisfied with the released build.

Overdoing it in Version 0.2

In November 2022, I released a new version. I had worked on it for 2-3 months, and had expanded the game out extensively.

I didn't do another 2-week/20-hour sprint, which resulted in an unfocused development cycle. This update did add a whole host of new features, including:

• An expanded map and camera controls
• Less abstracted game mechanics
• Better unit AI
• An AI director (and algorithm for spending resources)
• Vastly improved UI
• Physics-based vehicle movement
• New and improved models

This cycle was full of interesting and challenging work, but I made some massive missteps in this cycle.

Making Mistakes

During this development cycle, I didn't conduct any testing during those months.

This exasperated the issue of an unfocused development cycle. Without testing, I couldn't accurately determine where gameplay wasn't fun, where mechanics were confusing, and where bugs were that needed fixing.

I had made major changes to the way the game worked. Win conditions changed, resource allocation changed, enemy spawning changed, enemy decision making changed. All of these changes and not a single test to see if I was on the right track.

All of these changes and not a single test to see if I was on the right track.

The Journey of Physics-Based Vehicles

I also spent too much time on unnecessary features. Physics-based vehicle movement sounds cool, but I had to spend many hours to implement it. They then crashed into each other... a lot.

With them constantly crashing into each other, I spent another dozen or so hours building a collision avoidance system. This worked fairly well. I was even able to get them to merge into a rotary. Not well, but they were about as good at it as Boston drivers are, so it was good enough for me.

This feature was a massive time sink. And there were plenty more issues I would need to address. For example, they could be run off the road. If they were, they couldn't figure out how to get back onto it. They didn't even know how to reverse the car.

This all came down to 1 thing: Physics-based vehicle movement didn't add enough to the game to justify itself. Arguably, it detracted from the overall game.

Physics-based vehicle movement didn't add enough to the game to justify itself. Arguably, it detracted from the overall game.

Why Project Hermes is on the Backburner (Indefinitely)

Upon release of v0.2, I finally conducted a few user tests. I found that a lot of my ideas that were good in a vacuum were not good in practice.

I had reduced the amount of abstractions in the game mechanics, which worked really well in some areas, namely resource gathering and enemy spawning.

However, other areas were much less successful. I had added a "front line," where enemies would duke it out with your forward base (which you didn't control, but delivered supplies to). Players found this to be too confusing and put too much power in the friendly AI's hands.

Suffice to say, there were many issues with the game.

The (Possible) Future State of the Game

After v0.2's release, I had to take some time off of developing it. I've found it difficult to return to.

The systems design would require a major overhaul and several features would have to be removed completely. I would likely have to reevaluate the majority of the mechanics added in v0.2, and determine which were good enough, which needed an overhaul, and which needed removing altogether.

I would like to return to the project one day, but for the time being I think I'll focus on smaller scoped projects.

I would like to return to the project one day, but for the time being I think I'll focus on smaller scoped projects.

If you're interested in trying it out yourself, you can download the game over on the game's itch.io page. I'd love to hear what you think about it!

The Game as a Learning Experience

This project was extremely helpful in teaching me some key lessons.

Keep Development Cycles Focused

The first build of the game was stressful, but properly focused (at least most of the time). The second build was much less focused, which caused a lot of problems in the long run.

During both development cycles, I was working on figuring out a method of prioritization that worked for me. The second development cycle help me figure out the framework for how I currently prioritize, which is a mix of an Agile task board with a MoSCoW chart.

Limitations are Good, Actually

This is something that people say all the time: "Limitations bring creativity." Not only that, but deadlines bring, well... finished projects.

The first development cycle had a defined timeline, both in hours and weeks. While this created some challenges for me early on, it resulted in prioritization that brought the game to completion.

Every project I've built since has had more testing than this one did.

Test, Test, Test

I find myself repeating this over and over on so many projects. But on this project in particular, I ignored that advice and paid the price for it.

While Project Hermes is still in a relatively good state, I lost hours and hours of work moving in the wrong direction.

The good news: every project I've built since has had more testing than this one did.

Developer Logs

Why Changes Needed to be Made to Project Hermes

A deep dive into what changes were made in v0.2 and why.

Major Update – v0.2 Out Now!

Changelog for the major changes included in v0.2

Minor Update – Version 0.1.1

Changelog for minor updates shortly after launch.

Version 0.1 Out Now

An exploration of the initial release, its challenges, and where to go from here.

Images

Credits