Hey y’all! Hope February was as productive for you as it was for me! I’ve been working pretty much non-stop getting M.I.S. developed, as well as finally pushing and making progress with a side-hobby of mine; advocating for Flash Archiving for the NFSA! If you haven’t been following my socials, you may have missed that I recently co-wrote an article with Fergus Halliday of Multipler.AU where he interviewed me about my thoughts of Flash and games preservation. With the article public, I have begun reaching out to as many Aussie Flash devs and artists as I can to inform them about how the NFSA is accepting Flash content and to how to get involved. I’ve already since had incredible responses from numerous creatives, all very excited about this opportunity! This is something I’ve been looking forward to doing for a while now, and will be something I continue to work on and advocate for for many years to come. You can read more about my volunteer work and why I’m doing it here. Anyways, let’s talk about M.I.S.!
- Visible Area/Regions: Something I’ve wanted to include from very early on was ‘Visible Area’, the mechanic of having limited visible range. This wouldn’t just apply to the player, but to all Entities. I originally tinkered with the concept of ‘Sensor Range’, which would scan a circle around the Entity and detect all other entities within that range, but it wasn’t perfect. For starters; while a circle is the easiest form of hit-detection (is object B within the circle range of object A), the original implementation of this constantly checked for all Entities within range, though optimised by using ‘Chunks’ (you can read about how I did that here). After the 2D-conversion, I considered further optimising this by using an Area2D to act as the visible range and simply registering ‘Visibility’ by checking if any other Area2D shapes overlapped, and while this would have been both accurate and performant, it didn’t account for one of the new mechanics I had introduced.
Regions have been added! For now, this simply denotes areas of space that reduce ‘Sensor Range’, such as gases, asteroid fields, and so on, but these will be expanded to include various effects (‘Ion Cloud’ causing Shields to drain) and benefits (‘Asteroid Fields’ prevent building, but can be mined for richer resources). However, this meant that I couldn’t use simple circles to detect visibly anymore, as the range also had to account for variations in the surrounding regions/hexes. So, how did I fix this? ‘Entity Coordinates’! There is now a big list of all the Hex-Coordinates and all the Entities that are present in those coordinates. Every time an Entity changes Hex-Coordinates, it removes its reference from the previous coordinate, and the registers itself to the new one. If we want to check what Entities are visible in a Hex-Coordinate, we just check that list! Additionally, when an Entity changes Hex-Coordinates, it also updates its own Visible Area map, which is a list of all Hex-Coordinates it can currently see within its Sensor Range, and accounts for Region obstructions. When it needs to get the list of visible Entities, it firstly checks if the current list is already tick-valid (has been updated this tick at least once, to prevent re-executing the scan) and cycles through the Visible Area if not. Slightly slower than just a simple circle Area2D, but still very performant and accounts for variable visibility!
- Targeting: Okay, so this is an extension from the Visibility mechanic, but I’ve totally overhauled Targeting. I’ve scrapped all the generic targeting functions in favour of by-case targeting functions for the same reasoning that I recently changed Behaviour & States (which you can read about here); instead of having a few dozen generic targeting functions that have to cycle and check many flags and filters to ensure it matches the request, we instead have only a few targeting functions that look for specific things for specific cases. I originally built the hyper-generic functions because I wanted to account for all possible cases of targeting, again in preparation for modding, but after I realised that all Entities should follow the same behavioural framework, I also realised so should the targeting systems. It’s faster, cleaner, and also takes advantage of the new Visible Area system to further speed it up. This does mean that Chunks have all but become redundant, but I personally favour this new system a lot more. It is more precise, doesn’t compute unnecessary data, and is easy to call. It is also very easy to copy and alter for when I need to create a new targeting scenario.
- Combat: Oh, so I updated Targeting? I guess that means I also need to update Combat? Of course! Last year, while rush-building the early Alpha demo, Combat was one of the last things I built, and it was an absolutely insane to complete. It was full of bugs, and suffered from zero adjustment with big chunks of it being hard-coded. I’ve cleaned a lot of it up, optimised how AttackItems (the classes that handle Weapon & Attack data) work, and, as part of the 2D conversion, rebuilt how the attacks themselves are controlled. Fast-Projectiles like bullets are now a unique Area2D line that moves through space on the PhysicsProcess tick. It adjusts itself to account for collision-skipping, and moves smoothly through space to detect collision with the target. Entity-Projectiles such as missiles were always a type of Entity; it can be selected, targeted, and has flight mechanics. This has been optimised with both the new Entity structure as well as the new Behaviours & States, with these Entities acting as hyper-simple NPCs that smartly attempt to bombard themselves upon targets. Line attacks like lasers have not been updated yet; I’ll be tackling them later as they will involve a large re-write and I want to address them after I’ve finished working on the behaviour network and other targeting/detection systems. Anyways, ultimately Combat has been totally overhauled to be faster, cleaner, and more flexible.
- Relations: Okay, so this one combines both Targeting and Combat updates, but I have also overhauled how an Actor (an Entity not controlled by the player) determines friend from foe, and more importantly who to attack and when. There is already a base Faction system, which was also recently heavily optimised to use automated indexes as opposed to string-names for look-up, but this isn’t enough to establish a reactive environment. In comes Retaliation, which was a mechanic I wrote late last year. It was clunky and poorly optimised, but essentially the idea is that if an Actor gets hit, it remembers who hit it and prioritises returning fire. It worked, but was limited. Retaliation still exists, but instead is used to affect Combat Priority, a mechanic that determines who is the best target to attack based on Combat-style preference and both general Faction relations and personal relations, as each Actor now tracks their own personal Relation-Variance to both other Factions and Entities (thanks Noita for the theory of your own aggression system for inspiring my own system), which is both partially randomised at the start, as well as affected by Retaliation. Combat targeting now uses the Faction and Relation overhaul to more accurately decide who to attack, creating a more living system where NPCs fight one-another, protect allies, and enact revenge.
- Behaviour: I had already started working on the Behaviours & States last time, and I’ve made some massive strides forwards with it and the Behaviour Network that all Actors follow. The most notable update is the generic non-Military behaviour tree of flying around the Station and docking, with lots of little updates to orbiting and how Docking and the Controllers involved in Docking run. I’ve also made massive strides in the Drone behaviour tree, which automate how Drones handle and carry-out Tasks. This also involved lots of updates and optimisations to Task management. There’s still work to do here, but it’s thus-far made the systems much cleaner, more performant, and execute more naturally. Additionally, during last year’s rush-build, a lot of the Drone functions were hard-coded instead of being stored and executed through Behaviours, which has now been fixed with Drones properly behaving like Actors (and also implying that *other* Actors can be turned into Drone hahaha~).
These changes are all on-top of a million other updates I’ve made. I wish these updates weren’t primarily focused on back-end updates and that I had tangible new visuals to show-off, but I want to ensure the foundation of this game is perfect before I continue. As such, I’ve been working around the clock, but I’m still genuinely excited to get the new systems going and get this into public hands! Anyways that’s it from me today, time to get back to it! Stay safe, stay kind, and till next time all the best~!
^,,^