Developer Log #17 :: Performance
There have been a lot of new people playing Mercury Fallen over the last week which has lead to some great feedback. The core concern most users have, at the moment, is performance related issues and crashing.
We’re getting closer and closer to the alpha release of the game, but it’s taking a little longer than expected. I’m working to ensure there are solid core features of the game in place before releasing the alpha. There has been a lot of testing and I’m working on some final features and bug fixes.
Saving The Game
One feature that has been highly requested from the demo feedback is the ability to save/load your game progress. This is currently being worked on and should be ready for alpha release. Saving progress is certainly important and ensuring that it does so reliably takes some time. The core features of save/load is in place and I’m just working out the bugs.
Stasis Capsules
One exciting new feature are the stasis capsules. Your colonists now start in stasis capsules which can be opened by selecting them and clicking open. Additional capsules have been lost and are scattered across the map for you to find while expanding the facility. This provides another means to get colonists.
There has been a lot of changes in the game related to resource requirements for construction projects as well as speeding up some of the early mining/construction in general. Stay tuned for more updates.
The alpha version is coming along very well and will be available very soon!
The new colonist behavior system has been a lot more work then I originally thought it would be. I’m not entirely sure why I thought I could rebuild the entire behavior system in a short amount of time, but I tend to be a bit too critical of my own abilities. The new system is coming along great and I wanted to share a bit more information about it.
After receiving quite a bit of great feedback from the alpha demo I’ve been focusing on resolving issues with the colonist behavior system. This is a daunting task as I believe it will require a re-write of the current system, but thankfully most of the core systems in the game are fairly modular so it should be straight forward once I have a solid plan.
A lot of the core systems for Mercury Fallen are in place and a lot of my work has been focused on getting in the game play content. This, as always, is proving more of a challenge than I originally thought, but proper planning goes a long way. There has been one lingering system that I had been avoiding as I thought it would be a real challenge, but, as it turned out, I managed to get it done pretty quickly.
Up until now the UI programming for Mercury Fallen was relatively per interface/object. I have some top level classes that I made to inherit from that define a window panel consistently, but the UI for the different interactive objects in the game were all individually crafted which meant a lot of work if I’m creating a new object with a new type of functionality. This isn’t a problem with some games, but I wanted a system that would grow and adapt as i continue to add more content without having to re-write a lot of the same code over and over again.
The other concern were certain UI elements that are just naturally consistent across different types of objects. For instance the ability to deconstruct or if the object needs and is receiving power. What I needed was one window to rule them all. So to speak.
Components
I had been thinking about a unified UI window for a while, but wasn’t sure how I wanted to structure it. The underlying data, however, already implies how it should be visualized.
The custom component infrastructure that I wrote already shows nicely how an object is represented and I just needed to reflect that in a user interface. Each entity in the game is mostly just a container for components which means each component can simply be a section within the UI, where applicable.
Not all components need a UI, but it could be good for debugging.
Modular UI
So now that I had an idea on the direction I just needed to visualize it. I figured the best way was sections and elements. Each component could define it’s own section in the interface and create the UI elements it needed to handle user input or just display information.
So as we can see in the above image we can visualize the components of the selected entity and we don’t really worry specifically about what it is we selected. Each section has it’s own controller which handles the logic and data binding to the component. The main window itself is just one master script/prefab for every object in the game. The master window determines which sections to add based on what components the entity has.
I spent this week connecting in various components in to the new UI system and so far it’s all going pretty well. It means more work now, but the trade off is that it makes adding new objects and UI functionality easier later as I continue to add new machines/furniture to the game. This new system also more flexibly allows me to add additional relevant information for the player to see when they click on various objects in the game.
Building a flexible attribute system can be a challenging task, but the first step is always understanding what it is that you want the system to accomplish. I had already cobbled together a system for health, hunger, energy and mood, but it lacked ability for colonist attribute effects.
I wanted to be able to tack on effects like sickness that might temporarily effect health and mood temporarily until the effect goes away. I wanted a flexible system that would allow me to quickly tack on new effects without having to tie it in to the underlying values each time. I often confuse design problems for programming problems, but I think I have a good infrastructure for colonist attributes.
What Are Attributes?
This really depends on the project, but I originally thought things like health, hunger and energy were attributes. This was true in a general sense, but lacked the detail I needed for adding attribute effects. Hunger, for instance, is actually three different attributes relating to its current value, max value and rate of change over time. Dealing with these values separately allows for them to be effected separately as well. An attribute is simply just a means of storing and manipulating a value via attached effects.
Attribute System
Health, hunger and energy become containers for attributes and each attribute has a list of effects that manipulate the underlying value. The colonist, via the component system, has Attribute Controller components attached. Each controller has a list of attributes that it monitors and each attribute has a list of attribute effectors that effect the final output value of the given attribute.
The attribute controller monitors its attributes and can make decisions about what to do under different circumstances. For instance health is simply current and maximum attributes and the health controller can let the colonist know that when the current value is 0 then the colonist should be dead. The attribute controller is both the container and what gives the attributes meaning.
Each attribute has a unique identifier and a list of attribute effects. We can get the final value of the attribute by adding/multiplying the effect values to the base value of the attribute. The attribute controller can then get this final value and never needs to know about what effects are currently being applied to it.
Attribute effects have a single attribute that it effects and can be permanent or temporary.
Practical Application
The above image illustrates the HungerController and its attributes. The HungerController uses the attributes to clamp the hunger_current to the hunger_max and allow hunger_rate to effect the hunger_current value. The hunger_rate, by default, is a negative value which decreases hunger at a fixed rate over time.
In this example I’ve attached an attribute effect which temporarily turns hunger_rate in to a positive number which will refill hunger_current. This attribute effect would get applied when the colonist eats some food.
Conclusion
I’m pretty happy, so far, with the result of the attribute system as it allows the easy creation of new attributes and effects. As with most everything else attributes and attribute effects are created in external XML files so that I can add new content without touching the code base. The only thing I can see adding at this point would be some sort of attribute effect group that would allow multiple attribute effects to be applied all at once.
Over the last couple of weeks I’ve been working on some new world generation as well as a new crafting system. I can’t seem to make up my mind when it comes to the world generation, but it’s a pretty important aspect related to the starting conditions of the game.
Starting Conditions
After reviewing a bunch of information related to what I have and what I originally intended, I realized that my initial plan for starting wasn’t going to work. The game has just naturally evolved in a different, and better, direction than where I started with my design document.
I originally wanted the game to start with only 1 colonist and grow from there, but given the way professions, and the new crafting system, work, it would mean a lot of micromanagement juggling on the part of the player. While the initial part of the game should be fun and exciting, I don’t think juggling professions is what I had in mind. This means that the starting condition will need at least 2 or 3 colonists as well as basic starting supplies. This is fairly standard for this kind of game and, after evaluating the other aspects of the game, is not a place I need to be unique.
World Generation
I keep poking at the world generation code to make it a bit more configurable. I did finally add in a world generation screen so that I can test various seed values. I keep bouncing back and forth between heightmaps and cellular automata. The latest iteration of the world generation is using layered cellular automata which I’m using for ore distribution. There is now iron ore, copper ore and anthracite in the map. There is also a nice mix of caves, but I still have to add water back in.
Crafting
In an effort to better unify the crafting system I re-wrote the whole thing. After setting up crafting for the cook station I realized that cooking and smelting worked differently. Ideally I wanted a better way to handle crafting in general that was more consistent across all stations.
The new system is more simple and straight forward, but allows for more management. Each craft station has recipes that can be queued up for crafting. Once a recipe is queued for crafting the appropriate colonist, based on profession, will gather the materials and craft the item at the station. The colonist will repeat this for however many is in the crafting queue for that station.
This means all craft stations work the same, but have different recipes. It also lead to a new profession. I’m also planning for additional recipes, for existing stations, to get unlocked via research.