The phrase that started this whole project was "Exploration as progression." Many games give the player access to new areas as they get farther along, but that's "access to exploration as a progression reward", and I want the act of exploring or finding new things to be the progress that gives you the reward. It's not immediately obvious how to achieve that, however. Sure, you can take the percentage of the map you've explored, or, in the case of an unlimited map, a measure of how much land or how many places the player has been and give rewards based on that, but that linear system fails to capture the essence of exploration to me, which is the joy of happening upon unique or unusual things.

How, then, do I put rewards in place that do reflect the uniqueness of what has been discovered? I've mentioned in a previous post that beauty makes exploration satisfying in itself, and the player can be the judge of how interesting what they have found is; but that's only one kind of exploration, that of seeing new places. "Exploration" to me also includes doing new things, pushing the limits, the "what happens if I..." or the "do you think I can...", and that's not to mention using the other four senses besides sight in a new place.

It would be difficult for the generation algorithm to recognize features that a human might consider unique, unusual, or otherwise interesting. Even if some other post-generation algorithm tried to determine that, it probably wouldn't really feel right - a game must be careful about its use of procedural generation. I've played many games where too many pieces are procedurally generated, and so nothing feels unique. As much as programmers try (at least with traditional, non-AI methods), we cannot beat the feel a human designer can achieve for items, enemies, places, etc. My point here: to reward exploration of interesting features, I need to manually design both the trigger of the reward and the reward itself.

One system for these rewards in EXO has two pieces, "Augments" and "Effects". Augments are equippable, with only a limited number allowed to be active at once. Effects happen automatically upon unlocking them, and hence an unlimited number can be activated. Finding or doing something unique may trigger an Effect or unlock an Augment.

When you achieve something, you'll get a notification like this.

These triggers can be any number of things, like surviving a fall on a planet with very significant gravity or discovering an object with a complicated orbit. Variation in generation should mean that when you're starting out, you might unlock quite different Effects than your friends (or than your previous playthrough). Exploration is random and I want luck to play a significant role in the player experience.

However, I quickly realized that having only the random progression through Augments and Effects felt too arbitrary. I had basic capabilities, like the strength of your scanner and the temperature range of your spacesuit tied to Augments. But this way, if you, by chance, find a highly unusual planet in your first system and unlock a powerful Augment, it might basically skip you forward - and some Augments that could have been exciting will not be. I realized that I wanted the, um, effect of my Effects and Augments to provide a more lateral and branching progression, where the player receives some feature or ability that they can probably use in certain situations, but it's not a straight increase in power.

With that, though, some sense of progression was lost. I didn't feel like I could work toward anything, since it was more or less random whether I would find something that would unlock an Augment. I needed to augment my Augments (heh, that one was on purpose) with a more traditional linear progression system - money, items, and equipment.

Exploration still needed to be the means of progression, though. Rewarding the player with items for exploration is not too difficult - "chests" (in this case, lost ship cargo and the like) have been used in games forever. But, item-hunting is not the spirit I want for this; the "hope I get lucky" feel should be for "hope I see a cool thing". But the game should make you want to see a cool thing because it will give you a reward you want - and if it doesn't happen to unlock an Augment or Effect, I don't want there to be too much disappointment.

Eventually I landed on a borrowed feature from Elite Dangerous, where just by going to a place and scanning it you get "Exploration Data", which can be sold. So money (perlite) became a thing. This way, rarer features can be worth more, and every time the player finds one they get a reward. They also have to find an alien race that will pay for the information, but that is relatively straightforward. Of course, money that can't buy anything isn't money! So I placed the main, more or less linear progression in items that could be purchased. These can be straight power increases, unlike Augments and Effects typically, and they control all sorts of basic capability, including the scan strength and temperature control mentioned previously, as well as your ship's jump distance, cargo size, your time on non-breathable planets, and more. Some items still contain tradeoffs - which if you read the post last week, you'll know are important - but items of a given type are organized more in "tiers" of power, with a few tradeoff variations in each tier.

Ship module loadout. Can you guess what each item is just based on the icon?

