47 Days to Demo. 47 Lessons Learned.
In 47 days I plan to release The Maker Way’s demo on Steam, and I’ve been reflecting on the feedback from the currently running open playtest and the journey so far.
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):
Join our Discord to share feedback, bugs, and ideas: