I worked on many aspects of the game during the periods mentioned below but I try to provide the actual month/year I worked on each system to give a sense of the timeline.

This is the first Unity game (or game really) that I ever worked on. My initial efforts were focused on quickly creating modular buildings for the game.

I knew that in the future I’d like for players to be able to create similar buildings but really thought of them as two different systems at first. That was the first mistake of many.

Phase I - The Troublesome Magic of Houdini (Nov 2021)

Houdini is a tool I adore so much that I spent a LOT of time trying to find ways to use it for The Maker Way. Trying to force a tool on the game is of course a terrible approach but I was lured to Houdini’s power.

The thing with Houdini is that if you know how to use it, it’s one of the most powerful tools for content generation at scale. In the Spiderman game series, an entire New York City is generated using Houdini.

Houdini also turned out to have a Unity plug in so that was an exciting opportunity. I managed to create a Houdini procedural structure and using the Unity plug in managed to bring it into the game.

However, after additional experimentation, I decided to drop it. The plug-in felt too heavy and seemed to lack continuous support.

I’m happy though that I have an animated gif from those experiments:

Houdini could not be edited in runtime

Phase II - Blender Geometry Nodes (Apr 2023)

I was already creating the 3D models in Blender, so I thought I’d give Geometry Nodes a try. They provide a similar workflow to Houdini although a lot less complex. Geometry Nodes supported my goal of creating buildings in a procedural way and I got something working pretty quickly.

The fact I could plug in the models I was already working on inside of Blender was a plus. I could edit the parameters quickly and create various types of buildings within minutes.

Alas, the pipeline was very cumbersome. The model had to be exported from Blender to Unity and changes to prefabs or parts would mean recreating the structure in Blender and exporting it again. It didn’t make sense. I thought of trying to create a Geometry Nodes plug-in for Unity that will use prefabs from Unity and I’m so happy I didn’t end up doing that.

Quickly creating buildings in Blender

Phase III - 2D to 3D buildings (Sep 2023)

After working with external tools I decided to try and create a tool in Unity. I decided to go with something that I thought will be rather simple. What I had in mind was something akin to the Doom level editor.

You use brushes to draw compartments, platforms, walls, gates. You choose prefabs and then they are placed based on the 2D diagram.

This was much better because it was in Unity but it wasn’t WYSIWYG still. There was still friction in creating the diagram and then having to convert it to 3D to see it in the scene. This back and forth wasn’t efficient.

Level Editor - Doom Style?

Phase IV - Trying to double down on Procedural Building (Nov 2023)

There’s something about procedural generation that really excites me. Maybe it is the similarity to how nature and our world works. There is a set of rules/laws (in nature - physics, chemistry, biology) and everything evolves from said rules.

I bumped (don’t even remember how) into a magazine article about Oskar Stalberg and his system behind procedural generation based on Marching Cubes. It was too enticing to not give it a try. Ended up creating a system that worked pretty well but also was really not a fit for the game. Unlike TownScaper (which was created by Oskar), building in The Maker Way is about making buildings functional and not about showing great variety.

I started thinking about Voxels and decided to set the marching cubes building system aside. If you are interested in learning more about marching cubes and deep proc gen, you can watch some of Oskar’s videos on Youtube.

Oskar Stalberg’s brilliant approach based on Marching Cubes

Phase V - A Voxel Detour (Feb-May 2024)

Probably the costliest mistake in terms of time investment. I was inspired by TearDown and later Enshrouded and decided to look into voxels for building.

Getting Voxels to work at scale with high performance is hard, especially as a solo dev. Figuring out combining meshes, collision on small scale of cubes, accommodating different prefabs to fit structures etc. Building is also very cumbersome if you do it voxel by voxel so I found myself creating voxel prefabs to compensate.

It was just too much. Unfortunately I don’t have a video / animated gif from that work but I did find some premade voxel “prefabs” laying around in the project archive.

Voxel pre-prepared composition prefabs

Phase VI - Manual Placement + Base Modules Player Placement (March 2025)

