(CW: Death)
Hey folks,
Hope everything has been going wonderfully for everyone. Last month I managed to finally take a short bit of time away, but upon returning I was occupied with the passing of my grandmother. It was a difficult time for my family, and we still have tasks to tend to, but it was a peaceful passing and not unexpected. I’ve still found time to work when possible, though also being careful not to burn-out while juggling game-dev and helping my family.
On that, let’s focus on some of the cool stuff that’s been happening with Management In Space:
- Flight: A game about stuff in space naturally has things flying around. The prototype in Unity utilised physics objects to calculate all this movement, which works very well as it has a well crafted and dedicated system to do so. Godot, where the main build is being developed, also has one, but I decided to make my own system this time instead. The main reason is the same as whenever I decide to make my own version of a similar pre-existing system; control. I want the system to do exactly what I want it to do, in very particular ways, instead of being a general system.
Let’s take the Godot ‘Physics Body’; it is a fantastically detailed system with gravity, friction, bounciness, and of course collision. But none of that is needed in MIS; gravity is consistently zero, and because there is no collision there is no need for every object to have a Collision node, as well as no need to consider friction and bounciness. While there is no argument from me that both the Godot and Unity devs would create far more optimised physics systems than I, I know exactly what is needed for this project and only need to design that much. It means less is being checked and calculated which means simpler processing, and it leaves more room for me to directly understand and control what I need from the Flight system. One of the coolest parts of the Flight system is it can be applied to literally anything, even if it wasn’t originally designed to fly around. For example…
- Carrying & New Trading: This was a fun by-product of working on the Flight system, and is a big game-changer for how this build’s gameplay mechanics work when compared to the prototype. In essence; anything can carry anything. Like in the prototype, the main use for carrying will be Drones collecting Asteroids and dropping them off at Drills to be mined. But now, Modules can also be carried, not just by Drones, but by anyone. Let’s say you get attacked, and in the battle one of your coolest weapons gets destroyed, in fact it is so badly damaged it gets totally broken off your Station and now starts drifting away. Well, a Drone can retrieve it, reconnect it, and repair it! Because Modules represent both progress and power in a run, losing a Module that is a major part of your gameplay strategy or combo could potentially be a run-killer, even if you survived the battle. The plan now is that some Modules can be retrieved and reattached, but you need to work fast to do so. This also opens up the potential for some hostiles to attempt to steal parts of your Station, but also for you to capture other Entities!
Additionally, this also corrects a small issue that I personally had with the prototype; why can you buy massive Modules from such tiny Traders? Obviously this is really a non-issue; it’s a video game and we expect it to work this way when we play games. But I kept thinking about it anyway, and came up with an idea that also gives players even more agency over their runs; what if players pre-ordered Modules from Traders that were in the sector, and those Traders then warped on by, dropped off a ‘Module Package’ and left? These packages would be collected by Drones and the player then selects where to build that Module on their Station! This feels more realistic, but also means the player can select possible Modules from a short-list instead of deciding yes or no from single docked Traders, which means if they want to focus on a specific type of strategy, there is more chances for them to pick the right Modules that fit that strategy.
- Behaviours: So this is what I am currently in the middle of working on, and it is going really well! Already tested on some Drones and it’s delightfully clean and accurate. Essentially I am working to implement a “State Pattern” into MIS to control Entity behaviour (things that the player does not directly control themselves). I’ve created Behaviour States that, when loaded, issues a predetermined set of Behaviour Actions, and then stores a handful of Conditions. When one of these Conditions is signaled, the Entity loads the appropriate next Behaviour State and the cycle continues. For example; a civilian Entity spawns, and loads the default behaviour to fly to the Station. When it gets close enough, it loads the behaviour to request docking and wait a short time. If it gets docking permission, it flies to the Dock, otherwise it flies away. The system also allows for behaviours to be forced on, for example if a hostile ship approaches the civilian, the game will check if the civilian has the “Flee” flag, and if so, will inject the “Flee” behaviour into the civilian. In the prototype, triggers and events were handled by a similar (albeit jankier) system, but all Entity behaviour was hard-coded into the game. By separating Entity behaviour, it becomes a system that can be fully customised and updated without direct changes to the code. It also means that modding becomes easier, with the goal being that a simple JSON file, maybe even one created by a custom modding tool, is all that is needed to mod in behaviour changes.
Anyways, that’s it from me for today. I look forward to updating y’all again soon about how this project is coming along. Till next time, all the best! ^^