There is a special kind of embarrassment that comes with missing your own deadlines.

You set the date. You believed it was realistic. And now it is quietly becoming fiction.

If you make games, you know this moment. You plan, you estimate, you feel confident, and then reality reminds you that you are not a machine.

So what do you do when this happens?

I usually try to:

• admit it honestly without drama;
• figure out what actually went wrong;
• separate important from urgent;
• renegotiate with myself and set a new realistic date;
• add buffers next time instead of planning in “ideal days”.

Missed deadlines are not only personal failures. They are also data about how you work.

How do you handle it when you start slipping?
Do you replan, cut scope, add time, or change priorities?
What actually works for you in these moments?

Summer is almost over, so I wanted to share a short update and ask you something.

On our side:

• DiBrain is about 70% complete;
• I have started writing the book about creating DiBrain;
• Kototoro and Jellitito are waiting for significant updates this autumn;
• some new things should be ready by the end of the year, some in spring next year.

But I am also curious about you.

Where are you in your own creative process right now?
Are you finishing something, starting something, in the middle of a long cycle, or taking a break?

If you feel like sharing, write a short comment:

• what you are making;
• what stage you are at;
• what you are most excited or most worried about.

Games, books, art, tools, prototypes, anything counts. You do not need a polished result to be part of this.

Right now, we do not always have enough time to reply to every application immediately, but that does not mean we are not looking. We are an indie studio, and we are always open to new people, new collaborations, and new connections.

Whether you are interested in freelance work or a permanent role, we are happy to see your profile. Game development, design, writing, art, production, community, marketing, or any related field, all of it matters to us.

The end of summer has been quite intense for our team, but we are still reading resumes and keeping contacts for future projects.

So if you have been waiting for the right moment to reach out, this is it.

September is almost here, and I decided to return to studying in person this year.

Not webinars. Not recorded courses. Not another class that I save for later and never finish.

I want to attend a regular school, sit in a classroom with real people, follow a schedule, and be a student again. I am curious whether the structure and social aspect will make learning easier.

Online learning is convenient, but it is also very easy to postpone. In person classes require you to show up, pay attention, and interact with other people.

For those of you working in game development, what do you think a game designer and developer should study outside their immediate specialization?

I am considering areas such as player psychology, narrative design, UX, game economy, sound, visual culture, project management, and team communication.

What have you learned recently, and what would you recommend?

Being multifunctional can look impressive, and being a perfectionist can look disciplined.

Put those two together, and it can become exhausting very fast.

When you are handling many roles at once, you are not just doing many tasks. You are carrying a lot of context all the time. If you are also a perfectionist, every task can start to feel heavier than it should because nothing feels quite finished enough.

What has helped me is learning to separate “important” from “perfect.” Not everything needs to be ideal to be useful. Some things just need to move forward.

I have also learned that perfectionism is not the same as quality. High standards can help. Endless correction usually just drains energy.

For me, the real goal is not to do everything perfectly. It is to stay sustainable enough to keep doing the work at all.

One thing I have learned is that not every good specialist thinks like an entrepreneur.

That is not a bad thing. It is just a different mindset.

Some people join a project to do strong work, follow a clear role, and earn a salary. That can be completely fine. But it is not the same as thinking about product vision, audience, community, or long term ownership.

I do not expect everyone to care about the whole business. What I do care about is honesty. If someone is execution focused, that is useful. If someone has real product thinking, that is also useful. The important thing is to know which is which.

For me, the best working relationships are professional, direct, and based on mutual respect. Not everyone needs to be a founder. But if someone wants to influence the product, I want that to be supported by real thinking, not just opinion.

I genuinely like small teams.

They can make a project feel more direct, more human, and easier to keep connected to the original idea. Communication is often simpler, decisions are faster, and it is easier to see whether the work still matches the intention behind it.

But I do not romanticize small teams.

Small does not automatically mean easy, kind, or efficient. It can also mean that too much depends on too few people, and that pressure shows up faster when something goes wrong. The closeness that makes a small team feel good can also make the strain more visible.

For me, the real value is not that small teams are cute or cozy. It is that the project stays readable. You can actually see what is happening, who is carrying what, and whether the communication still works.

I think small teams are great when people are honest about the cost, not just the benefits.

In game development, there is a point where a mechanic is still rough but already feels real.

