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.
Mercury Fallen development never stops and I’ve been working on adding robot workers and other new features. Robot worker have always been part of the original plan for Mercury Fallen and I’m excited to finally start adding them in.
Robot Workers
Robot workers are cute and cuddly mechanized workers that will do your bidding while your human colonists focus on more important tasks. Worker robots function similar to human colonists, but are not able to do all the tasks a human colonist can.
I’m still working on implementation, but the plan is for robots to consume power at charge stations. They don’t require food or happiness, but make for great miners and builders.
Job Roles
A highly requested feature and something I’ve been working on is the ability to choose multiple professions instead of just one per colonist. Professions are being replaced with Job Roles which function similar to professions, but you can now select multiple job roles such as having a colonist that can do both mining and building.
A new job role also comes in to play with hauling. This allows you to toggle on/off the ability for colonists to haul items to storage that are left on the floor. This may be a task best suited for your new robot workers.
Colonist Colors
Since professions are being replaced and professions previously had unique colonist outfits I’ve switched control over to the player. Manage job roles and set custom colonist colors to manage your colonists how you want.
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!
With the latest release of Mercury Fallen I believe I’ve stabilized many of the core issues players had with the game. Creating a completely new colonist behavior system may have been overkill, but I wanted to ensure that the system would expand well as I continue to add new content and colonist interactions.
I’ve been working on Mercury Fallen for over a year now, and it has only recently reached a point where players can start to enjoy the game. I’m very excited to hear about player experiences and feedback as it provides me with good motivation. There is more content and updates coming for Mercury Fallen as I transition over to an early access alpha release.
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.
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.