There have been a lot of changes in the time since the DRONE SMUGGLER Early Access launch and, since the game as of 0.1.7 is really hitting a lot of good notes for me right now, I thought this would be a good time to step back and make a plan for what's to come.
I've been collecting color swatch screenshots from the HUD during 0.1.7 testing - these will serve as the basis for more "curated" color combinations while still leaving room for randomly selected ones!
Recent updates have been based heavily on feelings I had during playtesting - which is to say heavily based on vibes and what can be accomplished in a few hours sitting with the engine open and a few simple ideas to implement. It has been important to me to get the foundations for Privateer Mode (more on that below if you haven't been following the game's description or announcements) into the game before delving too much into RNG-based items and upgrades - mainly because I have a ton of ideas for how to implement those little rogue-y features into this game to help make each ship feel like a custom creation for the pilot in command, and I know if I start working on all of that I'll get lost in a procgen rabbit hole that I might never climb back out of :)
So in the interest of protecting myself from myself, I've made a plan to roll out some foundational features that will provide structure for Privateer Mode and enhancements to Arcade Mode across the next three updates - two minor "staging" updates and one big one that will bring a lot of behind-the-scenes structure that I'll need to start building out all of those fun mod concepts.
====
0.1.8: Color Collection, Cargo Slots, "End Orbit" Option
To inject some extra fun and importance to the various color mechanics which currently serve as a simple way to keep the game looking and feeling fresh even after hundreds of orbits, I want to bring some changes in the next update that will treat color as a collectable and consumable resource for DS pilots.
If all goes to plan, 0.1.8 will introduce the concept of Pyxels (Px) as resources in-game that are stored in one of three resource containers on the player ship. Pyxels are divided into three "shades": Red Pyxels (RPx), Green Pyxels (GPx), and Blue Pyxels (BPx). Later updates will add to the functionality and purpose of collecting and spending Pyxels, but 0.1.8 will simply provide the storage containers and a means of monitoring them in the HUD, and a simple collection mechanic where the player ship will receive Px when destroying asteroids. If a player laser or collision destroys an asteroid, that asteroid's color palette will be evaluated and the player will earn RPx, GPx, and/or BPx based on the score value of the asteroid and the percentage of each of that asteroid's color channels - in other words, the more red, green, or blue that is present in the palette that determines that asteroid's appearance, the more RPx, GPx, or BPx the player will collect when destroying that asteroid.
You won't be able to do anything with the Pyxels you collect in this way in 0.1.8, unless things move along more quickly than I'm expecting, but it'll be a good first step towards giving pilots a way to power HEXes and other upgrades that are installed in their ship.
Seeing what modules are installed in your ship and connecting modules to different Pyxel sources on-board will be vital to maximizing your ship's performance, so some groundwork will be laid in 0.1.8 for displaying cargo, Pyxels, and modules in the HUD while playing.
Lastly, pre-selected 3-swatch color palettes will be introduced as the normal way that color combinations are selected for the 4 palettes generated for each level. Currently, there's a lot of randomization and logic that scrambles and mixes and matches colors - and a lot of those combinations are cool and fun to fly around with - which does mean that sometimes the colors are tough to play with and not conducive to a fun orbit through DS shadespace. In the interest of helping to solve this, I've been collecting screenshots of color combinations that I particularly enjoy and will be creating a library of tricolor palettes that the game will select from when building a level. If you're an RNG-lover, like me, fear not - there will still be fringe cases where the current randomized way of choosing colors still gets used.
0.1.8 will also introduce the option to end an orbit early - enabling pilots to essentially retire their current run without needing to destroy their ship; perfect for situations where a level or ship config has grown stale and a pilot wants a graceful way to bow out (as opposed to ramming the nearest asteroid at full speed).
I expect this to be out, with some modifications and likely other spur-of-the-moment changes that seem natural during the cycle and that don't detract from these overall objectives, sometime in the next week and not later than the weekend of August 23/24 unless life demands attention in other arenas in the interim.
====
0.1.9: Proc-gen HEXes & More Functions for Consumables
A simple version of the Shortwave Energy Shield consumable HEX - commonly referred to as an SES - as currently implemented in the development build. SES mods allow the player to project a shield that absorbs all incoming enemy lasers for a short period of time.
0.1.9 will be the last round of adding simple, foundational elements for gameplay before stepping back to focus on the bigger picture of Privateer Mode. In 0.1.9, the player will be presented with 0-3 procedurally-generated HEX modules at the start of each Arcade Mode orbit. Pilots will be able to choose up to one of these to add to their ship, and they will do simple things like add new HEX slots (and therefore, further expansion capability) to the ship, modify one or more ship stats, or expand the capacity of one or more Px shades that can be collected and carried onboard.
HEX modules in 0.1.9+ will be fueled by Px and will require pilots to map their Px resources to different modules. Some modules may accept any Px shade, a combination of Px shades, or a specific Px shade - this will be something that depends heavily on RNG at the start and will likely take some time to tune correctly, but the goal for 0.1.9 is to have the simplest form of this functionality in place so that the player has to consider which modules are installed and which shaded Px resource pool those modules are powered by before starting their orbit.
Speaking of powering modules, HEX modules that are installed the player ship will persist between orbits and will need to be powered up through the collection and consumption of one or more Px shades. Once a module is fully charged, it will remain that way (even between orbits or gameplay sessions) until something causes it to lose that charge. Things that might cause this:
Activating a generator-type HEX that provides temporary functionality in exchange for spending some amount of Px each time
Taking damage from enemy lasers of a specific color might cause modules that use that shade of Px to lose some or all of their charge
Collisions between the player ship and space objects might cause random modules to lose some or all of their charge
When an orbit ends because the player ship is destroyed, all installed modules will remain installed but will be uncharged when the next orbit is started
Pilots will then need to collect Px resources to re-charge those modules to gain their benefits in-game.
To support all of this, a pre-launch scene (working title is Hangar, for now) where the player can review available modules, assign them to slots, and connect them to Px resource containers for power will be created. The Hangar will be displayed at the start of each orbit so that the ship's configuration can be tweaked and experimented with each time you re-enter shadespace.
This obviously has a bit more complexity than what 0.1.8 presents, but some of the groundwork for these systems has already been laid in previous updates - so it's really just a matter of building on that code and making sure things look and feel sensible for pilots getting familiar with these systems while remaining flexible enough to feel powerful and customizable to more experienced smugglers. I'd estimate another week or two worth of work to get from 0.1.8 to 0.1.9, so targeting the end of the first week of September as the earliest-possible release window for 0.1.9 seems reasonable to me at this time
====
0.2.0: Privateer Mode
Once 0.1.9 is ready for release, it'll be time to dive deep into the structures that will be required to support Privateer Mode - the career or campaign mode that will offer persistent gameplay and expanded modules and opportunities for discovery and experimentation to pilots who want more depth than Arcade Mode can offer.
This is all still a plan-in-progress as well as a work-in-progress, so I'll simply copy my notes from the project here and then leave you with a few thoughts on how I see this being implemented and what I'm hoping for from the small community of players who have already taken a chance on buying and checking out DRONE SMUGGLER:
The first iteration of Privateer Mode is planned (at this time) to include, at a minimum:
Actual launch menu with Privateer and Arcade mode, as well as options & end session buttons
Actual stats tracked for each orbit, tracking mode, ship stats, level generation parameters, and gameplay stats
First simple version of privateer mode with:
3d printer HEXes that generate a consumable mod (DRK, SES, RFM)
These can be purchased at stations or earned as contract rewards
Collecting a dropped consumable version of the module instantly charges the module, allowing it to be used once
Collecting Px of the color(s) specified in the printer module (RNG) will charge the module once the charged threshold is reached
Basic contracts with simple parameters and rewards
A prototype NPC android/bot that serves as the interface between the player and each Shadespace Station
HUD cargo slots and actions mappable to controller buttons / keys
HUD resource slots showing quantities and connections to power/charge HEXes
Simple +1 / +2 purchasable HEXes that modify one or more ship stats, heavy RNG
A set of 6-12 pre-generated "local" star systems to choose from in Privateer Mode, as well as a "Survey" option that spends collected resources for a chance to "discover" a new star system that can be traveled to and played within
A simple text-based representation of "known" systems, local and discovered, so that pilots know what is available to them when pursuing contracts or their own goals
This is obviously a much larger scope than what is laid out in either the 0.1.8 or 0.1.9 plans and, unlike 0.1.9, not much work has been done in the background that already supports some of these ideas - so the likely outcome is going to be two or more small updates (0.1.8, 0.1.9, and any other small incremental changes that feel right in the meantime) in quick succession followed by a longer period of development and testing work which will go into 0.2.0.
I'm hopeful that with the small collection of players that have already picked up DRONE SMUGGLER, some community feedback will start to trickle in on gameplay and the direction and vision for the game that I've laid out here on the various store page descriptions and community announcements.
As that happens, I'll start prioritizing the first few rounds of 0.2.x changes where I'll work on stabilizing Privateer Mode and the other systems introduced in 0.1.8 and 0.1.9 and introducing changes suggested by the community that feel in line with the philosophy of the game.
At the very latest, I'd hope for a 0.2.0 release sometime in November or December - but that depends heavily on a lot of factors both related and entirely unrelated to DRONE SMUGGLER and its development.
====
And that's all for now! I mainly wanted to put this announcement out so that as players continue to pick up this Early Access version of DRONE SMUGGLER (thank you all so much for your support - even just the handful of people who have added this to their libraries make this such an exciting thing for me to work on) there is clarity about what's being worked on, what the vision for the game is, and how long I expect things to take.
I've been pretty quick (imo) with the last few rounds of updates because things have started to click and I've found ways to build upon earlier ideas with pretty simple implementations - but I expect progress to slow down significantly when I start on 0.2.0 because of the complexity involved. By communicating that ahead of time so that it's not a surprise if you see the release schedule slow down significantly as that part of the project becomes more real, I'm hopeful that trust can be established between me as the sole developer/publisher and the small but so highly-valued community of players that has started to form.
I'm really excited to continue bringing this vision to life - and I hope to see you out in shadespace somewhere, commander! o7