At that point, albeit late, I was done with “playing with technologies”. As much as I enjoyed it, I realized that a lot of the work I’ve done on procedural generation is not a fit for the game.

I decided to go for the simplest concept: premade structures in Blender, and then building using structure prefabs in the game. All the modules (batteries, fuel tanks, antennas etc.) would also be pre made. Energy simulation would work based on distance between prefabs.

That worked well and ended up being the system for many of the playtest runs I conducted.

Premade modules supporting energy simulation

Phase VII - Attached Machines (Oct 2025)

This was an idea I had on the back burner for some time. Rather than using premade prefabs for base modules, we could use machines. After all, all modules essentially had a similar functionality to already existing machine parts. For instance, the battery module could be actually made from the same batteries used in machines.

This would bring the game closer to the vision that I had for it. I created a new block called Platform Attach - and now machines could be placed on platforms.

This worked exceptionally well and made the game loop so much more tight.

Machines as structures modules

Phase VIII - Achieving Nirvana and Cohesion (Jan-Feb 2026)

Weeks before releasing the official demo, it dawned on me that the way building works is not cohesive enough. It was quite a dilemma whether to dive into this system again just before releasing the demo.

But the problems in that base building system kept staring at me while I was playing the game. Namely:

1. Existing structures in the scene were static and couldn’t be edited
2. Using the range for energy simulation was very limiting. It required an additional layer of visual data to show which machines/modules are connected to which other machines/modules.
3. Creating structures in the Blender/editor was very manual

So I decided I’m going to give it one last try with the following goals:

1. Allowing players to edit TMW structures in the game
2. Energy simulation relationships based on being in the same structure
3. Creating an editor tool that will allow me to build in the editor new structures and will share code with the actual player building sysetm
4. Adding procedural generation touches for columns and lights to be added automatically

What is funny is that once I knew what I wanted to do and had already experimented with all of the above - this took me two weeks to implement (plus another week for bug fixing after some playtesters played it).

I’m thrilled with this version and confident it’ll carry the game to its Early Release version later this year

The current version of base building

The editor tool

Remember: Gameplay is king. Please DO NOT fall in love with tools

Yes, it’s been four years of iterating over base building!

For anyone on the same journey the two key takeaways would be:

1. Start with the gameplay in mind, then find the appropriate tool for it. Don’t fall in love with “cool” tools and try to force them on the game
2. Aim for editor tools and player tools to be the same if possible

If you want to see how it all turned out, here’s a link to the demo: https://store.steampowered.com/app/2421490/The_Maker_Way_Demo

I collected here the 47 most important lessons I learned while developing the game over the last 5 years.

Please bear in mind that I started with zero knowledge about game development, so many of these lessons were painful. I hope you find them useful.

1. Action produces information

At certain points during development, you might hesitate about your game’s direction or what you should work on next. An effective way to get unstuck is to see people play your game. The faster you get the game into people’s hands, the faster you’ll know what works, what doesn’t, and what to do next.

2. Working on the right things

Don’t confuse effectiveness and efficiency. Effectiveness is working on the right things. Efficiency is working on them well … efficiently. When I started tracking my tasks I was surprised by how many unimportant tasks I completed very efficiently. Those tasks didn’t make the game better though. Review your tasks every day and be ruthless about choosing what to work on. At any point, have a decision criterion, such as “Most impact on gameplay”. The criterion can change based on what you are focused on at the time.

3. I never regretted building a tool

Familiarize yourself with developing editor tools as early as possible. Data editors, automation tools, etc. If you find yourself working on the same task repeatedly, you should probably build a tool for it. It speeds up development and reduces mistakes. In The Maker Way, there are 5 different assets that I need to create for every machine part in the game. To this day I don’t believe that I used to do that manually.

4. Don’t overcomplicate testing

Ok. This one is going to be controversial. I’m in Jonathan Blow’s camp here. Writing massive amounts of unit tests, especially while you are still iterating on the game, is very wasteful. I learned this the hard way. Don’t be me.