It's nontrivial to actually design all of these items that make up the linear progression, but I won't delve into the detail of those decisions here. I'm constantly considering the ways to feel progression since I have loved RPGs for those little level-up dopamine hits for years - so you can be sure that EXO's progression system will be at the very least well-thought out.


  • Yukkafuzz

To make an exploration game interesting poses some new takes on traditional challenges in game development. A combat-focused game has to find a way for not just the first 10 or 100 combats to feel exciting, but for a player to still relish a battle when they've done thousands before. You can create a great variety of enemies, and give the player a long list of skills, items, whatever it may be - but as they say, quality over quantity. It doesn't matter how many attacks the player can make if each one does the same damage and has the same effect (different animations really don't get you that far). Even if you have a bunch of different attacks but the best one or few for all your enemies are the same, combat's going to feel very stale very soon. A better design would have a few attacks that crush certain enemy types, and don't do much against others, so people will have to search for the optimal strategy or face a tougher fight. But even better is if the player can succeed with several different strategies, each with their merits and problems. You need tradeoffs.

This principle applies across most if not all types of games. Even the best story-based games typically include choices that have meaning, decisions the player has to make weighing the pros and cons. So what does that look like in EXO? The most basic tradeoff is choosing to go to one system over another. Galaxies are set up as a huge set of discrete points of interest, where each one can be a solar system or another kind of object. Each time the player is ready to travel, they have to choose their next location from potentially hundreds of thousands of systems(!), and in so doing, they lose their time and some fuel. For a decision to feel meaningful, there has to be a cost. Just losing a little time as I go doesn't feel like enough cost to make me value that choice, and so the fuel is a little extra incentive. Also, systems that are farther away cost more fuel, so that's an additional factor players can consider. But if the only thing you have to consider is fuel, now there's just an optimal choice, where before there were a bunch of same-feeling options (read: both are bad). To make this feel like an impactful choice, players also get to know just a little about the systems they scout out as options. A point will tell you maybe "Multiple star system" or "rogue planet", or "Unrecognized scan signature" if the player has never been to a place of that type before. It might be worth it to travel a few hundred light years for an unrecognized signature to some, but others might prefer to conserve their fuel and explore the local region.

You might see an object like this. And only a light year away!

Of course, that's not the only choice players get to make. In the past week I have been refining the experience for investigating a derelict ship. Now, since this is not a AAA game, investigating is not walking/jetpacking around, flashlight out, exploring the darkness (it's hard to make a dead spaceship look and feel awesome with few resources). Instead, it's an opportunity for meaningful decisions. I had in mind three things that could be done with a derelict: check the ship's logs/computer, loot the cargo hold, and salvage the remaining parts. Obviously, if the player can just do those three things every time, they will, no interesting decisions involved. I had to make it matter which you chose to do, and in what order.

And so the security system was born. I wanted it to be possible to do all three activities, but not without risk. The ship computer, now, does not just give up its secrets for free; you have to hack it to obtain the information locked inside. But, if you mess up (i.e. get unlucky) then it could destroy the cargo, or even the entire ship! A number of other consequences could also occur - so should you hack, or not? As in the navigation example, giving the player some information can help make the decision feel meaningful. If they know nothing about their chances of success or anything else, each player will decide exactly once whether they are going to hack ships or not, and do that every time they find a derelict. So, the player is told the difficulty of the hack and how severe the consequences are for failing, and they can make their decision of "is it worth it?" The ability to preview the gain from hacking can be unlocked a little later on, making the decision potentially even more interesting. But that's for next week's blog on progression.

Returning to the main tradeoff here - which activity to choose at a derelict - the computer security is interesting in itself, but simply incentivizes the player to do the hacking last. Salvage the parts, get the cargo, and then try hacking the computer. There needs to be more.

