Entropy Game Devblog

Research Revamp

Research projects are getting quite an overhaul - they still are key to progressing through the game, unlocking new features, and the main resource sink before crafting becomes available. However, before they were dressed up as scientific papers which was very much in line with your science gathering mission but made each research item very verbose for not much gain, in addition to only being able to display 1 project at a time on screen.

I've dramatically decreased the amount of fluff text and am also planning to add a menu where you can see the names of each research item simultaneously, in order to provide a better overview for the player. In addition, I used to have 54 separate research items, each potentially unlocking multiple things. Now I've pared it down to 35, each only unlocks 1 thing, and many of the quality of life research that had to be unlocked are now given by default.

The other reason for reducing the list was to manage feature creep a bit better. It is easy to add a new line in my research database saying that I'll add such and such new mode to the game, but it's an entirely different story to then have to spend the time to program it in. So for now, things like an endless mode or a sector finder (irrelevant given the now set sector progression) or a mode where you explore bigger locations in your ship are off the table, but down the line who knows...

As I mentioned previously, I also simplified the research process. Before you submit items, then you have to explore new tiles in locations and battle enemies in order to generate data for the project. Both data and items would be processed at certain rates so you'd get notifications in the log window when your research was at certain %s or finished. Now, you submit items and scrap and research is completed instantly, which I think solidifies player feedback between buying something and getting it instantly.

Matrix Revamp

I had a big 9x9 grid of various passives that research would unlock, and you could slot in cores into them to activate and enhance them. Higher tier cores would provide better effects, and was designed as an answer for all your unused friends in creature collector games wasting away at your base/inside your PC/etc. While I have the scaffolding in place and a lot of lower tier effects working, the trouble is that the mechanics just weren't very clear or engaging, and eventually you'd want to be using the highest tier robot cores in every slot, meaning all your others would be sitting there doing nothing once again.

So first off, robots don't have tiers anymore, they just have levels, as part of the new statting system I mentioned earlier, making the game's encounters more like pokemon and less like SMT. Second, I have once again scaled back the number of passives to avoid the grid feeling overwhelming, and each research will be tied to exactly 1 passive (barring the ones that unlock new sectors), shown with its name in a list rather than just the icon in a grid.

Each passive will have a certain number of slots, and each unique robot core inserted into those slots will provide a linear bonus to that passive, and this bonus does not depend on level, tier, or anything else. Simply put, if you have the HP up passive unlocked, and you insert 1 core, your party will get an extra 20hp. 2 cores, 40hp, and so on, up to the maximum number of slots that upgrade supports.

Research will unlock interesting features like trap disassembling, liquid collection, optional level scaling, teleportation, and so on, and you'll get those by default, but adding cores into the associated passive slots will provide enhanced collection rates, decreased energy usage, and so on. Basically, play with the new toys and if you find them useful, go and slot in any unused robot cores into the respective passive to power them up.

I might also make it so that cores slotted into the matrix can still be used in battle, I'm not sure yet. It'd really just be a quality of life thing and it wouldn't break the game, so we'll see how it goes once I get to revamping this mechanic.

Other bits and pieces

These are the other few items in my list of "large effort" items but there's not too much to talk about since they're minor impact but will take quite a bit of programming:

Materials revamp: Along with research and the new sector structure I will need more items available at each tier, and faction specific items. This ties in with gating research progress by needing certain items, but I'm yet to figure it out. I also need to integrate the new resources you get from trap dismantling, liquid collection, and object crushing too. I'll scale back the materials I have now which are quite generic (a few key elements + various robot components) which means I'll have to retool my parts crafting list but what can you do, really.

Log filtering: I want the player to be able to filter the log for various messages such as battle, fluff text, tutorials, and so on. I already have arrows that let you scroll up and down so adding coloured letters shouldn't be too much work? Maybe?

Dungeon pathfinding: Based on feedback regarding the tutorial, I need a way to display an objective on the map, or at least indicate its direction. I already have a system for automatically moving the player, so maybe I'll also add a path that can be set and travelled back home or to your last location, ala the routes you can set up in the Etrian Odyssey games.