5. Stay true to your game’s central idea

This is one of the toughest ideas to implement. Can you answer the question: What is the single thing that will set your game apart? For No Man’s Sky, it was “Explore an infinite procedurally generated universe”. For The Maker Way, it is “Engineer complex machines from a limitless library of parts.” Having a strong and clear central idea is a forcing function on choosing the right tasks to work on.

6. Don’t fall in love with shiny technologies

You don’t have to implement every new technology you see in a GDC talk, Reddit, or X. Some could be useful but you must ask yourself whether they are going to solve a rather large problem for you before you get too excited and jump into implementation. I wasted way too much time on cool procedural generation techniques that never made it into the game.

7. Back up your work. In two different places!

I personally have my work folder on Dropbox and also commit to GitHub. Too many horror stories of people losing their codebase. Don’t be that person.

8. Don’t obsess over task management tools

I used Notion, paper, Miro, Jira - always looking for better ways to manage my work. Then I realized Tynan Sylvester and his team manage the tasks for RimWorld in a … long Google Doc. Use whatever works for you.

9. Use Steam for your playtest

Don’t overthink it. When you are ready to playtest - use the Steam playtest feature. It smoothens the experience so much. The Maker Way is in Open Playtest now and I never spent more than 10 minutes setting it up.

10. Collect data early

Seeing cumulative gameplay data really helped me improve the flow of the game, especially the early-game experience. I created my own tool to avoid Unity Analytics and it is serving me extremely well. I have full control of the data I collect so I can make sure I’m abiding by privacy rules while collecting only the data I care about.

11. Watch people play the game

Cumulative data is great but seeing someone bang their head on the keyboard in frustration will instill in you a strong drive to fix issues. It also surfaces “silent” bugs that don’t show as exceptions or errors in the logs.

12. Understand who your players are

The ability to put yourself in your players’ shoes is extremely useful. What other games are players in your target audience playing? What are their base level expectations from a game like yours? How do they discover games like yours? Talk to as many players as you possibly can.

13. Gameplay Gameplay Gameplay

When all is said and done, nothing beats a great game. Players will put up with a LOT if a game gives them a gaming experience they didn’t have before. The graphics of Schedule I look somewhat vanilla. Who cares?

14. Talk to other gamedevs

People in the trenches have the best advice. You can learn a lot from their success and their mistakes. I was fortunate to talk or exchange messages with amazing devs like Tobi Schnackenberg, Tim Soret, Jussi Kemppainen, Leo Saalfrank, Jonathan Blow, Tomas Sala and others. I learned so much from them.

15. Understand Steam’s algorithm

No one really knows how the Steam algorithm works but there are indications as to what makes it prefer promotion of one game over another (for example: median gameplay time is probably important). You can then test your game against those metrics to increase your chances of algo-love.

16. Be creatively scrappy

I remember listening to a talk by Daniel Mullins who created Inscryption. He mentioned that he got a bunch of 3D models by buying them cheaply (or even getting them free on some 3D platforms) and then using a shader he created to give them all a similar look and feel. That really sped up his pipeline.

17. Learn all the time

Listen to podcasts about gamedev in your spare time. It will expand your thinking about what is possible and you’ll learn about mistakes other devs made. Thomas Brush and Jonas Tyroller’s podcasts are a great place to start.

Here’s a great podcast episode on Jonas’ channel:

18. Fix bugs quickly

If you see a bug in a build or the editor and it’ll take less than 2 minutes to fix, fix it. That’s more effective than noting it down and returning to it later. If it takes longer, put it on a list and try to squash it before you release the next version. Don’t let those bugs linger and pile.

19. Get comfortable performing in an empty bar

Ed Sheeran tells this story about performing in small bars with no audience before he hit it big. It sure will feel this way when you have days with 0 wishlist additions, or have 7 people on your Discord channel. Don’t let that discourage you. Stay locked in.

20. Beware of marketing advice

There is a LOT of gamedev marketing advice out there. You should listen to it but also be very careful. Many of those sharing the advice have never actually successfully marketed a game themselves. When you listen to succesful devs sharing their stories, you realize there are many ways for games to gain traction.

21. Respect streamers’ time

Streamers get hundreds of emails from developers requesting them to stream games. If you find a streamer whose channel fits your game, be respectful and invest the time to write a compelling email explaining why your game matters and is relevant to their channel. Don’t just send a templated email. It shows and will reduce your chances for a response (and those are low to begin with).

22. Think in systems

Games are nothing but a group of systems working in tandem. This is something most game devs understand or know upfront but being smart about establishing system boundaries can really accelerate development. The best games have few systems that work extremely well in unison. An interesting exercise for aspiring game devs is to take a game like Minecraft or Factorio and list the systems it has (mining, crafting, health, etc.)

23. Keep an eye on the market

Don’t just chase trends but be aware of where the market is gravitating to, so you can at least properly assess the size of the player pool relevant to your game.

24. Don’t be afraid to throw code away

You have one goal and that’s to make an incredible game. Sometimes this means you have to throw work away, as painful as it can be. John Carmack was great at not being attached to his old code according to Tim Sweeney’s interview with Lex Fridman. He only cared about getting to the best possible solution.

25. Make your core loop tight

The core loop is the moment-to-moment loop in your game. It is the main engine of fun in the game. All other game loops should support the core loop and if they don’t, they are probably bloat. For a game like Minecraft, the core loop is: Mine Resources, Build, Survive. The secondary loops support this core loop - i.e, crafting weapons to assist with survival.

26. Automate or at least have a quick process for your builds

I have not gone fully automated here but at the moment it takes me around 10 minutes to build a version and put it on Steam. Once you start creating player facing versions, you want to have a quick process to push new versions out.

27. Use Assembly Definitions

Assembly Definitions are a bit awkward to grasp for some, especially if you’ve never dealt with code libraries (assemblies) before. Once you understand how they work, they really help structure your code and dramatically reduce domain reload times in Unity.

28. Do not build your own engine

Well… unless you are John Carmack or Jonathan Blow. To be fair, a good amount of other indie devs like Walt Destler who built Cosmoteer also created their own engine but the vast majority of successful indies use an existing engine.

29. Debug telemetry is crucial

You will test your game a lot. Aside from creating a dev console for helpful cheats and shortcuts (more on that later), you will want to have an easy way to add telemetry on screen. I created a tool for The Maker Way called DebugLogger that I can call from anywhere to print values to the screen or draw gizmos at will. Things like - DebugLogger.Log(machineSpeed) or DebugLogger.DrawSphere(_enemyEntity.transform.position).

30. Create a dev console early

A dev console with some cheat codes can tremendously help you with debugging. Shortcuts to advance to a certain point, load a certain level, give yourself unlimited ammo etc. Make it modular and keep adding to it as you go.

31. Separate general systems from specific game systems

If you intend to keep making games, treating systems that you build and are generic as external packages will help you separate the specific game logic from tools you can re-use later. Create a folder called GameUtils or (mine is called BraveUtilities). Make sure the folder doesn’t have dependencies (using assembly definitions) and keep adding tools on the go.

32. Game feel through action feedback

Humans thrive on feedback. Good game feel makes the game alive and provides feedback for every player interaction. It creates a sense of agency and action.

33. Marketing is very important but great games succeed in the long run

I used to obsess over my Steam page. Yes, you need to have a good Steam page that tells the story of your game. You also need to have a great trailer and a good press kit etc. etc. I’m convinced though that if your game is truly great, the word will spread.

34. Plant localization hooks early

If you plan to localize your game, implement the localization logic early. No need to actually work on translations yet but at least make sure you don’t have to go back and change the logic of all strings in the code and the editor. It’ll be really painful later.

35. Collect numerical feedback

Get a sense of how reviews would look like when you release the game by asking players to give you a rating. Subnautica implemented a simple 1-4 rating that really helped them get a glance at player satisfaction (watch Subnautica’s GDC talks).

36. Teach yourself the basics of performance

While it’s not useful to optimize the game’s performance too early, understanding the core concepts of performance will help in making choices as you develop and just in general will make you more aware of the cost of choices you make. Update loops, vertex counts etc. (Ben Cloward on Youtube has a fantastic series about it).

37. Try to avoid dead dev time

If your computer is busy doing some heavy processing in Unity (like light baking), you can’t work on the game. I decided to opt out of baked lighting to avoid the lengthy light baking process (and realtime lighting is also the better choice for The Maker Way).

38. Make building the game trivial

If structured well your game should build fast. If it doesn’t, try to run automated build processes on a separate computer if you have one, so you can keep developing the game.

39. Watch documentaries to get inspired

I personally LOVE watching documentaries about game devs. The Minecraft one available on YouTube or the Dwarf Fortress one made by NoClip are great examples of inspiring stories about devs committed to their craft.

40. Make it easy for players to report bugs

Players should be able to report a bug by pressing one button from inside the game. While you can catch some exceptions, user feedback on bugs will surface “silent” issues.

41. Scriptable Objects are your friend

This is Unity specific. Inspired by Odd Tales and several Unity talks, I started relying more and more on scriptable objects. They are powerful data and logic containers that are very useful for a wide variety of use cases (inventory systems, game wide events, sophisticated enum replacements and more).

42. Nobody reads UI text

Keep tutorial texts, objectives etc. to a minimum. From my experience going nuts while watching players play The Maker Way and ingore all text in front of them, the more text there is, the less likely players are to read it.

43. Please avoid dark patterns

The world of gaming is amazing. If you are reading this, I suspect you are not developing games to addict people to a game loop and extract as much money from them through micro transactions. Don’t let those dark patterns creep in.

44. Thicken your skin

Players will have feedback and sometimes this feedback will feel brutal. The way I taught myself to deal with it is to remind myself of the following - this player cared enough about the game to sent me their feedback and they are trying to tell me something!

45. Create a press kit

Even if it is a basic kit in a public Google Doc, or a public page on Notion, having an organized press kit is very useful when you interact with streamers or journalists. It also helps make sure that they are using relevant content and visuals from your game.

Link: A good Notion press kit template by PiratePR

46. Reduce dependencies

This one might be another controversial one. My goal from the start was to minimize the amount of external packages I use. There are some amazing assets on Unity’s (and other) asset stores but you have to remember that each one of those has a learning curve, requires integration and maintenance, and might be overkill. I mainly use MicroVerse by Jason Booth for the terrain and very few other assets.

47. Use version control, even if you work by yourself

Group tasks in versions and use version control to commit your work to a repository. This helps with rollbacks in case you mess up a version, allows you to work on experimental features on separate branches and is another way to back up your work.

If you have feedback or questions, please find me on the Discord server and DM me. Happy to answer anything.

You can playtest The Maker Way now

Join the open playtest on Steam (click request access):

The Maker Way on Steam

Join our Discord to share feedback, bugs, and ideas:

The Maker Way Discord Server

After a successful closed playtest and great feedback from our amazing growing community, it’s time to put The Maker Way in more hands and shape what comes next.

Game Mechanics

Most core mechanics are already in. This playtest will let us see how they hold up before we expand them and add more content.

What’s in now:

• Machine Design - Use a library of parts to build rovers, drones, and more.
• Machine Operation - 3D-print the machines you designed and take them into an open world to complete tasks.
• Resource & Energy - Mine resources and produce energy to print more machines and keep them powered.
• Base Building - Build bases to store resources, extend remote-control range with antennas, and run research on servers.
• Part Discovery & Research - Research to add parts to your tech tree, and scan parts in the open world to unlock new specs.
• Other Mechanics
  • Remote-Control Range — Stay close or extend coverage by building base antennas.
  • Combat — Use weapon parts to fight the three enemies currently on the scene guarding the government base.

How to Join

Join the open playtest on Steam (click request access):

The Maker Way on Steam