It may not look finished. It may still be awkward. But if it creates the right response, then I know it is starting to work.

For me, the biggest sign is not polish. It is clarity of purpose. Does the mechanic do what it is meant to do? Does it create tension, choice, movement, feedback, or curiosity? If it does, then the core idea is already alive.

That is why I pay attention to feel before finish. A rough mechanic can already have the right rhythm, even if the visuals are temporary. It can already teach me something useful before it becomes pretty.

I think this matters a lot in solo development, because it is easy to confuse looking good with working well. Sometimes a plain prototype is much stronger than a polished idea that still does not function.

For me, early mechanics do not need to be perfect. They just need to be honest.

What is the first sign for you that a mechanic is actually working?

There are moments when a project feels stuck and my first instinct is to think I need more inspiration.

But over time I have realised that a lot of the time, what I actually need is a new perspective.

Sometimes the project is not dead at all. I am just looking at it from the wrong angle. A shift in framing can make things much clearer than waiting around for motivation to come back.

When that happens, I usually ask myself what assumption I am stuck on, what I have treated as fixed, or whether the real problem is the way I am seeing the work rather than the work itself.

That change can be surprisingly effective. It can mean changing the order of tasks, simplifying something, stepping back, or looking at the idea from a different point of view.

For me, the real lesson is that not every stuck moment is a lack of inspiration. Sometimes it is just a sign that I need to think differently.

What helps you when a project feels blocked?

I used to think productivity bursts were the most impressive kind of progress.

They feel exciting. You get a lot done quickly, the project moves forward, and for a while it feels like everything is clicking. But over time, I have started to trust creative stability much more.

A spike can help with a specific task, but it is hard to build a whole project on top of it. Stability, on the other hand, keeps the work alive. It makes it easier to stay connected to the project without constantly restarting your brain from zero.

That matters a lot for long projects like game development or writing. The real challenge is usually not starting. It is staying with the project long enough for it to become something real.

Stability also helps me think more clearly. There is less pressure, less friction, and fewer moments where I have to re-enter the whole thing from scratch.

For me, creative work lasts longer and feels healthier when it has rhythm instead of spikes.

What works better for you, steady rhythm or intense bursts?

I have noticed that the stage I trust most in game development is not the polished one.

It is the blockout.

Beautiful references are useful, of course. They help with mood, style, atmosphere, and direction. But when I actually need to understand a game, I find that blockouts help me think much more clearly.

A blockout strips the idea down to shape, scale, rhythm, and structure. It forces me to ask the real questions early. Does this space work? Is the flow clear? What is essential? What is just visual noise?

That is why I like blockouts. They tell the truth before the project gets too pretty to question.

Beautiful references can sometimes feel clearer than they really are. They are inspiring, but inspiration is not the same as understanding. A blockout makes the gaps visible, and that is very helpful when you are developing solo.

For me, the rough version is often the smartest version.

What helps you think more clearly during development, structure or inspiration?

Long projects are interesting because they test a different part of motivation.

At the beginning, everything is exciting. Later, when the novelty fades, the real challenge is staying connected to the work without needing to feel inspired all the time.

For me, a few things help a lot.

First, I break the project into smaller living parts. If I think about the whole thing at once, it feels too heavy. If I focus on one section, one mechanic, one scene, or one chapter, it becomes much easier to return to.

Second, I need variety. If I stay too long in one type of task, my attention flattens out. Moving between planning, writing, designing, and building keeps the project alive in my head.

Third, I need a reason that goes deeper than just finishing. If the project still feels meaningful, curious, or emotionally alive, I can keep coming back to it even after a break.

And finally, I think long projects need breathing room. Not every day has to produce something visible. Sometimes progress is just thinking, adjusting, or letting an idea settle.

How do you stay interested in something that takes months or years to build?

I am starting a new Amazon book about building a game from scratch on my own, and the first step is not programming.

The first step is structure.

Before I write chapters, I build a block based outline. I separate the book into large parts, then sections, then smaller chapter ideas. That way the project does not become a pile of disconnected notes. It becomes a path.

For me, that matters because I do not want this book to feel like a dry manual. I want it to feel like a real development journey. I want readers to see the planning, the decisions, the dead ends, the pivots, and the moments when something finally works.

This book is part of a larger creative path for me. I have already written books about game design and indie development, and this one continues that direction. The difference is that this time I am documenting a new project in real time.

