Hello again my friends, today we are back with yet another development update, and I’ve got a few cool things to show you. This month’s log is primarily focused on ship modules, hence the name, so let’s see what we’ve got.
Things that do things
Alrighty, we’ve finally reached the point where we can start seeing some *actual* exciting tiles, namely, the kind that does something in-game. To start off this topic of increased substance, I’ve gone ahead and madethe first engine. This one’s intended to be a small class engine, and on the cheaper end of things too, as you might guess when seeing the tile below – especially with how run-down and dirty it looks.
My body is a machine
that turns grey rectangles
into engine blocks.
I think the end result turned out quite good, but holy hell…. I spent WAYYY too long on this. It took around 2.5 weeks to get this done… I’m not even kidding. Sufficed to say, that’s not a very sustainable speed if I plan to actually release this game, but, the good thing is, much of that timeframe was a one-time cost.
The main hurdle was figuring out how to allow certain tiles to pass through other tiles, without having to rewrite huge chunks of the codebase, nor create massive amounts of new logic (and thus script bloat) just for this one bit of functionality. I won’t bore you with all the details, but I did go through a whole number of potential solutions before finally landing on the right one. The solution itself was actually pretty simple, as it just meant adding a small bit of code that allows JSON entries to specify one or more areas of cells that are excluded from the final cell footprint (whilst also accounting for x/y flips and rotation). This solution was FAR better than all the alternatives I tried, some of which included pre-baking hull parts into engine tiles, extending the traversal cells system into other tile types, splitting the engine into two tiles, and a few more (bad) ideas.
The second blocker was a bit more mundane, simply being the one-time-cost of creating new asset types (in this case Modules). This is mostly due to the initial setup it requires, including all the script, prefab, resource, and integration work, as well as also the slower-than-usual sprite creation process (requiring thought towards dimensions, asset interaction, in-game functionality, visual style, etc). Once this initial asset is done though, all future assets of that type become far quicker and far easier to make – not only because the setup is done, but also because I can slowly build up a shared-resource library for assets of that kind, which I can borrow from and modify to speed up new creations.
So yeah, that’s why this took so long, but the hard part’s done now so all is gravy. I have made another GIF to showcase how this all ends up working in-game, specifically with the overlapping tile mechanic, which you can see below:
Aside from the engine, I also created a few hard-points for weapons, in small, medium, and large sizes. The initial idea was to allow for a dual loadout system, wherein players can either go into the ship builder to make larger changes to their overall ship, or, they can instead just make quick modifications to their loadout without having to enter the full editor. In essence, the hard-points would function much in the same way as those seen in Barotrauma.
But, now thinking, I may end-up ditching this idea entirely – as it just adds a whole new layer of scripts and functionality that, tbh, are probably not even necessary. I think this kind of system works well in Barotrauma because their editor is far more complex and is unavailable in-game, whereas, with Stellar Wasteland, the editor is more streamlined and is fully accessible at all times. I don’t know though, we’ll see. I may keep hard-points as a requirement for mounting weapons onto, or I may just ditch them entirely, it just depends on how it all feels once I’m further along.
Either way, I’ve included a preview of said hard-points below.
As side note, I recently played through the 2023 remake of Dead Space (totally recommend, it’s awesome), and one thing I found myself constantly doing was stopping, opening the snipping tool, and capturing all kinds of random textures as screenshots. I genuinely just could not help myself, because wow, the art department did a FANTASTIC job in modernising the USG Ishimura and, in terms of inspiration/reference, it’s a literal gold mine. There’s something about the mix of worn industrial design and futuristic semi-gothic architecture that is just so damn cool when it all comes together. So, I thought it would be cool to share this here, not only to give credit to the people behind one of the major inspirations for my own game’s world, but also to shed a bit of light on my own artistic process and references I use.
And finally, in the same vein as the previous image, I also thought it would be worth including some rough concept art I’ve been working on, showing some potential designs for the remaining modules. This, of course, is a VERY loose usage of the word ‘art’, as it’s more like a bunch of quick sketches than anything, but I think it still communicates the ideas well enough.
Kinda daunting with how much asset work is still left to go D:
So there you have it, that’s the update on modules thus far. But hang on – it’s been a whole month since the last log – isn’t there more to show by now?
Well, my friend, I have once again fallen victim to side tangents, which I shall detail in the following section.
Side Quest #1
Ah yes, the ever-present need to veer totally off track and work on something entirely unrelated to the main field of focus. This time around it’s the character system, or more specifically, their sprite libraries. Why do sprite libraries need more work, even though the character system is already done? Well, let me explain.
You may recall that, a few months back, I made the arduous switch from Unity’s built in 2DAnimation/sprite-skin system to a traditional transform-based skeleton. This, whilst being a great decision overall, was unfortunately only half the job. You see, until now, I’ve still been using Unity’s sprite library and sprite resolver system, which is super convenient for managing multiple types of characters (genders/body types), and also very handy for animating, but is unfortunately extremely limited when it comes to runtime modding. This is because sprite libraries cannot be modified once the game is compiled, which completely locks out any kind of texture replacements, character overhauls, or vanilla part modding. In addition, it also means that I’ve ended up with two parallel systems for characters – one for vanilla parts/labels via sprite library, and one for mod-added parts via raw PNG/JSON.
So, right off the bat, you can see why this is not a great design. Especially when, considering that every other sprite/asset in the game runs on PNGs/JSONs, this puts the character assets into their own unique locked-down system – completely separate from every other asset in the game. I don’t like it, and it goes entirely against my mod-first philosophy, so naturally, I need to fix it.
This conundrum has led to a solid bit of preparation work, mapping out every aspect of the various scripts I need to revise and also figuring out how I plan to implement things. Luckily, it’s actually not the worst migration, as much of the existing data structure already mirrors that of the JSON-based system, and almost all the existing lookup keys stay the same. Really, it’s just a matter of removing all references and dependencies to sprite libraries/resolvers, re-organising all the project files into a folder-based category system, and modifying the logic to explicitly take gender/body-type arguments in every call (which the sprite libraries previously handled).
Technical jargon aside, all of this will probably take me another week or so, but the benefits will be well worth it. There are, of course, a few drawbacks – namely, the fact that animating sprites becomes a bit more tedious as it now requires animation events rather than using built-in resolver tracks. But oh well, ’tis a fair price to pay I’d say.
Side Quest #2
So, this brings us to the final detour this month, the initial preparation towards marketing the game.
As you know, It’s been over two full years now of working in the dark, like a mad scientist in a cave, with zero online visibility or marketing. This, in itself, is totally fine, as I’ve purposefully avoided sharing anything – apart from on my website (to which there are very few actual visitors). The reason being that, well, there just hasn’t been much worth sharing yet, at least in terms of actual gameplay. This is still the case, unfortunately, but I think we are nearing the point where actual gameplay will be achieved, and so I’ve started figuring out how I plan to market this thing.
One of the first steps I’ve taken is to update the dev log thumbnail to a more refined visual style, which you may have seen at the start. Secondly, I’ve updated the game’s discord channel and Subreddit, in preparation for eventual visitors. And thirdly, I’ve begun planning out a few Instagram posts and YouTube videos, as I’ll likely be using these two as the primary platforms of promotion. I think I’ll skip Twitter/TikTok, as whilst they would probably be beneficial in terms of visibility, I don’t like either platform, and I don’t really wanna compromise on my personal views solely for promotion.
We are still in early days though, and it may be a while yet before I do start advertising, but it’s getting near, so I thought it wise to at least get started on it all. But yeah, side quests clarified, I think that about wraps up this month’s log.
Damn man, It’s crazy how quick the days are going past, especially since I’m now *officially* past the two-year mark in developing this game (and still not even into gameplay yet lmao). Getting old sucks, unsurprisingly. Oh well, the show must go on.
Also, I will admit, between the Dead Space remake and Resident Evil Requiem, I have definitely lost a bit of dev time this month – but holy shit, both games were freakin’ awesome. Dead Space always was a classic so no surprises there, but RE9, damn dude, that was fantastic. Probably one of my favourite RE games to date, only slightly below RE2R. I’m actually also going to go see the new RE movie tonight too, so that’s exciting.
Update: The Resident Evil movie was actually really good, though, apart from a few references to Umbrella, I’m not really sure where the ‘Resident Evil’ part was lol. I think it woulda been totally fine as its own standalone movie, without the IP attached to it, but it was still enjoyable regardless.
Anyway, random chit-chat aside, thanks for tuning in, and I’ll catch ya next time!