New factions: Currently I have 5 main factions in the game. I need a 6th major faction to fill out one of the mid-game sectors, and then I also want some minor factions sprinkled around here and there for variety and for filling in key niches in the element/affinities/stats spaces that I don't currently have filled. I'm thinking another 3-4 for a total of 10ish. That's a massive undertaking of course and is lowest on my list of things to do, but we'll see where I'm at as things progress. I am SO rusty regarding my pixel art and animations so it'll be interesting to see how that goes when I do eventually pick it up again.

Sector overhaul

Most pertinent to game progress will be the way that a sector (a group of dungeons) will be generated. Much like how the locations will now be completely custom (more on that later), to tell a better story and to ease to player into the game, I have also overhauled the sectors - no longer will they be collections of random locations, but they will have a thematic and narrative purpose as you travel from the outer orbits to the inner orbits, beat the sector boss, and gain access to the next sector.

Sectors will mostly be themed around one faction with some omni-enemy areas and one or two other faction zones to keep things fresh, and each area will have a defined level range and enemies that can be found in order to keep progression hopefully tighter than before. The level range can be as wide or narrow as I want and this gives me finer control than just labelling things as a tier 1 (1-10), tier 2 (11-20) sector and so on.

Previously, you could roll around in one of the many unaligned sectors, fight basically every enemy in the game, and not really have any sense of progression or exploration. In addition, it was incredibly hard to come in prepared for one of these sectors, in terms of covering your own weaknesses and attacking enemy weaknesses, because of the wide spread of enemies.

I still plan to have randomly generated sectors for the motivated, because the code is already there so I don't see any reason not to, but they won't be the focus of the game anymore, and probably to the benefit of it, because it was quite aimless previously.

Oh and by the way, I currently have my locations divided up into 6 sectors, with 2-5 orbits each. That's 47 locations, plus I'll have more because one of my sectors is devoid of the main faction as I haven't designed it yet (foreshadowing)!

Location overhaul

First off, pardon me if I sometimes refer to locations as dungeons, as that's what I've always thought of them as (dungeon crawling etc) but in-game they should, hopefully, be referred to as their less fantasy-coded counterpart, locations.

Anyone who's played the game already knows I have support for custom maps per-location, as the tutorial/launch base is a hand-designed map. The big part will naturally be designing the maps for all the other locations, but considering I already have the generation parameters for them, doing a more stylistic set of maps shouldn't be too hard.

Plus, I am planning to keep the random generation. As the universe is in its late stages of decay, each sector will have a ruined/decaying/crumbling/other thematically appropriate word counterpart which will be the randomly generated version of the location. This will be unlocked after you complete it and will be a mirror to the story counterpart. I would expect higher amounts of loot and tougher enemies to be patrolling these areas, in addition to a lot of different traps and machines that weren't featured in the main locations.

Research overhaul

Both of the above items also lead into the research overhaul. While I thought the initial concept was cool (that is, styling each research item as a scientific paper with an aim, method, and conclusion - the unlock), In testing, this fell flat due to the overwhelming amount of text on-screen and the ability to only see one research item at a time. That plus the data gathering in the dungeons while the research was chugging away was very unintuitive.

So I will be simplifying the research interface, showing only the necessary information, and letting the player select from a list of research rather than scrolling through each one. I haven't quite decided how to do this, but since local and relativistic navigation used to be research (that is, the ability to fly between locations and between sectors respectively), and now that travel between orbits is gated by completing the respective location on the previous ring, I will need to think carefully about how to best implement player progression.

if it comes down to it and I do implement this through the research interface I will have faction-specific materials as well as probably key materials located at the bottom floor of each location that will serve as gates. If I decide to unlock orbits automatically based on criteria, well, that'll be a different story! I definitely want unlocking sectors to be done through the research menu however, as that is a big deal that serves as a big milestone for the player.

As part of the big revamp, I'm changing how enemy stats work. Instead of a fixed system where every enemy of type A has the same stats (like in Dragon Quest, SMT, etc.), enemies will now simply have a level and use the formulas that used to only apply to player growths (ala Pokemon). This will mean substantially more encounter variation AND better balancing as I'm not juggling hardcoding stats to a level I think will be player-appropriate.

