...
Browse GamesSteam news
Full Steam announcements and update articles for this title.
The Start Your Engine Festival is starting now, with 86 games taking part, 28 of which are upcoming titles, and 18 of which have demos! Come take a look at all the vehicular games on offer.
From the organisers themselves: "Celebration of engines in games! Whether you want to drift through mountain passes, haul cargo across a post-apocalyptic wasteland, run a transcontinental rail empire, or sail an open sea with the wind at your back, there's an engine here for you."
Deep Space Exploitation is taking part, as it is actually a vehicle focussed game! This didn't occur to me during development, but it looks like it ended up as quite a slick little retro arcade flight game. I've you've not played it yet, or want to pick it up for a friend, then now would be a nice time to as it's 30% off.
Today I'm releasing an update for v1.1 of Deep Space Exploitation! This update contains some (but not all) of the things I wanted to add before release but never got round to, and also some things that came from suggestions and general bug reports.
I still have things on my list to add, but I really wanted to get this update out before the Winter sale and had much less time to work on things than I thought, given a recent apartment move and general holiday season madness.
Anyway, the Steam Winter Sale starts tomorrow and Deep Space Exploitation will be 25% off, so go fill your stockings!
And here are the things I've been working on... :)
Throughout development I'd get the "why are you slowing down in space?" question, and I would tell people that I'd tried it and it's just not fun for the default movement. I still stand by that, but what IS fun is having the option, so I've added a ship upgrade which installs a little switch to turn the inertia control on and off. So now you can drift to your heart's content!
There's an option in the settings to have this work as a "toggle" or a "hold", too.
When starting a job with a permit cost, the amount is now charged once you've finished the job instead of before. The idea here is to remove the frustrating step of spending all your credits or using them all to pay off your debt, then going to the jobs page and finding you don't have enough to pay the price of the permit you want. I'm a tiny bit unsure about this change, as I think maybe it's good to include that bit of friction to make the permit seem more serious, but for now I think it's worth smoothing out the UI interaction in that area.
I have hidden a second game within Deep Space Exploitation for your enjoyment! This is a little arcade game playable during the mining phase via your tool screen. It's semi-hidden, requiring you to hold down the tool cycle button for 2 seconds (this is revealed part way through the game if you're nice).
I felt (and one or two players mentioned) that there needed to be an additional basic tool when starting the game, so I've added the Prospector Gun which is something of a pea-shooter/scatter-gun hybrid. Tap the fire button and it'll shoot a single shot from its clip, or hold down fire to load multiple shots from the current clip and release them in one blast!
I think this solves another problem by being the first new tool available instead of the Mining Hammer, because although I love the Mining Hammer, it's quite a harsh first option for those who don't enjoy it and feel like it's actually a trap.
I finally got round to making individual icons for each achievement, which I enjoyed more than I anticipated but was definitely too busy with other aspects of the game to think about before. I've also added a couple of new achievements in there.
I did have a few more things I wanted to get in for this update which didn't make it due to time constraints, so I'll be working on those next.
Features - Inertia switch upgrade. - Permit costs are taken after a job finishes, not before. - Prospector gun. - Actual achievement icons. - Achievement for hitting a seeker mine with the hammer. - ASTROMINER mini game.
Tweaks - Added an extra message from the resistance about this scrap processor job to give an extra nudge and make the puzzle less punishing. - Made default screen background slightly darker for increased visibility. - Adjusted some item prices so that new items are still accessible. - SFX added to standard mining gun when it's ready to fire. - Added reminder message when the cargo is full which explains controls and dropping unwanted cargo. - Player can only take 1 damage from point-blank bullet explosions per second, this stops them one shooting themselves with the Prospector Gun. - Blocked activator tool upgrade from being uninstalled, which can soft-lock the player if they uninstall is before the first scrap processor job.
Bugs - It was possible for two bullets to collide in the same spot on an asteroid on the same update cycle, resulting in them destructing the same area and effectively wasting one bullet. This would have only really been possible before with the Gatling Gun but the Prospector Gun made it happen a lot more. Fix detects this and defers additional bullet collisions to the next update.
Hello!
Voting for the Steam Awards is open now, if you thought Deep Space Exploitation was a cool game that you played this year, then I'd really appreciate a vote! :)
I realise with my tiny community that it's quite unlikely that I'll get any award, but I thought that any votes might provide a little bit of visibility.
If you do vote for Deep Space Exploitation, then I think the Steam Deck Award is a great shout, since it is actually really great on the Steam Deck!
Hope you have fun with your votes and that some of your favourite games get some recognition!
Cheers! :)
This is post is more of a news roundup of the past few weeks since release. I've got some release stats and also some nice news regarding bundles. I would have liked to make this post either exactly 1 or 2 weeks since the release, but I've been a little busy moving flats, but that's just given me a little more time to organise thoughts and data.
If you haven't played Deep Space Exploitation yet, there's an excellent (and quite long) demo available on the store page! And please do come join the Discord Server, the more the merrier. :)
- Development Time: 14 Months
- Steam Page Live Date: 2025-04-09
- Release Date: 2025-11-06
- Release Wishlists: 4,298
- Units Sold: 960
- Steam Revenue (Gross): $7,049
- Wishlists: 5,805
- Units Sold: 1,156
- Steam Revenue (Gross): $8,785
- Wishlists: 6,461
So all things considered I'm quite content with this. The sales are good for the number of release wishlists, and that's an actual amount of money which someone can (frugally) sustain themselves on. Typical Year 1 sales projections are around 3 times the Week 1 sales, so we're looking at roughly $21k Gross.
(These wishlist numbers are rough estimates as Steam's wishlist reporting is currently down so I can't get accurate date range numbers.)
Throughout the 7 months running up to release that the game had a Steam page (it had an Itch page for a few months before that) I had been marketing it with social media (Reddit and Bluesky) posts and dev logs (Itch, IndieDB, and Steam). I would say that the social media posts netted about 1,500 wishlists, and can't really say that the dev logs did much.
I participated in Next Fest June, which was maybe a little early considering the ultimate November release, but I did honestly think I was going to release soon after Next Fest. Either way Next Fest was great for discoverability and wishlists, bringing in about 1,200 and also a lot of great feedback and new members for the discord channel. This was probably the biggest single event for the game's visibility, which made it even worse that I missed a couple of other fests that would have been great (Debut and Tiny Teams) because I wasn't keeping track of the right channels or knowing that I should really have been searching for them.
Two weeks before release I started my real marketing push, emailing content creators and journalists, posting my trailers, re-posting my best social media posts, and also paying for Reddit ads. This brought in the remaining 1,600 wishlists, which mostly came from Reddit ads, averaging about $0.60 per wishlist (difficult to know exactly since there was a lot of noise from other marketing).
The final wishlist count fell short of the magic number required to get on Steam's Popular and Upcoming tab, and I'm still not sure whether it would have been worth it to delay and push more money into Reddit Ads (because every other marketing avenue seemed to have run dry). I was feeling pretty confident about the release, and really wanted to get the game out there, but also felt like I'd done everything I could in terms of marketing. I had no coverage from journalists or the like, which I found surprising at the time (since there were two small articles written about the game after Next Fest) but now understand that that's just the state of things. I've had a fair few small Youtubers/Streamers cover the game, which has been amazing and lead great feedback and conversations more than visibility.
Overall, this feels like a decent result without striking lucky with any viral posts or content creators. I think my two week marketing push before release was too short, a month would have been better to give me time to react to things and push in different directions. Based on the feedback I've had about the game (next section) I don't think there's still potential to get more coverage and visibility for it; either I wasn't trying hard enough with the marketing or I was wasting effort in the wrong places.
Currently on Steam the game is at 100% Positive after 55 reviews (61 reviews in total, if you count those who got the game for free). In terms of feedback, this couldn't be better. The general feeling I get is that people really like the core loop of the game, some people love the story, and some people wish it had more of an open-world and endless element to it. One of my big worries while making the game was that people wouldn't get that it's supposed to be a short and sweet game, and because a lot of other games about mining in space are open-world and endless they would expect this one to be too. Thankfully, my intentions have come across clearly and people are enjoying the game for what it is. It's nice that people want the game to have more of an open-world, because to be honest, if I could go back in time (and have the experience I have now) I would probably have designed it more like that.
So yeah, feedback is great, couldn't be happier about it. :)
I released on Steam and Itch at the same time, and because I really like Itch and it's had a rough year I decided that 100% of the revenue from the Itch release sale should go to Itch. This hasn't been a substantial amount of money, just short of $200 at the time of writing, but it's support nonetheless.
I suppose I didn't realise how big of a thing Steam Bundles are, but I had a few devs of other games approach me about making a bundle with them. I wanted to wait for a little while after release and also approach some devs myself before I properly entered DSE into any bundles, since I didn't really have much of an understanding of this side of things. DSE is now bundles with two other games, which I can announce below (one of them I already announced in the Discord), and hopefully I'll have news of another bundle in a few months, but no promises.
DSE is bundled with Delta V for a 25% discount in the "Sim vs. Arcade" bundle. This has been very exciting because DSE has been likened to Delta V by players throughout development. If you like Deep Space Exploitation but crave a more hard sci-fi simulation in an open-world, then Delta V is the game for you.
DSE is bundled with Astronomics for a 15% discount in the "Astronomical Exploitation" bundle. Astronomics is big on asteroid mining and exploitation by way of automation and strategy, so give it a try if puzzling out optimal systems for resource extraction is your thing.
Now that I've finished moving flat I have a brief period of time where I can get on with things before the holidays season starts and I get stressed and distracted. I'm planning a few updates to Deep Space Exploitation, but not really anything in the way of large content updates. Next I want to spend a little bit of time bringing one of my old games to Steam, since I think it deserves a little more love and attention, and then I'll be starting on my next project in earnest. I have a couple of ideas of what I want to make, but I still need to properly think things through.
As always, thanks so much for all your support :)
It's been an interesting, stressful, and exciting week since the game released on Nov 6th. I'm thinking whether I want to (and have the energy to) write a break down and report as a larger post, but I'm not sure there's that much interesting to be said. All in all, the release went well, if a little quietly; reactions and feedback to the game are good, 40 reviews at 100% positive on Steam as I write this, but the audience could be bigger. That being said, I've had the chance to work on the bugs reported since the previous update, and also slip in a high contrast mode for this v1.0.10 update!
This was mentioned by a few people as feedback during the release. It seemed like an interesting problem to solve so I thought I'd have a go. I used a website that allows you to compare colours to check their contrast rating (check it out here), then made a post on /r/disabledgamers checking to make sure I wasn't making any obvious mistakes. Implementing the colour change was actually quite easy. Because the game is so heavily pixelated and uses very little blending and transparency (except one place which needed a little extra attention) I was able to write a shader that would simply check for one colour and replace it with another. Pretty great solution since it meant I didn't have to create any special assets or add any complicated logic to re-load game elements to display their high-contrast versions.
It's also possible to set specific colours for the high contrast mode via the game's settings file, if you want to use it to help with other sight conditions like colourblindness. This can be done by finding the setting file at '\\AppData\\Local\\JuhrJuhr\\Deep Space Exploitation\\settings.json', and changing the Hexadecimal colour values for the fields 'HighContrastColour_Background', 'HighContrastColour_TextDisabled', 'HighContrastColour_TextDefault', 'HighContrastColour_TextAccent', and 'HighContrastColour_TextHighlight', or as seen in the imagebelow.
High contrast mode
Typo in report feedback.
Settings now correctly save when "pause on focus lost" is updated.
Solved a few error cases when asteroids are destructed, which resulted in strange destruction occurring (huge chunks disappearing that were nowhere near the area of destruction) or no destruction occurring at all.
Fix for case where asteroid particles weren't being created.
Fix for issue where an object currently screen wrapping would desynchronise with its wrapped versions if hit with the mining hammer.
Explosions no longer potentially damage objects multiple times if they are currently screen wrapping.
Button press repeats are now working properly (bug was introduced in previous 1.0.6 update).
Deployment/Extraction ship no longer stalls in one spot when it's supposed to be exiting the screen.
It's been less than a week since release and things have been going very smoothly. Only 2 real bugs so far, so I'm counting that as a win. I've had great feedback on tweaks that I can make, and I've already started on some of them (see this update) and there're more to come!
Thanks so much to everyone who's played, left feedback, and generally enjoyed the game. And if you haven't yet, then why not try the demo? :)
Anyway, here's the changelog for v1.0.6.
Fixed a typo with for the Hull Plating MK3 upgrade which made it appear as "Hull Plating MK2" after installing.
Fixed a crash caused by seeker mines checking for line of sight on the player after they've died.
Fixed a crash caused by the spectro scanner caching data for an entity gets removed from the game.
Fullscreen-Windowed mode no longer shows the rounded edges in the bottom corners.
Improved performance of activator tool (this will make no difference, but the code is better now, trust me).
Changed day 19 response to Tavid's message to make it clearer that you're playing dumb and not just being sassy.
Red crystals are now a little slower.
Report page now explicitly says your terminal's data will be uploaded.
Easier to use deadzones for controllers when used for button presses, such as in the UI.
Some users experienced a graphics issue with the asteroids on Steamdeck or Linux (with Proton). So far this has been solved by updating the Steamdeck to the latest version, and I suspect a graphics card update will solve it on Linux. If this doesn't work for you then let me know so I can continue investigating.
Thanks again! :)
Hello!
Deep Space Exploitation is now fully released and available for purchase and enjoyment!
If this is the first time you've seen the game (thanks for taking a look, btw) then I'll briefly explain:
Deep Space Exploitation is a space mining game featuring 2D physics, fully destructible asteroids, and a story of survival under an exploitative corporation. You'll need to use your equipment wisely, upgrade your ship, and make difficult decisions in order to secure your future!
If this isn't the first time you've seen the game, then thanks for taking another look! And thanks for all your support throughout the development process. Making the game was super fun, but the real magic was seeing people's reactions, feedback, and overall excitement. So thanks again :)
If you've bought the game and want to help me out you can leave a review here on Itch or on Steam, share the game on any social media you're on, or just come over to the Discord to show your support. :)
Demo
The demo has also been updated, and the save files are fully compatible between demo and full release. So if you're unsure about buying the game, give the demo a go and if you like what you see you can buy the full game and pick up where you left off.
What's Next?
This is the v1.0 release, but there are still some small things I want to add that I didn't really have time to before. I won't promise huge content updates, or DLC, or the like, because the truth is that I'm really excited to get to work on ideas for other games that I have. That's still a while away though, because I want to make sure I react properly to post release feedback and make sure DSE is in the best shape for people to enjoy. I'll also have a lot of business related things to consider, like what my primary source of income being video games will look like. Oh, and there're quite a few games I want to play once I have a little less pressure on me...
Anyway, thanks for being here at this exciting time, and I hope you enjoy the game :)
(As a little extra, here's a picture of some flyers I had printed for the game and handed out at local games cafes and bars. I wanted the design to look like game print ads and box back cover art from the 2000s)
Hello! Today I'm announcing the release date for Deep Space Exploitation! Along with releasing the two trailers I've been working on and an update for the demo.
If you haven't already, go Wishlist the game! It will really help out in the run up to release :)
Release Date! I'm aiming for the 6th of November 2025 (2 weeks from posting this), but in most of the marketing stuff I'll just be saying "November 2025" so that I can give myself some breathing room in case I want to spend a bit more time on anything or I find out my chosen date is a bad idea. Release will be on Itch and Steam at pretty much the same time. Oh yeah, I'm also looking at around 8.99 USD for the price, most likely with a 20% launch discount.
Trailers! I ended up making two trailers, one which is all action, and one which gives more of a look at the story. I did this because I felt that the story elements were too slow for the main trailer, and that I had some good content (the intro cutscene) for the story trailer that people would like but is otherwise too slow to lead with in a traditional trailer (this is going with the advice that a trailer needs to lead with action in the first 5 seconds). So here they are:
Demo Update With the release coming I'll be updating the demo to the latest version. The biggest change here will be that the demo will actually end after so many in-game days, instead of switching to randomly generated levels and being infinitely playable. The reason for this is so that I can keep the save files from the demo compatible with the full release version of the game, so you can finish the demo and then buy the full game and jump right back in (once it's released, that is).
What's Next? Right now I'll be contacting as many people as possible about the release, and posting about it wherever I can. For the next two weeks until release I'll be reacting to content creators, pushing the game some more, doing any last minute changes, and writing some tech dev logs. I've been looking forward to writing some dev logs about some aspects of the game like the engine and my approach to destructible asteroids, so these next few weeks should be quite fun for me.
As always, thanks so much for your interest and support :)
Hello!
I thought that the recent v0.7 demo update was going to be the last before the release of the game, but there have been quite a few tweaks and fixes that I wanted to get in now since they're pretty important for a demo. What spurred a lot of these updates was a recent discovery that a small but significant number of demo players weren't playing further than the tutorial because they didn't realise the demo went on. This is obviously bad because the tutorial is only about 10% of the demo, and all the fun and interesting stuff comes in the other 90%!
I've written a bit extra about the bigger changes in the v0.7.4 demo update (full change log is at the bottom).
Tutorial Updates
This isn't the first time I've made a significant update to the tutorial, the previous time I re-arranged some steps to make it harder to breeze past the important sections on how the scanner works, and this time I'm adding more to ensure that players aren't getting stuck or confused by the tutorial steps. There's a step in the tutorial where you need to fly around and scan three difference resources before you're allowed to use your mining gun to extract them; quite short-sightedly I didn't add any kind of counter for the number of resources you've scanned, so players have been quite rightly a bit stumped at with this and only seem to get through by guess work. So now I've added an actual counter to the scanning and resource picking-up sections, which I hope will help with some player frustration. I also realised I should move the placement of the asteroids and resources closer to where the scanner is on the screen, to make it more comfortable when players are first learning this.
Terminal and Menu Updates
I had some feedback from a few different players that some things in the terminal screen are difficult to find, like the upgrades page on the market, and that the difference between cargo and storage wasn't clear at first. I think I initially went for a light approach to explaining this screen because I didn't want to get in the player's face with explanations that they might not need, but also because the menus were intuitive to me (which is obviously a trap most developers will fall in to).
To help with this problem I've added little popup explainers for most of the terminal pages that show when you first navigate on to them. I've kept these short since I don't think people like being assaulted with tutorial text all the time, but hopefully they'll nudge people in the right direction. There was also the issue of some players not realising that the demo continues after the tutorial, so I've made navigation to the "next job" page unavoidable, and repeat the term "next job" in a few of the popups they see up to that point, which should hammer home the existence of more stuff to play.
Another little addition which is only slightly related to this is a "NEW!" tag on items when they first become available in the market place. I added this because at the moment I'm adding a lot of new items and I realised it's not obvious when there's something new to go look at, and it would be annoying for players to go look and not find anything. It was a simple addition, but I think it looks quite neat and tidy.
Secondary Control Bindings
You can now bind a second key to a game control, so if you can't decide between WASD and Up-Down-Left-Right, you now don't have to! This is something I definitely should have had in when I first added control binding, but I thought it wouldn't be necessary and that I couldn't display it properly in the UI (I would have preferred to let you bind as many keys as you like to a game control, but there's just no way I could pull off the UX for that given the tiny screen in the game). The tipping point for making me add this was watching some people play the game on SteamDeck and see them trying to use the D-Pad or the left stick for menu controls, then I had to say that it's either one or the other, which made me feel like a half ass. :)
Here's a full list of the changes for Version 0.7.4 of the Demo:
Changes
- New market items are tagged as "NEW!"
- Back button can now be used to navigate back from terminal pages to the menu buttons
- Added item descriptions for some items that are now able to be picked up
- Items ejected from cargo are now pushed away with force based on their mass, so all items are pushed out at roughly the same speed. This is to stop heavier items getting backed up
- Added charging up SFX for gatling gun
- Scrap processor can now detect when an entity is stuck in its door and then turn itself off, pushing the entity out
- Updated some tutorial wording to make it clear that a button needs to be held down
- Added counters for tutorial tasks so it's clear how much needs to be done to move on to the next step
- The second secret message that the player can see in the game is now visible in the demo (previously it was only shown on the day after the demo ended, but better to show it in the actual demo)
- Upgrade info can now be viewed in the ship page, and can uninstall for a fee
- Main menu shows "no mouse controls" popup if you keep clicking the mouse
- Added popup explainers for most terminal pages
Tweaks
- "\" button is selected by default when buying tool/upgrade that can be installed immediately
- Tweaked a scrap processor exploit so that it's less effective (but still in the game since it was funny)
- Terminal settings page buttons now wrap from top to bottom
- Video settings "integer scaling: on/off" now changed to "scaling: pixel perfect/stretch" to be a little more explanatory
- Day 1 ammo reminder happens after 5 shots instead of 10
- Tutorial asteroid layout updated to be closer to the left panel so it's easier to look between the scanner and the asteroids
- Turned on stuck entity detection for the extraction ship (if player exploded inside the extraction ship then the physics objects of the shrapnel would get stuck inside the extraction ship's physics objects and infinitely make collision noise)
Fixes
- Removed blank job spec from the end of demo job list (this was used as a blank slate when developing new levels and sneaked in the demo)
- Fixed some late game terminal features showing during the demo if you play for many days
- Fixed issue where you can start rebinding for a device you don't have connected (gamepad if on PC, or keyboard if on SteamDeck) and then can't back out of it
- Having negative credits doesn't stop you starting a job without a permit fee
Hello!
It's been a while (about 2 months actually!) since I've put out an update for the demo, making it v0.7! I've been working mostly on content that comes after the demo ends but I realised there are still quite a few tweaks and bug fixes that the demo can benefit from too. There are even some bigger things in there too, like the intro cutscene, and some new upgrades.
Here's the full list of changes you can see in Demo v0.7!
General
- Intro cutscene!
- Activator tool now shows more informative text
- Drones will beep and complain when damaged
- Drones can now be deactivated/activated
- Reduced attractor beam length and width, and added upgrades to increase these
- Added lateral control (strafe) upgrade
- Added refurbished explosive charge
- Crystals now create particles when colliding
- Added background signal noise modifiers so that using different tools creates some interference with the scanner
- Entities like drones, containers, etc. now give off a pulsing signal
- Moved some unnecessary stuff out of the save file, which should help avoid breaking changes in the future
- Entities attached to asteroids now leave a slightly larger hole when they're detached
- Small change to how red crystals determine which direction to move in
- Better scrap placement on randomised levels
- Some small changes to story text
- Improvements to NPC pathing code, more performant in most cases and more precise overall
- Lowered damage required to open containers
- Tweaks to tutorial so that scanner functionality is better explained and the explanation is visible while you're actually meant to be scanning
- Added hint on day 2 about being able to push asteroids safely
- Containers will now always gently push their contents out (previously they only did it for a short period and things could stay hidden in there)
- Added message when finally paying off debt
- Changed "Civilian Capital" to "Civilian Resources"
- Archived mail is now sorted properly and displays date in the list
- Tweaked positioning of crystals on charge training day so that they're easier to get with a second charge
- Job times and permits are sorted now, and the selection with the most amount of time is selected first
- Red crystal shards value now add up to the value of a full shard
- Added confirmation popup when restarting a job
- Added rounded corners to some physics objects to make them easier to handle and less likely to get stuck when trying to pick them up
- Charge launcher build up SFX now uses tweaked volume and pitch
- SFX now plays when entities detach from asteroids
- Tweak to tool usage colour on tools page
Fixes
- Fix for message sometimes flickering on and off once when starting a new job
- Upgrades are now removed from the market after installing them from the market page
- Fixed some cases where entities are trying to interact with the physics objects of entities that were removed on that update
- Fixed some maths utilities bugs that were resulting in NaNs and then causing physics to behave in strange ways or be ignored altogether
- Can no longer pause while extracting, dying, or dead
- Gameover and pause menu buttons now wrap from top to bottom
- Fix for laser effect remaining visible after extraction
- Fix for rough transition to new game state when that game state took a while to load
- Fix for TOOL_NONE status notification not clearing when installing a tool directly after purchasing it on the market page
And if you read all of that, here's a peak at the mining laser I've added (only available in the finished game)!
Hello!
Recent work has been 100% on prologue and epilogue cutscenes. This has been pretty interesting from a development point of view because it's an important part of the game which is entirely story and art (at least my approach to it is).
Making the Cutscenes
The design goals of these cutscenes are pretty simple; the prologue needs to quickly set the scene for the game as well as give a little introduction to who you are, and the epilogues need to wrap up the story and provide a satisfying ending (though not necessarily complete closure). I wanted to use Papers Please's cutscenes as a model, since they're simple and effective, but also very accessible in terms of development and artistic skill.
The actual making of the cutscenes was quite straight forward. I worked on the prologue cutscene first since it's a straight sequence without any variations (unlike the epilogues) and the storytelling goals for it are pretty simple. I sketched out a bunch of panel ideas, from there worked out a sequence that would let me show and explain the setting, and then got to making the actual pixel art.
I found that they came together quite easily (compared to some of the epilogue panels where I'm trying to show more complex scenes). The small size and reduced colour palettes help with that, I think, but I'm also enjoying pixel art more and more, and this game seems to have been the perfect thing to properly get started on it with.
(I had a rough time making this video, and I'm still not 100% happy with it. More on that below.)
Coding the cutscenes was pretty pleasant. I now have a little cutscene engine that takes arbitrary sequences of panels and captions and displays them in order, letting the player skip to the next panel or the whole thing. I also made it so that the highlights in the captions are specified in the source text by enclosing text in pairs of asterisks, something which will come in handy if I get round to adding localisation support.
Recording for YouTube
To make it easy to show the opening cutscene for this devlog I thought I'd just record it and stick it on YouTube. I thought this would be easy but I had huge issues getting the colours to not appear super washed out in the final uploaded video. I think I haven't really had this issue so far because I've mostly been using gifs which tend to have very true colours (at least for pixel art), or the videos I have made haven't really had noticeable colour issues (the trailer for the Alpha is mostly fine.).
I tried a lot of different colour formats for the video, and had some really nice results until it finally came to upload to YouTube. Ultimately I ended up moving from using ShotCut for my editing to Davinci Resolve and then just manually colour grading the video until I was happy with the final uploaded video. I'm still not 100% happy with it, but I need to move on at some point, and the cutscenes are going to look fine when rendered in the actual game.
I've included a gif version of the cutscene here so you can see the colours a little more as I intended.
(Text is a little squashed by the page here, so open in its own tab to see nice crisp pixels)
Finishing Up Epilogues
I still have a little bit of work left to do for the epilogue cutscenes, and then some tweaks to make sure everything is cohesive. Since there are multiple endings to the game (at least 5 at the moment, with varying levels of difference) I want to make sure that each path and its epilogue is actually satisfying, and players don't get punished for their choices with a lame outcome to the story. Doing all this art and figuring out how to end things has been a really welcome break, but I'm ready to start designing and coding some more interesting tools for the player's ship now. :)
I'll leave you with one panel from the epilogues that I hope is interesting enough while not spoiling anything.
Hello!
There has been a lot of progress recently but not a lot of big exciting things to show off, apart from maybe the mines. Mostly I've been working on story and levels to build out a single run of the game to the length I want. I think this has also been the longest break in dev logs, which shows I've either run out of interesting things to talk about, or I've been way too stuck in the details of everything and now need to come up for air.
Mines!
As part of adding some more chaos and danger to the levels I worked on some exploding mines. They're quite simple, in that generally they will explode if you get too close, but combining that with physics and the ability to hide them makes for some fun and unpredictable scenarios. There's a story reason for these mines being here while pilots are engaged in peaceful mining activities, but I'll talk about that a little bit more below.
There's a Seeker mine, which will roam around the level looking for a target, and once it finds one will follow it until close enough, and then explode! This uses the same pathfinding as the Drones, though I had to update it to be able to deal with pathfinding to a constantly moving target. I also got to test out the pathfinding's parameterisation of minimum path widths, since I wanted the Seekers to move quite close to things and not take a longer and safer path. Here's a gif of one creeping up on the player:
There's a very simple "touch" mine, which has four pressure points on it which when touched will detonate the mine. Pretty standard but also useful to the clever miner who can have them explode where they want. I actually ended up updating some core entity code for these guys since I wanted to be able to embed them within asteroids and have their pressure points work perfectly.
The third type is the Jumper, which are definitely my favourite (maybe for obvious reasons). They're embedded within asteroids, sometimes visibly and sometimes not, and jump out of the surface to explode as close as possible to a target. If you're fast enough you might even be able to catch one...
Giant Asteroids
I'll quickly mention some giant asteroids that I've been adding in preparation for some more "diggy" tools I'm thinking to add. When adding these I had to update some of the game's screen wrapping code to handle entities that could be off both the top and bottom of the screen at the same time, which had just never happened before. I also found out that the wrapping code happily handles giant entities colliding with themselves!
(Giant banana is for illustration purposes only. I can't guarantee that there'll be a giant banana in the game.)
Story
Much of the work I've been doing recently is on writing the story and events that take place, and then building out the rest of the levels for a full playthrough. I didn't start this project with the goal of writing a cool story, but I knew I needed some form of story in order to give the game structure. To that end, I wanted the story to be simple and coherent, give an actual reason for the events and scenario of the game, and then not get in the way of people just playing the game. I've heard a few people actually describe the writing as good, which is not something I expected, but I think the best thing for me is to not focus on making an amazing story, just on an overall good game.
So the story I've been working on involves an organised resistance group, the mining corporation becoming more involved with military corporations, and general background worker exploitation. Through all of this you are trying to pay off your debt before your contract is up. This all ties together through your choices, some of which are very explicit (like replying to a mail) and some of which require a little more commitment and action from you (trying not to spoil anything here). But what I've ended up with here is a story with multiple endings, which is cool but now I have to keep track of these endings and provide some satisfying closure for each. :)
Full Playthrough
I've now finished a first draft of all of the levels and general flow of the game. I've been aiming for 4-5 hours for a single playthrough, then there's replayability for different story choices and upgrade/money choices. This has been one of the most challenging parts of development for me, having to sit down and think of levels that are interesting, fresh, and let players play how they want. But I'm happy to have done it, and I'm excited to start play testing the whole thing and see how it holds together.
What's next (or what's left)?
Now that finishing this project is feeling closer than ever, there are only so many things left on my todo list. So I think in roughly this order, this is how I'm going to tackle them:
- Play Testing. A few full playthroughs of the game as-is will help me take proper stock of everything.
- Endings, Prologue, Epilogues. I need to properly track each ending and see how I can make each one satisfying, then create epilogue cutscenes for each. Probably more on this in another devlog.
- More upgrades! Lots of ideas.
- More tools! Even more ideas.
- Localisation. I'm going to sit on this one for a bit first, not sure whether I want to do it before or after release.
We'll see how all of this goes :)
Hello!
Recently I've been busy working on procedural generation for levels, which is something I didn't originally plan for but started to look more attainable as time went on. Much like the previous work I did on path finding, there are some difficulties that come with doing this kind of thing for a free-form environment and not one that's nice and grid based, which I'll talk about more below. Even though I'm still planning to hand design a lot of the levels, this will really help to add some extra choice for players, and even open up the possibility for an endless mode once the main game is finished.
Quick note on the gifs in this post: to be able to show the generation slowed down like that I hacked some stuff together (which I explain at the bottom of this post). In the actual game this generation happens in milliseconds.
Deciding on Proc-Gen
Originally I only planned on using procedural generation for the textures of the asteroids and not the levels themselves. My idea was that since the game isn't going to be infinitely long, and procedural generation is hard to actually make good and interesting, I could hand design each level instead and reap the benefits of a human touch (like placing resources specifically to trick players or give them a huge payoff). I had a huge love of procedural generation when I first started programming, and made lots of little experiments but also wasted a lot of time trying to get the results just right when I could have been putting more effort into other things. So this was partly influenced by me not wanting to get stuck with a task I wasn't sure I could actually pull off.
Now though, decent procedural generation started to seem more attainable. After working on the game all this time I felt I had a much better understanding of what worked and what didn't for levels, and how I could have that pieced together randomly. This is partly confidence from having hand-built a lot of levels, and partly from having more tools available to use for this (I say tools, but I mean clever code for interacting with the physical shapes of things).
I decided to give myself one week (which turned into one and a half after other commitments) to have a serious go at it, so what you're seeing here is the result of that. I'm quite pleased with the result, and I think it can only get better with tweaks and added features.
Step 0 - Parameterisation
The generation is actually quite heavily parameterised, with me specifying exactly how many asteroids of each size and type, how many resources of each type, what destruction to apply, and finally what other entities to place. Because of this, I'm a little reluctant to call this "procedural generation" since it's more just clever placement of things. When I think of procedural generation I think of the huge worlds of games like Dwarf Fortress. But this approach works well for me because I do want to really specify what goes into a level for the purpose of balance and some form of predictability.
Step 1 - Asteroids
The first step is the placement of asteroids, since they're the largest objects on each level and everything revolves around them. There are four different sizes of asteroids (Large, Medium, Small, and Tiny) and currently three different types (Purple, Red, and White), with parameterisation allowing to specify exactly how many of each we want. There are also asteroid presets, which are hand designed placements of asteroids, with each asteroid shape having roughly four presets to choose from.
Very roughly, this is the process for placing the asteroids:
1. Select the largest asteroid size available
2. Select an available asteroid type for this size
3. Find a random place for this asteroid with some additional padding around it
4. Decide whether we will use a preset
4.1. Find all presets which we have available asteroids for
4.2. Place a preset which doesn't intersect with other asteroids
5. Decide the total number of asteroids in this cluster
6. Place asteroids in this cluster until we reach the total number
6.1 Choose a random asteroid in this cluster
6.2 Choose a random size smaller than this asteroid that we still have availability for
6.3 Place a new asteroid of this size next to the current asteroid
6.4 Repeat until we've placed all asteroids in this cluster
7. Repeat until we've placed all asteroids
I find this strikes a decent balance between being random, interesting, fun to fly around, and also semi-natural looking. I'm thinking to experiment with broader rules, such as making everything more scattered or condensed.
Step 2 - Destruction
Next there's the chance for some destruction to be added, so that the level looks like someone else might have been here before and done some mining. This is done before placing any resources or entities so that we don't place anything exactly where we make the destruction and make it look like someone excavated some resources but then decided not to take them. The destruction is also physically simulated so that asteroids look like they've actually been moved by what's been damaging them, and having resources/entities placed while that is happening can make things look a little too random.
At the moment there are two types of destruction for randomisation; explosive charges, and bullet impacts. The destruction for explosive charges is positioned on the circumference of Large or Medium asteroids, since placing them on smaller ones can completely obliterate them, making it pointless to even place them. And the destruction for bullet impacts are positioned starting from an empty point in space and then casting rays out in a fan to see where bullets could impact, and then creating small destructions for those positions. After each destruction there's a random chance to place some debris associated with it, such as shrapnel from explosive charges, or un-detonated bullets from bullet impacts.
Step 3 - Entities
These are the different entities that we might want in a level, like the scrap processor or random pieces of scrap lying around. I plan to add individual rules for each of these so that I can have specific results, instead of trying to come up with one master rule for everything. So if I want one level to have a container that's always empty, I might specify rule CONTAINER_EMPTY in the parameters, or if I want a later level to have a container with some good loot in I might specify rule CONTAINER_LOOT_3.
Step 4 - Resources
And finally there are the resources, which are parameterised by type (Blue, Green, or Red), quantity, and the range of depths they can be placed at. Currently, there are rules stating which asteroid types a resource can be placed on (Blue crystals only on purple asteroids, for example), and for each asteroid shape I pre-compute the resource placement positions and their depths, so when it comes to placing resources we do the following:
1. Choose a resource to place
2. Get all asteroids this resource can be placed on
3. Get all placement positions for the given depth range for these asteroids
4. Choose a placement position out of these positions that doesn't overlap with an existing resource
5. Place the resource there
6. Repeat until all resources are placed
This is fairly simple but allows for good distribution of resources in the level. I do want to improve this by forcing some clusters of resources, or giving a larger weighted range of depths, so you can specify that a resource could be placed at depth 1, but it's much more likely to be placed at depths 4 to 6.
Hacking these Gifs together
I wanted to show gifs of the generation happening in somewhat slow motion, so you can see what's going on. In the actual game this generation happens very quickly (Under 100ms in debug, which makes me think I have a lot more room if I want to use more complicated logic) so I needed to slow it down and also show it happening in real time while the level is running.
First I tried throwing it on a separate thread and locking between updates so that the main thread and the generation thread weren't fighting for the same resources, but even that didn't work because of some restrictions to using graphics components off of the main thread (I generate each asteroid's texture as it's created).
So what I ended up doing is turning each method in the level generation into a C# Generator Method, which basically means that execution can pause and return at specific points. With this I can do everything on a single thread and wait for a timer to elapse between each level generation step or placement. Fun!
What's Next?
Now that I have this working I'm able to very easily add more "filler" levels between the more interested hand designed levels. It also means I can hand design more levels as whatever the procedural generation outputs is completely editable using my makeshift level editor, so if I see it generating something that I know could be better, I can do a few manual tweaks and voila.
This also sets the game up well for a potential endless mode after release. Though I won't go as far as to promise this, because I have no idea what the state of things will be once I actually get there.
If you've got to this point, thank you so much for reading, and I hope you found this all even slightly interesting. If you did, be sure to check out Deep Space Exploitation on Steam!
Hello! This is everything I've been up to over the past two weeks. Adding more interaction to the game, gearing up to create the full length of the game so I'll have an end-to-end that I can start refining, and of course working through improvements and feedback from people. So here are the major changes, minor changes, and bug fixes I've done for v0.6.6! Scrap Processor Jobs As a bit of variety and also story, I've added scrap processing jobs where you can collect items of scrap and feed them to a scrap processor which will then process them into a higher value cube. This is meant to be a bit of fun interaction but also provides a bit of opportunity for the game's story, as well as helping to enrich the game with more mission types and interactions. This is also linked to an upgrade for the player ship, which is available in the demo but hidden as a little secret... Destruction Code Update I've updated the code used for creating asteroid destructions so that now it can take arbitrary shapes as input (Up until now it was only circles). This was necessary now so that I could allow any shaped item to be attached to an asteroid and then be dislodged when hit and leave only a hole of its own shape. This also prepares things very well for shaped charges and other things that will leave a non-circular impact on asteroids. I've also improved destruction so that there are no false pieces of asteroids left over. By which I mean pieces of asteroids that are drawn but don't actually have any physical presence backing them up. This happened quite a lot when using the gatling gun repeatedly on one area of an asteroid. Tutorial Rework I've had the massive fortune of being able to watch a few streamers and youtubers play the game recently, and I noticed that the tutorial definitely needed improving. The main problem was that it was too easy to miss the sections explaining the Scanner, since you could blow right through them without even reading. I've reworked things now so that you have to go through the scanner explanation first before your mining gun activates, since what I saw before was as soon as the mining gun would activate people would just keep blasting and they would accidently complete the scanner tutorial steps. Level Editor Updates I've updated the makeshift level editor I use so that items can be chosen and placed much more easily and starting destructions can also be added. This is a super makeshift, solo-dev, style level editor that uses a bunch of confusing hotkeys and outputs code to a text file that I just copy/paste into the class for the level. Which is all fine because it's only me who's going to be using it :) I uploaded a little video of it here: Maximised Windows Another thing I saw when watching streamers play was an annoying issue where if you try to maximise the game window (not fullscreen) on 1920x1080 the game's integer scaling will kick in and force the game resolution to the integer below, effectively making the game appear rendered much smaller in the middle of the window. This was happening because the title bar takes up some pixels and actually makes the window height about 1051, which the integer scaling doesn't like. This went unnoticed forever because both of my monitors are 1920x1200, so it's my fault for not testing natively with the most resolution! The simple fix was to give a little vertical tolerance to the integer scaling, so you can lose some pixels off the top and bottom of the screen before it will kick in and change the actual resolution. Other Changes - Default tool hotkeys now use backtick for Activator Tool, then correct number keys for tools - SFX and UI volumes default to 75% - Tutorial tells you that you can rebind controls - Increased physical size of player ship cargo hold, so picking up certain items is easier now - Volume selectors and Debt Repayment amount selectors now change in higher increments when holding down buttons but still move in single increments when tapping. - Market now shows tool ammo amounts and cost before buying - Debug overlay (via backtick) is no longer available in release builds - Any item can now be attached to an asteroid - Changed confusing "TL_..." style statuses back to "TOOL_..." - Improved checks for entities stuck inside other entities, should now kick in faster on actual instances and less altogether on false positives - Added check for unsold resources in cargo before starting a job. A popup will show asking if you want to continue - Improved physics particle performance drastically in worst case scenarios - When buying an item in the market you are now prompted over whether you want to place it in your cargo or storage - Loans will now cover any negative credits you have, plus 100 - Some items will now appear in the market earlier - Storage slot count reduced to make it more important to buy the upgrade - Debt repayment page starts with the amount selector selected - Re-ordered the terminal pages so that Inventory is before any other page where you can spend credits, so you can go straight to selling your resources and then go to spend the credits instead of going up and down Fixes - Can no longer rotate asteroids with (invisible) mouse-over and scroll - Laser reflections are now limited in number, this fixes a crash where the laser start is stuck inside an object and reflects infinitely - Unused extraction ship bays are now "filled in", this stops the player glitching into them and getting stuck if they're positioned on the edge of the map when the extraction ship enters - Fix for laser sight line effect being accumulating over a number of days - Tools no longer stay active if held down when extracting - Late extraction fines are now actually applied (time below zero was not making its way to the debrief page!) - Property damage fines weren't being reset when you restarted a job
Hello! Next Fest has been pretty intense so far. A lot of feedback and chatting with players about the game. Here's a collection of tweaks, bug fixes, and even a couple of minor features I managed to get in for version 0.6.5 of the demo.
Next Fest is still in full swing, so if you haven't played the demo yet, please do and let me know what you think!
Laser Sight Special mention for the laser sight, which I'm really happy with (it reflects and lights up particles!).
Features - Laser sight upgrade - Volume settings are now split between SFX, UI, and Music, and can be set from 0 to 100 (previously 0 to 10). This should help streamers who have more sensitive setups.
Balance - Hammer easier to control - Some items are cheaper now - Crystals sell for more - Don't show cycle tool reminder on charge training day - Charge training hints at key for dropping charges from cargo - Added status notification for an empty tool slot - Lowered damage necessary to force a container open - Increased time limits across all days - Scanner tutorial step now requires you to get closer to the scanned resource - Some wording changes in mail messages
Fixes - Default key bindings are set properly, instead of the debug ones - DPI Awareness is now working again (proper resolution scaling when you have Windows scaling set) - Activator tool sprite now drawn on the correct layer - Possible fix for losing BASS audio after PC wakes up from sleep, plus additional logging around this in case the issue persists - Stopped null tool drawing pink sprite - Fix for culture variant text comparisons. This was causing crashes due to Font validation on PCs with certain locale settings - Log file uses 24h time instead of incorrectly using 12h - Hammer retract animation now plays properly - Mail reply scroll bar no longer shows on other mail pages when there are no replies - Additional logging around entity wrapping and asteroid destruction to help with an investigation into a wrapping bug - Extraction ship typo when extracting ("EXTRACING" -> "EXTRACTING")
Hello! One frequently requested ship upgrade in the game is a kind of laser sight (and lasers in general!) to make lining up shots easier. So in preparation for Next Fest I thought I'd try and get this in, along with some of the cool ideas I had for it. I think it turned out really nicely and paves the way for mining lasers to be added soon. I thought I'd give a little explainer of how I went about creating this effect, since it's not too complicated and only really requires knowledge of stencil buffers. Before I get into it, I'll quickly mention that everything I talk about here is live in the demo that's currently on here Steam. Next Fest is a big deal for tiny indies like me, so wishlisting the game and sharing something about it around this time would really be awesome. Step 0 - What do we want? Most of all, this effect needs to be useful but not overwhelming. A big bright red line across the screen would be really dominating and take visual precedence over other things in the scene. Next, it needs to look convincingly like a thin beam of light and not some debug overlay. And finally, we want some cool simulation-like details, like lighting up other things along its path and reflections.
Step 1 - Tracing the path To trace the path of the laser I use ray casts against the physics objects in the game world (I've avoided calling these lasers ray traced, even though I'm technically tracing them with rays). I start from the player ship in its current facing direction, find the closest intersecting entity, then either stop there if the entity is non-reflective (like the asteroids) or continue from the intersection point using the normal of the intersection to calculate the new direction of the laser. The tracing continues like this until it runs out of distance. For each ray cast we store data about the position, direction, and what it intersected with (if it intersected at all), which we then use for drawing everything. One caveat to all of this is that I wanted the lasers to wrap around the game world like everything else, so at the start of each ray cast I calculate the distance to the edge of the play area in the current direction, and only cast the ray for that distance. If the ray reaches that full distance without intersecting anything then it means we have to wrap around to the other side, in which case we continue with a new ray cast with the starting position adjusted. Step 2 - Basic Drawing The basics of the effect are the fading out and fading in lines at the start and end of each segment of the laser, and the glow of the laser on the entity it collides with. The fading lines are draw point-by-point using Bresenham's line algorithm, this lets me draw the line without any aliasing (so it's guaranteed to be 1 pixel width) and also allows for better control over the fading out of the colour on the line (currently the fading is linear, but I'm thinking to bucket it so it has more of a pixelated feel). The glow where the laser collides with an entity is done by first writing the colliding entity's sprite to the stencil buffer, then simply drawing a sprite for the glow using that stencil (If you're not familiar with stencilling, check out this OpenGL explainer: https://learnopengl.com/Advanced-OpenGL/Stencil-testing). This gives us our basic laser effect, which works well and gives us everything we need exception for a few extra details. Step 3 - Particles One cool thing about lasers in real life is seeing them light up dust in the air, or lighting up a line straight through smoke, so it would also be cool to have that happen with this laser effect. This is done in a similar manner to the glow on the colliding entities. First we write all particles to the stencil buffer, and then we draw a line for the laser using that stencil. This particular line we draw is done using a sprite which is stretched out along the line of the laser, this lets us get a wider and softer glow, and is also much more efficient than tracing out the whole thing point by point. Step 4 - Background Glow Finally, I thought it would be nice if you could actually see the laser in the background of the destroyed asteroids, as if the laser were coming super close to the background but not actually hitting it. Much like step 3, this is done by writing the asteroid backgrounds to the stencil buffer and then drawing a very faint line with a stretched out sprite using that stencil. Steps 3 and 4 are both done simultaneously for all lasers so that we only have to write the particles and asteroids to the stencil buffer once per frame.
What's next? There's plenty more I'm thinking to do with this, like having the laser refract from some entities instead of just reflect, or having the reflection only happen at certain angles. I've realised this is the kind of thing I love most about game dev, just messing around with little effects and then seeing how they can contribute to the fiction and gameplay of the whole game. The majority of the work done for the laser sight upgrade is kept in a reusable laser effect, which I'm planning to use for more lasers (especially a mining laser). This is quite versatile as the effect collects data for each segment, such as distance and intersecting entities, which can be used to calculate damage or perhaps activate things. Thanks very much for reading :)
About
This page aggregates Steam news feeds, patch notes, and developer announcements for Deep Space Exploitation, sourced from official Steam community posts.
Major updates, balance changes, and seasonal events often correlate with player-count spikes — cross-reference announcements here with the live charts on the main Deep Space Exploitation statistics page.
Articles link back to Steam for full changelogs. SteamScope refreshes news entries as new posts are published to the game's Steam hub.