Developer Log #12 :: Just Trying To GOAP

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.

Read more “Developer Log #12 :: Just Trying To GOAP”

Developer Log #11 :: Goal Oriented Action Planning

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.

Read more “Developer Log #11 :: Goal Oriented Action Planning”

Alpha Demo 1.1 Update

I’m very excited to announce a new version of the Mercury Fallen Alpha Demo. This update should hopefully resolve a lot of the game breaking bugs as well as add several new features/improvements to the game. Please contact me and let me know if you find any bugs, have some suggestions or just want to say hi.

Download At Itch.IO

Read more “Alpha Demo 1.1 Update”

Developer Log #10 :: Fog Of War

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.

Read more “Developer Log #10 :: Fog Of War”

Developer Log #9 :: Research

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.

Developer Log #7 :: Modular UI

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.