After the release of Take Notes, the Stoneware team took some time to reflect on the development process. Like any project, we faced challenges, made mistakes, and learned valuable lessons along the way. In this article, I’ll share the insights we gained from this experience—what we could have done better, what went well, what didn’t, and why we made the choices we did. These lessons are something we’ll carry forward into our next project, and hopefully, they’ll save you some time and help you avoid the same pitfalls.
Good Choices
Give Each Other Feedback
From our experience, we know that giving constant feedback is extremely valuable. By that, I mean you should always discuss your work with your teammates. We talked about almost every single 3D model we created—even something as simple as a broom or a wall. And surprisingly, the walls turned out to be a more complex topic than you might think. (You can check out this article for more: Textures and Decals.)
This kind of communication helps prevent situations where someone spends hours working on a 3D model, only to realize later that it doesn’t fit in the game—whether due to design inconsistencies, technical limitations, or even lore conflicts. Catching mistakes early saves time and effort.
Besides, discussing design decisions can be fun! Imagine two people seriously debating the perfect size for a trash can. It might seem trivial, but sometimes, even the smallest details can have an impact on gameplay. Of course, it’s important to strike a balance, but open discussions like these can lead to valuable insights.
Steam Next Fest Is a Must-Have for Indie Games
If you’re not familiar with it, Steam Next Fest is an event where developers can release a demo of their game and gain significant exposure during the festival.
Before Next Fest, we had around 100 wishlists. After the event, that number jumped to 1,500. That’s a huge boost for a team that no one had heard of! On top of that, we received valuable feedback from players.
If you’re planning to sell your game, make sure to participate in the next Steam Next Fest—it’s an opportunity you don’t want to miss. And this isn’t even an advertisement—it’s seriously that good, at least in our experience.
One Person in Charge Is a Good Solution
This is something I’ve learned not only from Take Notes but from my entire experience in game development: having one person in charge is better than making decisions by committee.
In almost every team project I’ve worked on, we followed the idea that everyone’s input was equal. This makes sense for hobbyist teams—since no one is getting paid, having a „boss” might feel unfair. But in reality, if everyone has an equal say in the game’s design, things can get messy. Trying to merge everyone’s ideas into one can sometimes result in something fun, but more often than not, it leads to a mix of disconnected elements with no clear direction.
A game benefits from having a leader—not just someone giving orders, but someone who understands the bigger picture and ensures all elements fit together. The role of this person isn’t to control everything but to make sure the vision stays consistent. They need to be able to say no to ideas that don’t fit, while still valuing the team’s input.
Of course, for this to work, the person in charge must deeply understand the entire game—every aspect of it. Without that, they can’t effectively guide the project, and things can still fall apart.
A Lot of Playtesting
Many aspiring developers don’t want to show their work until it’s finished, but believe me—playtesting is something every game needs.
So how do you do it? Simple. You give a tester your game, say “play,” and then you watch. And most importantly—you do not say a single thing.
Of course, you should explain this approach to the tester beforehand.
This might feel a bit harsh—why not help them if you already know the answer? Because if you do, you’ll never know whether the problem is actually solvable or if it genuinely needs developer attention.
This method is especially useful for things like: “Find a path to the target” or “Solve logic puzzle” But it’s generally a very useful approach for testing the feeling of the game.
For example, imagine your player needs to find a way inside a building. A tester might initially say, “There are no open doors or windows—how do I get in?” But if you give them a little more time, they might discover the hole in the roof that you placed. However, if nobody finds it, then you know it’s a problem—you may need to rethink the idea of that hole being the main entrance.
By silently observing testers, you don’t just rely on their direct feedback—you see the things they struggle with, even if they never mention them. In short, this approach gives you tons of valuable insight into player behavior.
So do as much playtesting as you can—it’s one of the most powerful tools you have.
Good Communication
When working in a team on a game, one of the most important things is communication. That means having clear channels with specific roles.
We used a SCRUM-like approach to manage our tasks. Essentially, we had a single place to track them—a virtual board in GitHub Projects. Each task had a clear description, making it easy to understand what needed to be done.
For general communication, we used Discord. We created specific channels for specific topics, so music discussions didn’t blend with 3D model talk and so on. This kept everything organized and easy to follow.
Another important aspect of good communication was making sure everyone knew when someone would be unavailable. If someone knew they wouldn’t be around for a certain time, they’d let the team know in advance. This way, everyone could adjust their plans accordingly.
In other words, just talk with your teammates—if there’s a problem, solve it together. Don’t force anything on others, and always stay open to collaboration.
Could Be Better
Make Concepts
During playtesting with actual testers, we encountered numerous problems that required changes. Sometimes, this meant redesigning an entire room. That’s when the real challenge began. We’d discuss how to improve things, and everyone had an idea—most of them were really good—but which one should we choose?
Naturally, we ended up debating which idea was the best and why others didn’t work. Everyone wanted their idea to be implemented, and honestly, these talks could drag on for hours, which was not healthy. The problem here is that when you face a situation like this, you’re just losing time. In game development, what’s important is to take action. It’s very hard to say if something is going to work—what looks good on paper may not always work in practice.
Sometimes, this doesn’t even require testers. Developer can just wake up one day with a new idea in mind, but is it worth redesigning something to implement it? Constantly jumping between ideas can cause unnecessary delays, and it’s essential to evaluate whether these ideas are worth pursuing or if it’s better to stick to the current design.
So, for our next project, we’ll implement a solution:
“If you have a proposal for changing existing features, rooms, levels, or assets in general, create a concept first.”
I’m using room design as an example, but this applies to any asset. Always make a concept—whether it’s on paper or in something simple like MS Paint—just visualize what you have in mind and share it with the rest of the team. Without a visual reference, people will imagine things differently based solely on words. People simply don’t always understand your ideas as clearly as you might think. When you have a visual reference, it’s easier to decide what to implement and move forward quickly.
Don’t Worry About Realism So Much
By this, I mean your story doesn’t need to explain every single aspect of why things are the way they are. The puzzles don’t need to function exactly like they would in real life—they just need to appear believable enough that the audience doesn’t question them.
We often found ourselves spending long hours discussing how the story wasn’t perfect, and whether the character could have done a thousand different things instead of what we chose.
Side note: Yes, we were supposed to have a more developed story in the game, but for reasons I explain in a different section, we ended up not having one.
So, don’t stress too much about perfection. The story just needs to make sense overall, and you don’t need to explain everything. It just needs to feel logical. And when it comes to assets, if people don’t immediately notice inconsistencies, then it’s probably good enough.
The World Could Be More Alive
Take Notes is a very static game. You solve one puzzle, a door opens; you solve another, a safe opens. But other than that, there’s no real movement in the world. We don’t have things like spinning fans, flickering lights, or dust falling from the ceiling.
One of the twelve rules of Disney’s animation is “secondary action,” which in simple terms means that a second, less important action on screen adds life to the scene. For example, if the main character in an animation is cooking dinner, a little vapor might rise from the pan.
For our game, it could be something like a spinning fan in the ventilation system or a computer screen flickering.
Why add these small details? Because a more dynamic world isn’t just about eye candy—it makes the environment feel alive, which helps players form a deeper emotional connection with it. When the world reacts to the player’s actions, it also makes the experience feel more immersive and rewarding.
Of course, secondary action can’t just be added for the sake of it. It’s easy to go overboard with these details, which could become a distraction if not implemented properly. Balance is key. Adding small details like a flickering light or a soft hum from a machine should serve the atmosphere without taking focus away from the gameplay itself.
So, secondary action will definitely be something we aim to include in our next project. However, it’s important to remember that these additions take time to create. So, sometimes it may be better to focus on the more crucial elements of the game first. For Take Notes, the static nature isn’t necessarily a bad thing, as it allows players to focus on the puzzles without distractions. But, it can feel a bit boring if the world is too static.
More Small Details
This is similar to the previous point, but it’s about even more small details that make the world feel alive. Secondary animations are one thing, but the world also becomes more immersive when you add elements like the sound of a working computer, electrical sparks when interacting with electric objects, or the ability to see the pixels of a screen when you’re very close, or even a spiderweb in the corner of a room. All of these details can help contribute to a livelier environment.
In Take Notes, we didn’t include any environmental sounds, which leaves the world feeling quite dead—though that was part of the atmosphere we were trying to create. Still, even something as simple as a flickering light on a security camera could have added some subtle life to the environment.
For our next project, we will definitely be adding more of these little details. While they may seem small, they go a long way in making the world feel more dynamic and immersive.
Community Building from the Start
The sooner you start showing your game, the better. Game development is a highly competitive field, and when you release a game, you’ll be fighting for players’ attention against thousands of other games. If you don’t have a community by launch day, it will be difficult to build one afterward. Without a community, the algorithms won’t recommend your game to new players.
So, show your progress while developing the game to as many people as possible. Post on social media, share your development journey, and engage with potential players. This way, you’ll have at least a small community built up by the time your game launches.
And don’t worry about someone stealing your idea. In this industry, everyone has a tendency to tweak and change things. You’ll create your own unique approach, and even if someone says they’re going to do the same thing, they’ll end up taking a different path because they’ll adapt it to their own style.
Make your systems modular
If you want to save time during production, aim to make your systems modular. For example, if you have a button in your game, don’t create a new one for every puzzle. Reuse what you can. You can change its appearance just by changing the mesh, but keep the underlying logic consistent. This approach will save you time and make your development process smoother in the long run.
The same principle applies to other assets. For example, if you have walls in your game, consider making them modular. You can create segments that are 4 meters long and build rooms using those. This is how we approached it in Take Notes. But don’t forget to create variants, such as 2-meter and 1-meter sections. There’s no point in forcing every room to conform to a size that’s only divisible by 4.
However, keep in mind that not everything can or should be made modular. Sometimes, you’ll need a custom script for a very specific function, and that’s perfectly fine. Ultimately, everything depends on your specific use case. It’s about finding a balance. Personally, if I know I’ll be using something in multiple places, I’ll try to make it work for multiple situations—even if the purpose is slightly different in each case.
Design Your Game with Marketing in Mind
One thing we learned—though it was a bit too late in our case—is that it might be a good idea to design your game with marketing in mind, rather than designing marketing for the game afterward. In other words, think about how you can present key aspects of your game in a way that grabs attention.
For example, when designing characters, consider how they will look in a Steam thumbnail. A character that stands out visually can make a big difference when people are scrolling through the store. Similarly, think about gameplay mechanics that are easy to showcase in a trailer. If you design with marketing in mind from the start, you’ll make it easier to create marketing materials that grab attention and engage potential players.
Mistakes
Design UI for Controllers
If you know your game will support controllers, you need to design the UI with controllers in mind from the start. We didn’t, and that caused us to lose time redesigning the UI after we added controller support. In practice, this means the navigation should be straightforward. You shouldn’t have to move all the way to the second edge of the screen to confirm something. Generally, just remember that controllers don’t have a mouse cursor, and you should be good.
Complex systems should be designed as soon as possible.
I’m talking about things like the save system or controller support.
We made the mistake of leaving these things for later, and that caused us to rewrite a lot of code and make changes to the game design. We initially assumed that these systems were secondary—after all, you need a game to play before you can save it, so the save system should come last, right?
Not necessarily. These are big systems that affect everything, so if you leave them for the end, you’ll have to adjust everything else to accommodate them, effectively doubling your work. So, when you design something and you know something else will affect it, at least keep it in mind and adjust for it now, not later. The best-case scenario is to do those big systems ASAP, but of course, it’s not always possible.
If you’re targeting a niche, you need testers from that niche.
It may sound obvious, but we learned it the hard way. We made the mistake of taking the easiest route: we needed testers, so we gave the game to our friends. While their feedback was useful, it didn’t always give us the full picture, and in some cases, it was even misleading.
For example:
Take Notes is a logic game. If I gave it to a player who primarily plays shooters, they might enjoy it, but the time they take to solve the puzzles will likely be much longer than the average player from the niche we’re targeting—simply because they have less experience with puzzles.
We initially thought the game would take 3-4 hours to complete, but in reality, players who actually buy it finish in 2-3 hours. That’s the kind of misleading feedback I’m talking about.
Another example:
“One of the puzzles is too hard; I would have never figured it out.” Meanwhile, an escape room fan would solve it effortlessly.
So, moving forward, we’ll make sure to have more testers from the group of people who would actually buy the game.
If you want something in the game, plan it from the start
We were supposed to have a story in our game, but the mistake we made was leaving it for the end. „Let’s focus on the puzzles first, then we’ll think about the story.” That didn’t work out. By the time we wanted to add it, the game was a complete product, and trying to introduce a story would have forced us to remake half of the game to make it fit.
So, we decided to drop the story altogether.
Something as significant as a story needs to be developed from the start. Remember, every aspect of the game should be developed simultaneously; otherwise, you might end up in a situation like ours. The game could have really benefitted from a story, but at that point, it was simply not feasible to implement.
Cutting-Edge Technology Isn’t Always the Best Choice
Originally, we used Lumen for our game, but we realized that we didn’t really need it because only a few things were moving. That’s when we switched to baked lighting, which gave us a 1.5-2x boost in FPS—a great improvement. More FPS means more players with older hardware can enjoy the game.
But wait a second—didn’t Lumen look better? Actually, no. After a week of tweaking, I managed to achieve nearly identical results with baked lighting. Some areas were slightly darker or lighter, but overall, it didn’t look worse. In fact, Lumen had a tendency to cause some weird flickering in certain places, which didn’t happen with baked lighting. Some might even argue that baked lighting looks better than Lumen.
Of course, this is all true for a static game. The situation would be completely different if you’re working on something much more dynamic.
The lesson here is that not every cutting-edge technology will be the best choice for your specific use case.
Final Thoughts
In the end, making a game is a learning experience. You’re bound to make mistakes along the way, but each one teaches you something valuable. Whether it’s about planning ahead, managing your resources, or just learning from feedback, it all adds up. Every project is different, but the lessons stick with you. Hopefully, this gives you some insight and saves you a bit of time when working on your own game.
And if you haven’t played it yet, don’t forget to check out our game: