It took me longer than an hour.This week I spent most of my time on design thinking.
Exoloper has been built using a bottom up method: build out the minimum viable product, and then add to it as I go. I personally prefer this approach as it allows me to quickly build the core loops of the game, and then design around those. This means though that often I'll come to a point where I need to design a concept, and simply stub it out gracefully. One example of this has been handling objectives in the combat scenarios, up until now the game simply checked to see if either a) all spawned enemies were inactive, or b) the player was inactive. It'd then boot you back to the campaign with little ceremony, not really conducive to feeling like you've accomplished much of anything.
So the goal this week was to figure out how this is all actually going to work. Helpfully listed in my task manager as :
It took me longer than an hour.
The basic idea is that each Point of Interest on the campaign map can have an array of "scenarios" tied to it. When the player begins combat, one is picked at random. Each scenario lists out the enemy types, quantities, an objective type and finally the actual map to load. Each map therefore needs to support the kinds of objectives available for each scenario. This seperates the concerns of map building, scenario definitions, and enemy compositions.
So for example, a Campaign POI might have a scenario labelled "destroybuildings-tanks-difficult" or "destroyforces-exo-verydifficult" or "capture-convoy-easy". each of those will determine the kinds of enemies that spawn into the level, or which buildings are active. For instance, the targeting capacity for buildings is only enabled when "destroy buildings" is active.
checklists that are explosively satisfying to complete
This week also saw me adding some basic UI elements for objective UI, and for tracking components that aren't just enemies in worldspace. Turns out sometimes things are as simple as you'd expect. Target buildings are handled the same as units, controlled by the same systems (albeit without some functions, like movement... though.... moving building boss you say?....) So, as long as they get initialised along with all the enemies, boom, target icons. (keen eyed readers will see an exo-paper-doll icon next to the unit. That's just me being lazy, each "base-unit-data" entry has an optional icon that I've not yet set.)
One thing that came about whilst testing objective gameplay this week was that when you completed all objectives, as I said before, I'd simply boot you back to the campaign screen (or main menu for quickplay), and this felt jarring. I didn't want to throw UI in your face, and while I'd thought of adding some animation or something, that'd get tiring pretty quickly. Instead, I added "exits" to the combat space. Each level now has an array of entrances and exits for the player, and now, once your objectives are complete, you may leave.
The image above has an important clue though: You can leave before your objectives are complete. I think it's important to have retreat as an option in games. It's rarely ever explored, but it's a critical component of any conflict. Sometimes it's better to leave, lick your wounds and try a different approach, or to just leave that particular conflict altogether.
Going back to where I started this post, everything is designed from the bottom up, so right now, yes you can leave a mission, but the campaign only cares that you're alive after returning from a mission, so for now that still counts as a win, and the campaign clears the combat status of that POI. Another stub of design to follow for another week.