I’ve been developing Mercury Fallen for a little over a year now and while there is a lot more development to come I’m excited to announce that Mercury Fallen has reached Alpha! For those wanting to get in early and join the development of the game it is now available for purchase on Itch.IO.

(more…)

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!

It took longer than expected, but I’m happy to say that the 1.2 update is now available on Itch.IO! The biggest amount of time was spent on a complete rebuild of the colonist behavior system to fix up existing issues and ensure expand-ability as I continue to add new content and colonist actions.

There are a lot of other great fixes and improvements including storage containers can now be placed anywhere, better profession leveling, better hauling and a lot more. Check out the release notes below for a full list of updates and fixes.

Release Notes

Updates

• Colonist movement speed now based on athletics attribute
• Colonist profession level now affects productivity for some professions.
• Completely new colonist behavior system to allow for better behaviors as well as resolve issues with colonists getting stuck
• Builders now collect all items required to build an object before going to the object to build it.
• Builders will only collect items for a build project if all items required to build it are available
• Colonists moving items to storage will now pickup multiple adjacent items on the ground
• Changes to base profession productivity speed
• Profession level progress is now scaled. Higher levels require more experience/work in that profession.
• Items on the ground can be selected and will now show internal inventory with quantities.
• Deconstructed structures now drop the materials required to create it
• Deconstructed storage containers drop their content on the ground
• Deconstructing action now takes time to do based on structure durability
• Added deconstruction animation and effects
• Game starts with four colonists instead of three
• Added Feedback form to main menu and in game menu
• Colonists now have hair with random starting color.
• Darker lighting
• Minor graphic tweaks to Fog Of War and tile selection
• Minor UI tweaks
• Storage containers can now be placed anywhere
• Removed Storage Room Floor
• Storage Container inventory size increased

Fixes

• Colonists will no longer favor moving items to storage over their chosen profession
• Colonists should no longer get stuck in various situations
• Profession level progress should update with colonist info window open
• Colonists now correctly find and eat food items.
• Global Storage Facility Storage section should now show items stored in storage containers.
• Colonists profession level properly capped at 10

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.

(more…)

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.

(more…)

Now that I have a more unified user interface setup I can start integrating more of the core features of the game. A big part of a colony survival, of course, is research projects which unlock new place-able objects, recipes and more.

Research is handled by your colonists at the research station after choosing what research project to be worked on. I’m still working on ensuring a scientist doesn’t starve himself to death while researching forever. Research can be sped up by either having a higher level scientist or having more than one scientist/research station researching at the same time.

Creating the code implementation of the research system was fairly easy. The hardest part, so far, has been determining the order of research projects as some research projects have to be researched before others. The research technologies really define the flow and pacing of the game and I keep re-arranging things constantly trying to find the perfect balance. I think I just need to get an arrangement in and make a better decision after some external play testing.

The below image is not final and does not include all planned objects, but gives a general idea of the research break down. Using XMind to layout the technologies and it provides a visual way of quickly looking at the break down.

Lots of work has been going on with Mercury Fallen and I did a new video to cover some of the main and new features that are in development.

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.

Just finished up the first developer preview for Mercury Fallen which shows the game in action for the first time. The video doesn’t cover everything in there at the moment, but gives a good overview of the core mechanics of the game.

I welcome any and all feedback. 🙂

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.