Enter... locked cargo! When I first was designing this, I had the cargo unlocking just like the computer hacking - some difficulty to unlock, some negative consequences when failing. But as I mentioned with the combat game example, reskinned versions of the same thing are less interesting than entirely different features. After some brainstorming, I settled on an item lock. Simply put the item it needs in the slot, and the cargo is yours. How does this make a tradeoff? Well, it doesn't, if you have the item in your inventory. Unlock the cargo already! But, that's a feeling of getting lucky that I want to include. The true tradeoff is when you don't have the item, and you would have to leave to go acquire one. In some cases, you might not even recognize the item it's asking for (as you can see in the image below, you're given the icon of the item to find). But if you do, maybe you know it's easy enough to get, and you can leave, get one, come back, unlock the cargo, and then salvage or hack. If it's not that easy, though, maybe it's worth risking destroying that cargo to get the other resources now.

User interface for investigating a derelict ship. Trying to fit a lot of information on one screen while keeping things digestible.

This way, it's a decision whether to hack first or hack after you've found the key and unlocked the cargo. Next, and last, is salvaging. This involves some tradeoffs in itself - use a rarer and more expensive salvager for a higher material yield? Try to keep the part whole to attach to your ship? (See the buttons in the top right of the screenshot.) But, I also want it to affect the other two activities in some way. For the cargo, I took some inspiration from "realism" (that is, imagining logic applying to my space fantasy) and decided that salvaging the fuselage would destroy the cargo, guaranteed. That gives another "resources now, or potentially more later" decision. It's not an amazing tradeoff, but I can imagine a player trying to salvage the part if they can attach it to their ship. This way, it has the additional consequence of destroying the cargo if you fail to keep the part whole.

Just one piece of interdependence left, and that is how salvaging affects the ship computer. To be honest, I was not sure how I wanted this to work, but just in writing this post I have decided to make each piece of the ship sort of "contain" some of the ship computer, so the more intact pieces, the more exploration information you can gain from hacking. In this way, hacking first has the highest risk, since the whole ship might be destroyed and you can't salvage nor loot cargo, but it also has the highest reward: getting the most exploration information, and getting it now.

These tradeoffs, risk for reward, some now vs. (potentially) more later, higher investment for higher returns - reflect real-world decisions we have to make, which lends EXO's decisions an impactful feeling, and offers the opportunity for different playstyles to manifest based on personality (or on the whims of your game-playing self). The two features I've explained here in some depth are just some of the tradeoffs you can expect to encounter in EXO, but I'll reserve the rest for you to learn about when the game is eventually released!

  • Yukkafuzz

When creating any large project, it's hard to know all the details up front. Think about redecorating a house. You have an idea of what the end product looks like - maybe the large furniture locations, and the theme of different decoration areas - but you don't map out in advance where every painting and knick-knack goes (or at least, I don't). Some items might end up not having a place and being thrown out, and you might end up missing something you didn't know you needed. You uncover, or, more accurately, decide these details as you start moving stuff around. You placed your large painting in the living room thinking it would be a good spot, but as more things make their way in there, you realize it would be much better placed in the den; so you have to move it again. I call this extra work "paying technical debt".

In programming, and for EXO in particular, just as in the home redecoration project, design - that is, thinking ahead - can only achieve so much progress. I can think all day about how a certain patch of code should be set up, but I can never come to a definitive conclusion to exactly how it should be designed (for a sufficiently large patch). Mind you, I'm talking here about the design and ease of use of the code, not of the game itself, although the two concepts are related. The better the code design, the easier it is to change the game design. Granted, changes to the game design that you've already made also takes extra work - I guess that would be non-technical debt - but it feels less like I owe something.

So, instead of thinking all day about how it should work, I frequently "just go". I make my code with the desired end functionality in the first (or second) way I can think of. This way often results in code that I can only describe as "jank". In other words, I have incurred technical debt. Even while programming it, at a certain point I know I will have to mostly or entirely rewrite the files related to certain features. To elaborate a bit, I want to try to explain my process with the item system, which I was working with this week.

A long while ago, when no item system existed, I figured items would have some common elements like needing a name and a description, and maybe a cost (but would that be for every item?), but for items to feel different and not just be the same thing reskinned dozens of times, they would need a lot of different functionality. So I made one superclass for items that contained those common elements, and a bunch of subclasses, each of which would be a specific item. But after working with that a bit, I realized I was making an entirely new subclass for every item and then just filling in some properties (the name, description, etc.), and not creating that much different behavior like I thought. (Each class has its own file, so you can see how this sort of feels like a waste.)

Instead, why not have just one class for items, and when the game needs to create an item, just have that other code fill in the right properties? Well, in the back of my mind I was thinking that I would need something to predefine item types - every Basic Salvager item should be identical, but I shouldn't have to go find the place where I created one and copy/paste - but I wasn't sure where to put that predefine code and how to make it mesh with the inventory code I had built around my first system. So I swapped to the one-class approach anyway.

Why is it that I can only make progress this way? Is it not a waste of time programming something when you know you'll rewrite it? Well, it is definitely out of necessity. I prefer to be able to design code ahead of time; however, as I mentioned earlier, for sufficiently large sections, it is impossible to know exactly how I want it to work up front. I can imagine the uses of the code base, but I can't actually apply it and find out how easy it is to use. I knew I wanted to be able to randomly populate inventories, buy and sell items, etc. And I knew I wanted it to be easy to create new items. I just didn't realize how much of a pain that would be with my first ideas. But the "jank" version let me actually try the functioning code while I created more features. You can't build on top of a beam in the blueprint; you have to actually put it in. But you can use cruddy wood as long as you replace it later.

Using this code, it became more and more clear how it should be designed. The problem is, the more code I build on top of a first version, the more work it is to change - that is, adding features to this functioning code incurs even more debt. But, if I decide it's time for a redesign too early, I might just be paying to refinance my loan. (I would be putting work into a second version, and making all the code I've built on top of it work with the second version, when it might have to be reworked also.) Which is exactly what happened, although in this case it might have been necessary.

The current, and hopefully final, version of the item system shares a lot with the version I used for a long time, before this week. There are two parts to an item in an inventory: you have the piece unique to that item in that location, like the number of stacks or the amount of fuel in the tank; and you have the information shared across all items of the same type, like how much total fuel that type of tank can hold. The unique piece holds a reference to the shared piece, and so the game can get the shared information from the unique piece.

If it's not totally clear how that works, that's all right; my point is this. Changing around all the items to this system took some work - the more places I created items, the more work it was. But in the newer system, it was a lot easier for me to create new item types, and easier for me to create other code in the game to use the item system. That is - pay your debts so you don't have to pay interest. So maybe the refinancing was worth it.

But, as I said, it was not the final version, and the difference was this: all of the shared pieces in the previous version were defined in a class (that is, code), and now they are in a data file. It's the difference between


It's not that much extra to put in the code syntax required in the former, but in the latter it's entirely stripped down. Every character except for the newlines and the space between "salvaging" and "1" is pure content (unique to this item type), rather than syntax. Plus, data files have the bonus of being moddable. Hurray! It took time, of course, to write the code that reads the data file into a format readable by the main game code, but the main point of this post is the debt. Of which there was a significant amount, but it could have been a lot worse. I had maybe 30-40 item types in when making the switch, which meant I had to retype or copy/paste in the information in the former format into the latter 30-40 times.

You might be wondering how I put up with typing "item. ..." so many times in the first place, like why didn't I switch earlier, and it's because I was never making a bunch of items at once. I had a system that worked for my first five item types, and here and there I just wanted to quick make a new one, knowing that I was incurring more technical debt but unwilling to take the time out of whatever other feature I was on a roll with to write a new item system.

Eventually, though, with the item system and with any piece of code, once I start to use it a lot at once, I start wanting to copy/paste fairly large portions of code, or I feel like I'm rewriting the same thing with new variables (protip: whenever you're tempted to copy/paste code, don't. Make a function. Or a parent class. Or something.), I decide it's time to pay my debts.

I find technical debt a useful concept to think about as I consider "is it worth my time right now to fix this, or can I just use this old system one more time while I make this other thing?" a question which comes up surprisingly often for how long-winded it is. I paid a lot of debt this week, with the item system, the effects system, and a bunch of my UI elements, so hopefully I'll be paying a lot less interest and I'll be able to make quicker progress.

One Knight Studio © 2019