Woo Happy New Year~! ⸜(｡˃ ᵕ ˂ )⸝♡
Hope everyone is doing wonderfully. After a short breather at the start of the year, I jumped back into work full-swing making progress with Management In Space. A lot of the work has been back-end stuff as I rewrite the code structure, but I’ll try to cover some of the important stuff~!
- 2D Conversion: I mentioned last time that I was planning to shift the game from 2.5D to 2D. This was unfortunately never going to be a simple one-button click, but it has been going really well! I speculate I’m about two-thirds through the conversion, however I’ve also been massively fixing and optimising the code as I go along. Many of the classes have been rewritten and simplified, especially how space objects are managed and interact with one-another. By the end of 2025 much of the base game had been built, but the growth in my abilities across the year was obvious in my code. Combined with some of the changed concepts from the start of the year and the rushed concepts at the end of the year, there was too much inconsistency and unnecessary script throughout the project. I’ve spent a good deal of time formatting everything, condensing and optimising functions, and working to ensure classes are more generic and less dependent upon one-another. All of this to to strengthen the foundation of this game as I work towards a public demo later this year, as well as future-prep for community modding down the track one day~
- Flight Physics: AGAIN! Yes flight was updated again! This was done for two reasons; the biggest was the shift to 2D; while I could have copied much of my flight mechanics over, working in 2D gave me a chance to fix the system up. Previously, while many of the flight functions were relatively generic (convert Target to Velocity etc), this was all pre and post calculated using per-behaviour functions, creating a clustered mess of a class. The second reason is pivoting to using Godot‘s own physics engine instead of my own Flight Manager. I’m very happy with my flight systems, and mechanically they worked really well, but by utilising Godot‘s own physics I’m able to simplify much of my code, push basically all the flight calculations to the physics step, and also make the most of extra features the engine provides such as impacts and gravity wells! Flight is no longer a dedicated controller class, but a handful of short functions on the generic Space Object class coupled with a targeting class that cleverly and speedily tracks your flight targets.
- Tags & Behaviours: Currently what I’m working on right now! Tags are a simple concept that allows assigning ids to objects. This means that if I need to check if an object is a Merchant for example, I can just look for the ‘merchant’ tag. I’m also implementing tags in such a way so that they can also apply ‘Attributes’; rules that modify how an object or the station function. For example an object with the ‘armoured’ tag can have an attribute that reduces kinetic damage by 50%.
Tags work in tandem with the new Behaviour system as well. To preface, behaviour systems have always been a bit janky in prior versions of this game; the prototype had all the behaviour hard-coded, while last year’s alpha demo hard some flag-checks hard-coded alongside a mess of loadable ‘states, conditions, and actions’. Using states was actually good in theory, but how I had implemented them was not; I was so focused on having an open-ended “everything is possible and adjustable” system that I was building this massive call-and-response network of scriptable behaviours with which every actor needed to have written for them. It was too much, and unnecessarily so. Recently, while researching options, I took a step back and looked at other games that had inspired M.I.S., and Noita stood out. Every actor is adheres to the same behaviour structure, but makes different choices based on their faction and tags, and this is exactly what I needed to do!
Behaviour is now controlled through a network of States, not too unlike before, however now each State class defines it’s actions and conditions internally, much like a ‘State Machine’. Additionally though, it will frequently check it’s validity state, and call Success, Fail, and other In/Out triggers, closer to how a ‘Behaviour Tree’ works. All actors, unless told otherwise, will load the default initial state, and check it’s own Tags and Controllers to check the best path of behaviours to take. This new system will make writing new behaviour simpler, will ensure all actors are adaptable and can read and act according to changes in situations, and will still allow me to make custom behaviours for unique cases.
Looking back over my recent change-log, there have actually been way more changes than what I’ve mentioned here, but everything is still very back-end right now. I will say though Duncan has returned to his work on the game’s soundtrack, and Grace, the artist from roll, has rejoined me, this time as character designer! I’m hoping to have many amazing characters that you can chat with, befriend, fight, date and betray! (wait, date?! (˵ ¬ᴗ¬˵)) I’ll leave you with Grace‘s first draft of redesigning Arala, the non-binary administrator and the first character you talk to while they hack your ship and force you to become a Manager (in space)!
Till next time, all the best~! ^^