Of course, that means working backwards from the player stats at level 99 - this takes a bit more mental math and I'll probably have several columns dedicated to some quick calculations at each tier (just a reminder, 1 tier is approximately 10 levels). Currently, the XP and scrap calculations are completely out of whack because their formulas were scaled to the old stats but that should be fine to adapt.

As I mentioned in part 2, enemies will also have a signature burst attack that can be used by consuming a shared point resource gained by attacking or healing with a variety of elements in battle. I first assigned a burst effect to each unit, but then decided this was a poor way to do things as I hadn't covered the full range of effects I was hoping for.

This led me to work on the routines database, where the new burst attacks would live. Here I drafted up all the effects I was after, reassigned/invented cool new names for them from the old grid system, and used the existing move database to fill them out. There's now enemy-wide damage, single target damage, DoTs, and healing in all 9 elements, attack/defense/speed buffs and debuffs, plus a range of status effects and status clearing effects, for a total of 71 different effects. While some units will reuse certain burst moves, each unit will have a unique point cost to using the move, where the more points you use, the better the effect of the burst attack (more damage/healing, longer status durations, etc)

I also worked on some simplification while I was there - the UI can get quite busy and cluttered and so I wanted to cut down on the number of attacks that had multi-element, multihits, and random esoteric effects like, clearing only data-type status effects. I've buffed said moves to compensate and made their weird effects more standardised (e.g. instead of clearing data status effects, it'll clear all virtual status effects which includes data, neural, and sensory elements).

I also worked on the attack descriptions as they would be front and center when choosing the attack. I already have the cost on that pane, so I wanted to generate short succinct descriptions of the attack, for example, "Deals medium kinetic damage to one row, and inflicts Defense Down". I previously had mixed in move effects with descriptions of how the move is executed in-universe, but that is better suited for when the move is used, as it will say something along the lines of "USER unleashes a barrage of bullets" etc.

Speaking of flavor, I also changed up some of the battle dialog. Each unit now has a short snippet of text for when they are hit, in addition to a bit of polish for their other dialog triggers (battle start, attacking, recruitment chance up, and asking to be recruited). Dialog is not my strong suit so these will probably need further changes but for now this is fine.

Finally, tutorials. This is an ongoing process as more things in the game get changed, but I changed a few tutorial lines and deleted a whole bunch of irrelevant ones based on the changes that I had previously detailed in part 1 and 2 of this blog series. Naturally, there are also major changes coming up to several systems which will necessitate more tutorial changes.

Inventory revamp

The first and most prominent thing I did in this category was a complete overhaul of how I was treating the inventory. Previously, you had an inventory limit (to encourage returning to the base and not hoarding things) and you could manually choose which items to keep on you or store. The way that having an overloaded inventory generated increased oxygen consumption was not very clear, and there was player confusion about not having the right resources available for research/crafting because they were in your suit rather than in the ship's storage.

So the revamp is now as follows:

Unlimited stacking of any one item (with a hard cap of 999)

Unlimited number of types of items in your inventory

Automatic transfer from suit to storage upon entering your base

No more transfers from storage back to suit (it serves no purpose because...)

