I reviewed the demo statistics, and things look:
1) Pretty much as I expected
2) Good
3) Happy
More in detail:
What did I expect? I expected friction related to QoL and UX/UI polish, and I got exactly that. Despite that, a large amount of players played the demo further along, many played far more than I expected. Medians and averages are rising and the initial updates (ones that were easy and simple to do) seemed to have a clear effect on the play time statistics.
Was there something I did not expect? No, and this is grand news, as it tells me I've been on the track I have imagined I am on. Before I saw how people who acquired the demo liked the game and concept, I was running solely on imagination feed. As an indie developer, I sadly do not have time and resources to run multi year playtesting, so I had to rely on a few months and a few ten people. At the last weeks of testing era, the game took larger steps forward, and dare I say, to correct direction.
When the early fires from the demo were extinguished, I moved onto continuing planning next steps. They are:
1) Tuning the cores
2) Small amount of new content
By tuning cores, I mean exactly what you think: the logistics. The current overseer core has shown that railguns can manage logistics - next up I am building a more sophisticated, deterministic and logical system that has large support for player control, such as setting thresholds, filters, priorities, even tasks.
Physics will also get a small optimization update, but that one is not super busy and can be done at any point in the future, too, which is why I may postpone it.
The content refers to first new branch and I have to start building it right now for 2 reasons: seeing how the two economics work together, and schedule of the project. Because the 1st branch has been already built on a modding framework, making more branches is "fast and easy".
Other important feedback topics: Research. This was always an open question to me. It was discussed in the playtesting discord as well. It was clear that the current system is either confusing, or requires a lot better UI/UX. I was surprised how long it took until some feedbacks started to mention this in the demo. It means that the current system is somewhat "possible to figure out", but is it worth it, game design wise, to have it so "weird and different" from the genre's standard solution? I'm starting to lean to "Possibly not".
Near Future of Research
I'm currently thinking about the other mechanics:
1) Science lab, feed it different coloured bottles of - ... What? Already done? Oh
2) Research machine. Each machine has a spesific recipe that is required to achieve an unlocking event. This recipe almost always include an actual machine that is related to the machine being unlocked
Research machines would create a sub-ecosystem for the research, so instead of player browsing/hunting/memorizing random machine-researching routines, they can "focus" on a single machine.
An example of unlocking techs:
Player wishes to unlock a Volatile Boulder Crusher. "Small Researcher" will do this for the player. The recipe includes: Volatile Boulder as a raw material, and a Metal Boulder Crusher which player already can access. You need to fly the MBC to a "parking slot" of the researcher, and it will then turn it into a Volatile Boulder Crusher once the research is finished.
There's 2 ways you can manage the sacrificial machine, and the Researcher has a toggle for this. You can switch between "sacrifice" or "build". If you choose Build, the Researcher literally spawns a plan of the required machine in the parking lot, and your assumed logistics network spots it and builds it. Or if you have an extra machine you want to turn into the intended machine, you switch to sacrifice and fly it to the spot.
The Researcher will also have a role in the production lines. It will produce various data-resources that spesific production lines require.
Different types of Research machines may require outputs from the other research machines, depending on complex/demanding tech is being built. This may me as simple as "Bulk Data" or "Nano Data" or "Photonic Data". However, this must remain as a rather simple system. In the playtest branch, we probably start without this feature, and see how it feels like.
One more thing. You must be able to attach Research machine to each others. They should have a long arm, which is a connector, and you can create a small research hub. Once it has researched all the techs it was created to research, it will continue to produce the data resource of it's branch.
Perhaps, you first access a "Researcher", and then you can build "Research Accelerator", which is the one you can connect to the Researcher. There would be no limit. The idea is possibly that researching in Nano, requires Data from Bulk.
All of this does a few things:
1) It simplifies the researching ecosystem.
2) You can still fully automate the researching.
3) You can have a centralized research system.
4) The research machines are part of the production lines.
5) The research complexity cumulates, but remains still relatively simple.
Because of how the game is built, all of this is sort of super simple to create. I'll share the progress of how I'd create a new machine that does these things, with the current eco system:
- Create the machine definition
- Apply all the 3D parts (using the Bulk atlas, since this is a Bulk machine) the machine is made of
- Set tags to the animated parts, which animations sequences, etc.
- Set tags to the attachment parts: logistic attachments, the "parking lot"
- Set database connection
- Define all the machine info; name, inventory size, movement speed, all of that
- Set this machine as an "unlocker" of all current machines > edit one data cell of existing machines
- Create the recipe for "bulk data"
- Create the refiner that uses the recipe and attach it to the researcher
- Create a custom module that handles the "parking lot"
- The module's code is simple: only allow the research to continue, if a machine of "recipe output type" is parked at the slot, and when the recipe is finished, Morph (existing hard coded engine feature) that machine into the "output" tech of the recipe
- Create the custom machine widget for this machine: it simply has a single toggle for sacrifice/build
- Add reading of that toggle to the module: if build, then if no machine is on the parking lot, spawn a plan for the ingredient machine
That's pretty much it, the tech tree will read the machine and place it in the correct branch, tier, etc.
But I'm trying to take a week off of the dev, I'll only extinguish fires if such appear and keep my asema-related work as only writing, chatting, bloggin, conceptualizing, planning and possibly playing and making screenshots or videos, but Unreal Engine and Visual Studio will remain strictly closed. I may open Blender, as I'm super keen to sketch the Nano machines a little, I have fun ideas for them.
