Plane Hoppers Post-Mortem (Originally published on Wordpress)

Here’s to a second more serious attempt at keeping an actual dev log. First I’d like to talk about my previous project – Plane Hoppers – and some lessons I’ve learned after moving away from it. I’ve tried to order my stream of consciousness into a legible structure, hopefully the reader can get something out of it.

Sitrep

It’s been a while since I’ve abandoned Plane Hoppers. A scope originally planned for a team of four became unfeasible to finish with a team of one. Not just in coding terms but even in the sheer amount of assets required to get to a playable version of the game. The goal of the game was to be a dungeon keeper clone with the rules of a rogue-lite: one life per run; random elements; resources restricted to that run; side-grades to vary gameplay from one run to the next.

All work and no play

It was a simple idea. Yet it wasn’t the idea that made the project unfeasible, but the conditions we added: 3D models; real-time lighting; destructible terrain; AI players; multiple factions; the list goes on. When the game was abandoned, I’d finished implementing the basic RTS commands (move, stop, patrol, attack, attack-move, hold position, build, gather), pathfinding in dynamic terrain, preliminary terrain generation using layers of cellular automata, and object pooling. After months of work we still had no gameplay to show off, except for the 3D placeholders seared into my eyeballs.

Get to the Fun-zone

This leads me to my first lesson learnt. The biggest demotivator was having no gameplay to show off. Don’t get me wrong – it was fun to watch units seemlessly slide around obstacles and each other in a way a 90’s RTS would envy – but pathfinding alone doesn’t make a gameplay loop, at least for what we were trying to accomplish. Even then, getting to the gameplay loop means nothing if you spend 80% of the loop not having fun. So I want to make my first objective more specific:

Prioritize a path to the fun-zone.

The sooner I get to the fun-zone, the sooner I can start getting actual feedback from non-technical people. Most people don’t care about how you saved a few milliseconds on pathfinding by caching paths and subdividing the world into sectors. They will nod and act impressed out of respect because they have no frame of reference to compare to. On the other hand, people know when they’re having FUN. They’ve had fun before. They might not be able to verbalize what is fun but they sure as hell can answer the question “Are you having fun?” with a yes or no answer. This also means I can have my own fun in testing my own game sooner which, personally, is a huge motivating factor.

Look at the size of that thing!

The second problem ties very tightly with the first: scope. We thought of all these cool features and the very idea of having these features motivated us to work harder for them. Unfortunately this is a double-edged sword. That motivation quickly shriveled as we realised the absolute size of this unit of a game. All those features we were excited about getting into our game never felt further away than when we were 3 months into the project and had absolutely none of them done because we were so bogged down in laying down the fundamentals.

The less I needed the better I felt

Do I really need to have 4 different resource types? Do I really need to optimize for 500 units on a screen? Do I really need 5 different terrain types with their own hazards and creatures?

These are actual things Plane Hoppers was planned to have. I chose these three questions intentionally because each one represents a different axis of complexity that a new feature might add to the game (not a comprehensive collection, but the ones I noticed the most).

The first one is trivial in terms of man-hours required. Perhaps a few days’ work adding assets for your resource type, voice lines to notify you of shortages, modifying your terrain generator to consider the new resource type, and so on. The cost comes in time required to balance and design the resources to fit the game.

The second is a technical complexity. This is something you either recall on past experiences or you do your research. The cost of this comes in adding complex structures to your code to reach an efficiency that might never be required in an actual game. This brings us back to Donald Knuth’s famous words:

“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”

Sometimes ‘good enough’ is just as good. The hard part comes in deciding where it matters, which is where you consult your friendly neighbourhood profiler.

Make it work, then make it fast.

The last question dips its toes in everything but I’d like to focus more on the increased asset load it brings with it. Even getting enough assets for a single terrain type felt like a herculean task. This leads me to a couple of new objectives:

One of everything, until everything is done.

What’s next?

Hopefully all this rambling was useful to someone. I’ve been working on Longsword on and off for a couple of months now and I’ve been ramping up hours recently with covid-19 wrecking the world. I’m really excited to be working on this project as I’ve gotten farther than I’ve ever gotten before in anything of this sort (at least when it comes to a playable demo). More details to come in a future post.