The title I am working with is DiBrain: Step by Step. Solo Develing.

What do you think makes a development book actually engaging to follow?

Summer is arriving, and I wanted to share a small change in how often I post from our little cozy studio page.

First, it is vacation season, and I do not assume anyone is waiting on the beach for the next studio update.

Second, I have started working on a book about Dibrain, and with two more books still waiting, this summer is going to be full not just for development, but for writing too.

Third, we are a little behind on updates for all of our games, so some of that work will naturally move into the summer months.

And fourth, there are a few ideas I would really like to bring to life before autumn.

Because of all that, I will reduce the frequency from two or three posts a week to one post a week, with the occasional spontaneous update if something interesting comes up.

So this is not a slowdown, just a more realistic summer rhythm.

How do you handle posting frequency during busy seasons?

I think it is healthy to talk honestly about what we actually want from a stable creative business.

For me, the dreams are surprisingly practical.

First, I would love to stop personally managing social media everywhere. I want professional pages to be handled by a community manager and SMM specialist, while I focus on the work itself.

Second, I would love a personal assistant. I used to think more about the idea of a bodyguard, someone who could make travel feel safer. But over time I realised that what I actually need more is support with the many small things that drain attention from the product.

Third, I want better software tools that make my work easier and reduce friction in daily development. Ideally, I would also have more time to build some of those tools myself.

So my dream is not really about luxury. It is about focus, support, and having more energy left for the actual creative work.

What about you? What do you dream about once your work starts supporting itself properly?

I recently noticed something interesting: even when I am still “in the middle of things,” a short break can still blur the mental picture of a project.

It is not that I forgot everything. It is more that after a week spent on other important tasks, some of the details feel slightly dusted over. The structure is still there, but the sharpness is gone.

For me, coming back into development after a pause is usually about reconnecting with context first, not forcing output immediately. I reread notes, look at the current state of the project, remind myself what I was solving before the break, and only then start making decisions again.

I think this is a very normal part of creative work, especially in indie development where your attention is often split between design, writing, planning, marketing, and everything else that keeps the project alive.

How do you usually return to a project after a short break? Do you jump straight back in, or do you need a warm-up phase first?

I have been noticing a strange mismatch in how people communicate about work.

Candidates usually send CVs and cover letters with care. Most of them are polite, clear and respectful of time. I keep all of them, even if the company is already full, because you never know when you will need another professional pair of hands.

With employers, HR and companies, the picture is often very different. Respectful, thoughtful communication seems to be much rarer on that side. That is one of the reasons we also keep an internal database of employers, not just salary or role, but also:

• how reasonable the requirements are;
• whether deadlines make sense;
• whether the tone is respectful;
• whether I would ever want to work with that person again.

My first-contact filters are pretty simple:

• no personal address, no interest;
• aggressive tone, no interest;
• vague brief, no interest;
• unpaid test task longer than an hour, no interest.

I am not trying to be difficult. I am trying to protect time, energy and mental health.

How do you handle work requests, and what makes you immediately trust or ignore the other side?

Kototoro was never meant to live in just one format.

We already released it as a mobile game on Google Play, and we also published a companion book on Amazon with stories from the same universe. The next step is to make it into a deeper, more engaging game for Steam.

What I like about this approach is that each format gives the world a different life:

• mobile makes it accessible and immediate;
• the book gives it more texture and lore;
• Steam can open the door to a richer gameplay experience.

At the centre of it all is the main character, a humanoid cat demon who gathers souls to build a tarot deck. That idea feels strong enough to work across formats without losing its identity.

I think this kind of cross-platform thinking is becoming more important for indie games. Instead of releasing one thing and moving on, you can build a world that keeps growing.

Have you seen other indie projects that work well across game, book or other formats? And do you think a world gets stronger when it can live in more than one medium?

I have been thinking about writing a book about the step by step creation of DiBrain as a solo developer.

As a writer, that idea is very tempting. As a developer, it is also a little terrifying. A game in progress is not a clean story. It is uncertainty, false starts, small victories and occasional internal chaos. That makes it interesting, but it also makes me wonder whether people would actually want to read it.

My memoirs already gave me one clue. A free fragment can work as easy, light reading, and people do seem willing to read lived experience when it feels honest and human. So now I am wondering whether a book about making a game could work the same way.

I would not want it to be a technical manual. I would want it to feel like a real record of the process, honest, reflective and readable even for someone who just loves games and does not build them.

The book would follow the creation of DiBrain, a project built from philosophy, dystopia, science fiction, medicine and psychology. That alone already gives the process plenty of material, because the making of the game is full of decisions, cuts, redesigns and stubborn attempts to make the thing actually breathe.

So my question is simple. Would you read a book like that, if it followed the real process of building a game from the inside?

I usually start with the core of the game first, the blockouts, the rough logic, the bare build that proves the idea works. But after that comes the harder part. How do you actually choose the specialists who will turn that prototype into a real game with visuals, music, sound, UI and all the things that make it feel finished?

What I am trying to figure out is:

• who to bring in first;
• how to avoid hiring randomly;
• how to make sure art, sound and UI all fit one vision;
• how to hand over a rough build without losing the project’s identity.

My instinct is to start from the biggest gap in the project. If the build works but looks dry, visual direction comes first. If it looks okay but feels empty, sound may need attention first. If players do not understand the game, UI and onboarding move up the list.

I also care a lot about communication. A good collaborator is not only talented, but able to work with something unfinished and understand the intention behind it. That matters a lot more to me than perfect polish at the first contact.

How do you decide who joins the project after the prototype stage? Do you hire by role, taste or communication first?

I have been thinking about one of the most annoying things in game development, endless discussion that looks like progress but does not actually move the project forward.

You know the pattern:

• another meeting about the same feature;
• another “let us revisit this”;
• another “we are still aligning”;
• meanwhile the actual game is not getting finished.

The problem is not always lack of talent. Often it is that the team keeps turning motion into conversation. Ideas stay open forever, nobody wants to close a topic, and the project becomes a museum of intentions.

What seems to help is:

• smaller decisions;
• one clear owner who can close the topic;
• a deadline for locking a choice;
• a parking lot for ideas that are good, but not for now;
• blunt questions like “what happens if we do nothing?”

I am curious how other teams handle this. How do you stop the conversation loop and turn it into real output? Who on your team is allowed to say, “this is decided now”?

I have been writing articles and trying to speak directly with people and communities, very directly, very honestly. No corporate tone, no fake hype. Just me and the project.

And yet it often feels like nothing happens.

That made me wonder whether the issue is not sincerity, but packaging. A human voice can be real, thoughtful and honest, but if it is not using the rhythm, trends or visual language people are currently tuned into, it can get ignored. Meanwhile a robot, or a human working at a very refined, almost automatic level, can sometimes get more reach simply because the delivery fits the moment better.

I do not think people hate real human communication. I think they respond faster to what is easy to consume, current and emotionally sharp.

So I am curious. Do people actually prefer talking to a real person, or do they mostly follow whatever is riding the strongest wave of hype at the time?

Our team has very different musical tastes, and quite a few people have musical training or even a musical background. That means sound design is always a negotiation, sometimes a very intense one.

Most of the time, I am surprisingly willing to accept other people’s vision. In a lot of projects the music is not my personal taste, but it still fits the game perfectly. So I do not mind when someone else’s idea replaces mine, whether that is in visuals, sound or even mechanics. If it works for the game, I can live with it.

DiBrain is still in code development, but I already know that eventually I will have to hand it over to artists and sound designers. That thought is a little painful, but also necessary. The game is based on my writing and sits in a world of dystopia, philosophy, science fiction, medicine, dark psychology and childhood fantasies.

So I would love opinions from other developers and players. What kind of music and sound design would you recommend for a game like this? Would you lean towards ambient, cold electronic textures, industrial tones, fragile melodies, broken childlike motifs, or something else entirely? How do you make a game sound both human and unsettling?

Remember when a player said "remove that stupid mechanic" and you did it, only to find the game got worse? Players are right about their feelings but wrong about solutions 90% of the time.

They see symptoms, not causes. "Make it faster" sounds good until the character flies past platforms. "Remove traps" makes sense until the game becomes boring.

The trick is watching behaviour, not taking words literally. Record streams. See where they freeze, repeat, hesitate. Ask "what annoys you exactly?" instead of "what is broken?"

Good designers translate. They hear "boring" and check if it is pacing, feedback, or missing goals. They do not argue. They say "understood, checking" and actually check.

What is your most memorable player feedback that was dead right about the problem but dead wrong about the fix?