Parts can now only be equipped at base (I found players wouldn't worry about part management in the field anyway)

Friendly robots will let you trade directly from storage (avoiding the tedium of getting the item from base and going back)

I may re-enable part equipping in the field if this proves to be a controversial decision - that's the only negative that really comes about from all these changes.

Element revamp

Elements and the advantage grid have been overhauled as well. The advantage grid used to be interacted with by hitting a weakness, healing, or inflicting a status effect with a particular element. This lit up the corresponding cell within the grid, and depending on how many lines you filled and which elements you lit up, before the enemy's next move, you would get one of a LARGE amount of effects. This was incredibly confusing and most players did not understand nor engage with the mechanic. And fair enough, it was an incredibly poor design choice! Now:

The element grid is just the 9 elements of the game in order

Doing anything advantageous (dealing damage - no longer just weakness hits), healing, and status effects causes that element to light up and you get 1 point of burst power.

Each robot core has a different burst command that consumes a number of those points, and each burst effect will depend on the robot - a support robot will do a party-wide heal, an offensive robot may do high damage, a sneaky robot might stealth the party, etc.

Further to this point, each element is now colour coded with a unique colour to indicate what class they belong to (orange for common, pink for exotic, and teal for virtual)

Element icons have also been changed so that common elements are a diagonal line, exotic elements are circles, virtual elements are diamonds, and non-elemental effects are cross shaped (see image comparisons below, with the new elements on the left)

Now, I actually quite liked the older element sprites, however, in the heat of battle where all damage/healing is typed, those icons became very unreadable just because they'd only be popping up on-screen for half a second, and weren't very visually distinct. This + the colours should help to differentiate them and easily identify what class they belong to, as the element-class relationship was not very clear prior to this. I don't think I've done it justice here to be honest, but it should be evident in game!

Talkative robots

The final change I'd like to talk about is that I needed clearer UI for when robots were talking in battle. Previously I had a single-line rectangle an a single pixel-wide line connecting the box to the speaker. I had lots of feedback about how this was very unclear, and so I've made a custom speech bubble text box for these events, which you can see as the opening image of this post.

As you can see, the box can be any colour and come out from any side, and it is a multi-line textbox with variable width and height! I have also made it so that you can talk with the assistant in your base - one of my friends suggested it to be a more direct form of delivering lore and interacting with your space-faring buddy as opposed to the randomly scattered and fragmented logs that you'd find within the dungeons, and I completely agree.

Now, depending on your level, the assistant's level, how many different robots you've recruited, what research you've unlocked, how many locations you've visited, etc. your assistant will respond and provide you with related tips and tidbits! I had fun writing up this database but am still yet to program in the triggers, but all the systems are in place to track these events quite easily.

Power load: Initially I had it so that robots would have a parts capacity - their power load - that limited the number and power of parts that could be equipped on them simultaneously. When overloaded, the robot would lose stats proportional to the difference in values, but you'd still gain the benefits/moves of all parts equipped. I've removed it because it was a fairly unintuitive system and parts already are limited by each robot's 5 part slot types (weapons, frame, mobility, support, universal). I also noticed that going over the power load with an item would show a preview of all the unit's stats going down, and my playtesters just attributed that to being a terrible part, rather than they were about to exceed that robot's power load.

Fuel costs: Fuel was initially needed to move between locations within a sector, and between sectors as well. The game also adjusted fuel usage, making it cost more when shifting between orbits, and even more when moving from an inner to outer orbit because realism!!! I had lots of safeguards in place to ensure that you couldn't get stuck in a location that was too difficult, but that meant fuel could be gained from both fights and exploration. None of that was really engaging or core to the experience, so now you are free to travel between/within sectors as you like!

Research data: Research is the key to unlocking new features in Stellar Terminus, and you used to need to submit both materials and research data in order to unlock the research. Research data was gained by uncovering new squares in a location and from fighting enemies, and so one would have to initiate the research, THEN go out into the field and collect data, wait for the data to be processed, and then you'd be notified that the research was ready for collection. This delay between having the items and gaining the effects of the research was meant to encourage exploration while having something cooking in the background, in practice it only served to be a big friction point for players, and weaken the association between researching something and getting a new thing to play with.

Adding scrap to research requirements: With the removal of data, each research item now has a scrap cost. Scrap currently wasn't doing much, only used to activate some recovery machines in the dungeons and, later on, to be used as a cost for parts fabrication. This gives scrap another use and gives you more incentive to seek it out in the early game before fabrication becomes available.

Flipping the move description and details panel around: Previously, a move's details would be the first thing you see, and you could press a button at the bottom of the window to check the move's description. After realising that it is easier to parse text rather than numbers, I have inverted this such that you see the move's description first, which should help the player immediately identify what the move does (as demonstrated in the left portion of the above image).

Demo recap

The work leading up to the demo was intense - some anticipated such as all the code needed to finalise it, and others not so much, mainly the many, many different sized assets assets and dev account validation process that steam required. As a sidenote, I know wikihow gets a bad rap but this guide was actually perfect and told me everything I needed to know.

Working towards my self-imposed deadline, I didn't do much in the hype-building/advertising department, and that being said I was floored with the response I got! I'll have to check the stats again when I get the chance, but it was 1000s of downloads and 100s of wishlists, which was honestly incredible. I got noticed by some cool Japanese game aggregator too so demographics-wise, Japan was the second highest country to visit my page!

First person dungeon crawling is a niche genre, and getting feedback from enthusiasts was incredibly helpful and is shaping my work this year. Compared to the download/wishlist numbers, I only got a little bit of feedback across the steam forums, a couple of enthusiast sites, and Tumblr, but it was all very valuable nonetheless!

Post-demo activities

I decided to take a break after the release, in order to gather feedback, reassess where I was headed, and prevent burnout. Little did I know that it had already set in, and I just didn't know it yet. There was still a ton of work ahead and this was very demoralising. Weeks turned into months and throughout 2025 I had around 4 quite disruptive periods of housesitting, and a couple of other life events that made development on Stellar Terminus come to a standstill.

If you have been following this blog for a long time, you may know that I am working in Gamemaker Studio 1. The new version of Gamemaker used to be called Gamemaker Studio 2 (GMS2), but has since rebranded to Gamemaker. GMS2 was released in 2016, so GMS1 was absolutely ancient at this point. I developed several smaller games in GMS2 with my friends in order to check it out, and wanted to port my code over to it due to the nicer UI, more performant compiler, and additional language features it offered.

Unreleased as of yet, but I also developed a board game roguelike prototype in GMS2 during one of my housesitting stints that takes an expanding board and lets you build an army from various chess/checkers/shogi/xiangqi pieces that I'll write about at some point in the future.

I also prototyped a bunch of boardgames through Tabletop Simulator, some for gamejams and others just because I wanted to explore a cool idea or mechanic. Whenever I get an idea that I can't stop thinking about, I have to get it playable in some form otherwise it drives me crazy!

Another housesitting session, I had a cursory look into Godot and had my first go at a simple first person 3D game where you climb a randomly generated tower containing various easter eggs on each floor. It was my friend's idea and they envisioned it as a chill game that you could turn your brain off and play/stream while on call with your other friends!

We are so back: 2026 edition

Anyway, it's 2026 now, and I was of two minds in terms of completing Stellar Terminus. On one hand, there was still so much work to do, and I was nowhere close to finishing it, and I was also not enjoying development due to how old and messy the codebase is, in addition to GMS1's clunky interface. On the other hand, I was still very much in love with the idea of the game and what it could be, in addition to finishing it for all the other people (you guys!) who want to see the finished version.

One of my friends threw me a curveball and gave me a third option, one that I embarassingly hadn't really thought of: finish the game, but revise the scope such that there was less to do. With all the various dev activities I've been doing over the past couple of years, I really do feel like my design philosophy has evolved a ton and has tended more towards simple engaging mechanics that together give rise to emergent complexity.

I know these words might be ringing alarm bells in some people's heads (my own too, honestly), I want to state this clearly: nothing central to the game is being changed. The setting, combat, exploration, aesthetics, progression mechanics, and the main loop of explore > fight > return home and recover are all either staying the same or getting some polish.

What I am doing is working to trim the superfluous and confusing mechanics that, at first I thought "wow this is so cool and adds realism to the game!", but I now realise that they just only add unnecessary friction to the game! I have a big list and have been working through it currently, but these include removing fuel, power load, inventory limits, and revamping the elemental advantage grid, research, core matrix, and galaxy structure.

If those words mean absolutely nothing to you, great! That's because they were obtuse, poorly explained, and underutilised mechanics! This blog is already very long so I'll have a separate blog going through all of them and more.

Oh and the big one? Hand-crafted dungeons for the majority of dungeons instead of random generation. Yes I know I said I wanted to make less work for myself but if I'm going to put in effort, it might as well be where it will make the most impact to players.