Hey y’all!
Finally posting again after… 3 months..! Yup, that’ll happen when you go full crunch-time to prepare for con season! And it was worthwhile! I was fortunate enough to attend numerous conferences and events throughout October, showcasing at most and even speaking at a few! You can see some photos and posts about these adventures over on my [Bluesky]. If you want the short summary however; everything went amazingly~! ^^ It was lovely giving talks again, and while there were a handful of bugs to patch along the way, the showcases were fantastic. My booths had very consistent traffic and the demo had wonderful and positive feedback. The people who love games like M.I.S. loved the game, and I even had a good number of people tell me that they don’t normally like games like this, but they didn’t want to put this one down! Really happy with the reception, and it’s always wonderful catching up with all the fantastic devs that we have in our industry! ^^
So what about the game itself? Well, I had a little read of my last post and, uhh, the game progressed so far over the past few months that it’d be way too boring and daunting to talk about all the big changes and additions. Combat, trading, behaviours, dialogue, music, window, and dozens, if not hundreds, of other changes and updates! Now, I won’t be posting the booth build anywhere like I did with the prototype last year, so if you got to play it, congrats! Because that version won’t be seeing the public light! So instead of talking about what is new, I’m going to talk about what I plan to change and why. After all the play-testing and talks, I’ve started working on a few major gameplay changes to address a handful of issues, some old some new.
- Problem: “Game Over takes too long to happen!”
In both the prototype and the current build, a run ends when your Bridge is destroyed. Something I noticed in both builds is; as a station is getting destroyed, it eventually passes a ‘point of no return’. This is essentially a point where the player will not be able to recover and the run is effectively over. In the current build, this is point is pushed back a fair bit thanks to the ability to recover Modules; if a Module is destroyed but not “overkilled”, it will break off the station. A Drone can collect it, reattach it, and repair it, meaning that quick and strategic players can reattach necessary parts mid-battle and turn the tides. But that ‘point of no return’ still exists.
I have plans that will further help this, notably ‘actions’ that allow the player to directly affect a run such as summon allies or cause explosions in certain areas, and while this will help with controlling the tide of battle even further, it still doesn’t remove the fact that there is a point at-which a run becomes a guaranteed death and you’re just waiting it out. - Solution: “Station Stability”
I am currently working on implementing “Station Stability”; a mechanic that tracks how large a station has gotten, and uses this to track how much of a station has been destroyed when under attack. If a station loses, say, 90% of it’s size, there is a fair chance that a run is over. What this mechanic does is shows a station’s stability as a sort-of global health-bar for the whole station, and when that bar hits critical, the station collapses and the run is over.
The first benefit of this is that runs no longer hit that point where a player is just waiting for the inevitable, but I also notice a second, possibly more important benefit. This mechanic, particularly the bar showing stability, gives players a clear visual representation of how damaged their station is. It can show a player they’re losing to a boss, holding out against a horde, or steadily rebuilding their station. It is a means to show a player how stressed or relieved they should be. As a bonus, I believe it will also encourage smarter construction, and may even spark some players to build tiny-yet-sturdy bases in an attempt to manipulate the stability mechanic. Regardless, I strongly believe this will help show players how their run is going and when it is about to end.
- Problem: “I can’t tell when the boss battles are coming!”
Quickly, this isn’t talking about a detection system for hostiles, which is it’s own thing. This is talking about knowing when a run is coming to an end. In both the prototype and the current alpha build, the run ends when a “Cataclysm” event takes place and the player either wins or loses. Now, you might think that losing means that the run was a failure, but M.I.S. is a game about constant progression, so reaching the “Cataclysm” is a big deal and it means you did really well! Most players understood that, in fact I don’t think I had any players criticise being obliterated by a giant boss or said that it ruined their fun, but this was also in a conference setting at a public booth, not privately on a computer. While watching people play, and comparing their experience to my own experiences in other games, I realised that M.I.S. doesn’t do “good runs” well, or at least the user experience of ending a good run isn’t very clear. - Solution: “Awareness/Popularity”
Okay I haven’t nailed the name yet, but the mechanic is simple enough, and already utilises a few other systems I already have in place. Essentially, there is a bar on the screen, tucked away, that represents how “successful” a station is. This is a culmination of several things; how many resources a player has, how many ships they have visiting, how many ships they’ve destroyed while defending, and just how long they’ve survived in that area. This meter is essentially a run timer, counting upwards, depending on how well a player does.
Instead of tying certain events, such as special attacks and story beats, to the passage of time or other progressions, these events will now be tied directly to this progress bar, and will be marked on the bar itself. Different sectors will have different events; dangerous sectors will have more hostile attacks and allied areas will have more traders. Some of these events will be known ahead of time, some will be random, but the player will still be aware “something is coming”. Most importantly is the “Cataclysm” and the run’s end; a player will know when they have reached a point where their station is ‘profitable’ or otherwise successful enough that a run is completed. They will get a pop-up saying congratulations, and that a nearby ally is willing to purchase their station for 33% of it’s worth. A player can sell, and walk away knowing they did a good job! If they stick around, they’ll have to prepare for a “Minor Cataclysm” which may end their run without profit.
The players now face a choice; accept they had a generally good run and walk away, or risk facing a harder battle. If they choose to stick around and they defeat the boss event, they keep playing in a more difficult, but more profitable, world! Refilling this bar again repeats the offer, but for 66% of the station cost this time! The player has done an excellent job, and can be rewarded for their efforts. This process repeats until the player essentially chooses to face a “Full Cataclysm”, with it staying true to the original intention of it being a run-killer. This should almost always be rejected until meta-progression has hit the mid to late game, and players will learn this quickly.
Ultimately this concept reuses numerous mechanics already in the build to restructure the player experience. It shapes a run, provides a clearer goal, and rewards the player for doing well instead of doing a “victorious Game Over”. It also still leaves in the option for players to push the difficulty and play against higher risks for higher rewards with a successful run.
- Problem: “Game is lagging?!” / “Oh, the game is 3D?”
Turns out my early-alpha game isn’t fully optimised! Crazy, I know! After watching play-testing and experimenting around myself, I found the major culprit was Multi-Meshes. I don’t think I actually wrote about this, but while researching ways to simulate 2.5D, I discovered Multi-Meshes in Godot; essentially a performant method of replicating thousands and thousands of duplicate meshes. Unfortunately, this node seems to be designed for one or two uses, not hundreds and hundreds. What ended up happening was, even in smaller stations with low object counts, if a player zoomed in too close and the game started updating all the hundreds and hundreds of Multi-Meshes, it got laggy. This wasn’t an issue on my fairly decent dev computer, but it was a problem on every laptop I tried it on at the booths. Obviously there are also dozens of other ways to optimise the game, but this was the one I noticed the most in play-testing. The most annoying part of this issue was that most players didn’t even notice the depth rendering, most assuming it was a 2D game until they built a particularly large module and went “Oh, that’s cool.” and went about playing. - Solution: “Make the game 2D.“
To preface; the game is already 2D. All the mechanics are calculated at 2D, all the movement is 2D, and all the interactions are 2D. But to get the depth effect, the game is built into a 3D scene. This is incredibly normal, not an issue at all, but it did mean I had to write dozens and dozens of 2D to 3D conversion functions. Does it look cool when ships move down to dock? Yes! Does it look cool when Drones pick-up objects and those objects visually move up and click in? Yes! Does the depth render effect from the Multi-Mesh look cool? I personally think so! But was all this duct-tape worthwhile just to get this effect? Honestly no, and this was something I noticed before I even went to the conferences. While drawing-up some of the larger objects, I realised that every ‘layer’ of the object needed to be visually flat, and that when I tried to do some cool pseudo slopes or curves with pixel-art, the depth rendering looked terrible.
My current intention is to fully remove all the current depth rendering, rebuild the scene management into a 2D scene with parallax mechanics instead, remove all the unnecessary code that converts 2D and 3D space back and forth, and then build the game as a 2D game with parallax. From there I intend to add some level of depth rendering, but only as a singular optional effect as a shader. My hope is that not only will the game perform much better, but I will be able to draw much cooler pixel art that itself will demonstrate depth.
I did consider going various other paths. The most common one I discussed with people was making every object a 3D model, a massive pivot from the current visuals. I would essentially build all visual objects as models, and have a post-shader render their lines as pixel-art, still achieving the current aesthetic but with a full 3D effect. I chose not to go this route for two reasons; firstly, I really enjoy doing pixel art for this game and two, while I can do 3D modelling, 2D art is my strong suit and this route would massively blow-out my production timeline. I also considered keeping the current 2.5D scene structure and simply finding a new way to handle depth rendering, but this path would still require me to fix many of the conversion functions I currently have while also keeping the less effective flat-layered effect. If I’m doing pixel art, I want to fully commit to doing strong art.
Okay, enough about production, I’m going to stop there. It’s been a crazy few months and I still have lots of work ahead of me. Don’t worry, I reduced my workload over the past few weeks to recover from the burnout, but I’m still keen to keep going and progressing this project! Full disclosure; my funding is about to run out! )’: I am currently talking to publishers to seek a way to fund the remainder of this project, as well as look for alternate options. I have no intention of dropping this project, I am very excited to see where it goes~!
As the end of the year approaches and with most of my immediate work being fixes and back-end updates, it is likely I won’t post again till the start of next year. You can follow my more frequent updates over at [Bluesky] and stay on-top of production over at [Discord]! Anyways, I hope everything has been going wonderfully for you all, stay kind to one-another, and till next time all the best~!
^,,^