Join our Discord to share feedback, bugs, and ideas:

The Maker Way Discord Server

Nailing the game’s design pillars provides incredible focus. Defining a core set of principles allows me to filter through hundreds of possible tasks and ideas I collected over time.

After searching for the core game design elements for a while, it’s now clear to me that the magic of the game lies in creating powerful machines to overcome adversity in an immersive, hostile world.

In a list form, the game pillars are:

1. The Exhilaration of Making – the elation from operating machines and base-building parts that you designed yourself
2. Deep, Immersive World – seeing your creations interact with a living, reactive world
3. Overcoming Adversity – persevering in your fight against the massive odds stacked against you

In this post, I’ll discuss the current progress in creating an immersive world.

Inspiration and Focus

As a mostly solo dev, it’s comforting to know that some of the most deeply simulated worlds were created by small teams. Dwarf Fortress is the gold standard, with a simulation that spans from geological processes to the emotional states of creatures. It’s also been in development for 19 years.

Considering the other pillars of the game, I decided to focus on elements that interact with the act of creating machines and bases. Specifically, for Early Access I settled on:

1. Foundation - the passage of time, day-night cycle, basic weather
2. Energy - generation and consumption of energy, particularly how it’s used by your machines and by enemy factions
3. Enemies - simulating sophisticated enemy activities

Foundation

A day-night cycle is common in many games and fairly basic. However, the passage of time becomes interesting if day and night have a meaningful impact on gameplay.

Currently, the day-night cycle affects electricity generation through solar panels. They don’t generate energy at night.

As for weather, in Early Access, the only impact will be from wind. You can use wind turbines to generate electricity from wind.

Some enemy robots operate only at night and use daytime to recharge.

Energy

To operate machines and bases, you’ll need energy.

Energy can be:

1. Converted - converting fuel to electricity
2. Generated - using solar panels or wind turbines (for electriticy generation)
3. Stored - energy must be stored, so you need storage capacity (tanks for fuel or batteries for power)

One early example of this is the research facilities you discover. Initially, they’re locked because their doors can’t operate without power. It’s up to the player to connect them to a power source.

I intend to add more energy types later — I’m looking at you, Nuclear Fission!

After placing a battery, if you wait a bit, it will have enough electricity to power the facility

Enemies

Overcoming adversity takes several forms in the game. One is managing scarce resources needed for printing machines and base parts. Another is using your machines to overcome obstacles and access special areas.

Important areas in the game are defended by enemy entities. There are two major enemy factions. One of them, DTHP (Department of Technology Harm Prevention), is a government agency established to stop technological progress.

They both use robots, rovers, drones, and radars to prevent you from advancing tech. For enemies to feel believable, they need to follow the same simulation rules as your machines. That means even in Early Access, enemies will need to recharge at charging stations.

This creates a pretty meaningful overhead in the development process. I suspect it’ll pay off, because it also creates interesting gameplay opportunities — like cutting off the power supply to enemy charging stations.

Experiencing the Simulation

Some parts of the simulation are immediately visible, like time of day. Others, like wind, are invisible.

To give players a sense of wind strength, vegetation reacts dynamically to wind changes. Going a step further, wind volume increases or decreases based on strength. I know most players won’t notice — but I believe these small details matter.

The Maker Way is a long-term project. It might take 19 years to reach the simulation depth of Dwarf Fortress. But even these early simulation elements already make a huge difference in gameplay.

Thanks for reading!

If you’re interested in participating in the closed playtest, please join our Discord server.

A feature or a bug?

The feedback from playtesting so far has been amazing. It is hard to describe the joy of seeing players interact with, and enjoy, a piece of work you are pouring your heart into. It’s truly addictive.

While I’m collecting data points on player interactions, machine builds, exceptions etc., and learning a lot from the aggregate data, nothing beats the live playtesting sessions and videos that players send my way with live commentary. I already uploaded 5 new builds with many bug fixes and improvements. The last build (b15) was almost two weeks in the making and fixed many lingering issues.

My plan is to upload to Steam a new build at least once a week going forward. Many of the updates will revolve around bug fixing, and also a gradual increase in the amount of content in the scene (both parts and points of interest). Even with the initial content, several of the playtesters chose to play multiple sessions, clocking almost 10 hours in the game, which is just mind-blowing.

The most exciting moment in every playtest session is seeing the players figuring out how to build a machine, and then seeing their joy in operating it. It’s a magical moment in the game, and throughout the playtesting period, one of my goals is to make this initial experience the most enjoyable that I can make.

Back to coding now!

At some point I really need to pen down a blog post about the history of the game. There are some really amusing videos from very early builds :)

In June last year, I posted an early alpha version to Itch.IO. Some people played it and gave me good feedback, but I realized something important - they were not playing the game that I wanted to make, they were playing the game that I was capable of producing at that point.

I really value care and excellence being put into products and I just hated that I put out something that I wasn’t proud of because I felt pressure to get some playtesters.

So I took the time and went back to the lab, or to be accurate more of a small home office.

Been building and testing and building more and testing more for the last 18 months. This goes against every advice from some incredible game developers such as Jonas Tyroller (really recommend his Youtube channel if you are into gamedev) and others. But I took comfort in knowing that at least one game dev took a similar approach - Eric Barone, who made Stardew Valley:

Traditionally, video games are playtested extensively—dozens, if not hundreds, of people kicking the tires, looking for bugs and issues. But even more than that, games are a form of art built on complex systems and code. Playtesters are often asked, Is this game even fun to play?

Remarkably, Eric was the only person to play Stardew Valley until the very last stages.

Eric Barone GQ Profile

And today, 18 months later, I finally got a decent playtest version up and running on Steam. I also started giving out keys to play testers.

I’m still very far from the vision and aspiration I have for the game but it is a good point to iterate from.

From here, the plan is to have regular updates while gradually expanding the approved playtesters pool until the game is ready for a full on demo, and later, Early Access.

While I did ran several small playtesting sesssions, this is going to be the first playtest that is open to the community.

I still intend to have only a couple dozen playtests this round but expect to grow the list over the next several months.

Please head over to the playtest page to sign up and I’ll follow up personally.

This version has massive changes compared to the last version:

1. Overhauled environment with deeper simulation - improved global illumination, vegetation, ambient sounds
2. Improved machine design editor - easier to use machine editor with shortcuts and new additional parts
3. Introduction of a player character (the last playtest version was machines only!) - probably the biggest change since the last version. It makes the game so much more dynamic because the player can interact with the machines they build
4. Resource collection and management - this was planned for quite a while but the game includes 6 key resources for you to collect. You need them to build new machines
5. Basic base building - allowing you to build chargers and fuel stations for your machines across the map

Looking forward to hearing your thoughts!

This game is about believing in the human capacity to master resources and build great things out of nothing. It’s about ignoring cynics and doomsayers, and believing in the human spirit and our ability to make a better future. It’s about understanding that the prerequisite to progress is liberty and what happens when liberty is being compromised.

We can find one of the most beautiful stories in facing doubters in the Wright brothers’ success in the face of harsh critics.

On October 9th, 1903, the New York Times published an article predicting that it would take between 1 million to 10 million years to achieve human flight.

Exactly 2 months and 8 days later, on December 17, 1903, the Wright Brothers took flight for the first time.

As a dad, I want my children to grow up in a world where we believe in our ability to invent, create, and make a better future for ourselves. I started thinking about what type of game could inspire players to think that way. After a few weeks of brainstorming with just pen and paper, I came up with an idea: a sandbox game about building and crafting, where players can create machines and robots.

But the game’s setting was also important. Originally the setting was in space, and the missions a bit mundane. Then, I realized that the best setting for the game is right here on Earth. It’s about facing real challenges and using your problem-solving skills and hard work to make this world a better place.

It’s always day 1 on this journey and I’m excited about the work on the game moving forward. The Alpha version is several months away, and I’m looking forward to getting the community’s feedback!