Alex Itsios's Blog

Recall that game your team abandoned when it was almost done? You’re not alone. Many developers get caught in endless iteration cycles they can’t support. This mindset quietly kills projects, even when they’re properly scoped.

In this edition, you’ll learn:

What is iteration hell, and its top causesHow to assess whether a project is actually on trackA practical success criteria frameworkSteps I took for my team to avoid iteration hellThe root causes of iteration hell

A breakdown of the core factors that push teams into iteration hell

Iteration hell usually comes from two things: fear that the game isn’t “good enough” and a lack of clear success criteria. A friend of mine is currently facing this. His game was nearly complete, but low wishlist numbers made him think the art wasn’t good enough. I told him that the upgrade he was planning wasn’t enough to justify an art reset. Now, even after multiple art and small gameplay iterations, his wishlist numbers barely moved the needle. The reasons are debatable (personally, I think the genre played a bigger role), but he and his team put in extra work with no return. He’s now evaluating what went wrong again, considering going back to the drawing board to iterate on the game's narrative. Once a team enters this loop, it becomes impossible to stop, even when the game is already close to the finish line.

And this isn’t an isolated case. Just in 2025, I’ve been in a handful of teams facing the same iteration hell.

Define what success is to your team

This is where clear success criteria matter. Without them, it’s easy to lose direction, especially as an indie. A simple framework acts as a compass and keeps you from drifting into endless iterations. It won’t guarantee financial success, but it will stop you from sinking months into work that doesn’t move the project forward.

A practical framework for assessing project outcomes. Download Template.

For smaller projects, this Framework is so embedded in my mind that I rarely write it down anymore.

I faced the iteration dilemma with my recent release (Cook or Be Cooked). The game wasn’t gaining enough wishlists to justify its continuation, and I had to choose between iterating further, scrapping it, or cutting scope and shipping. Instead of canceling the project, I reduced about 75% of the planned content and released a one-hour version. You might think the reduced scope became a self-fulfilling prophecy when it comes to revenue, but the wishlist numbers had already made the outcome clear. I had barely reached 20% of the threshold, and pouring more money into it would have been a waste. It was a clear example of how defined criteria help you avoid endless iteration and make tough decisions before losing more time and resources.

Steps to avoid endless iteration cycles:

Define success criteria before production begins and stick with themLimit iteration cycles (e.g., max 2 passes)Lock your vision earlyCreate non-negotiable constraintsAssign a single person as the scope owner

Conclusion

Finishing a game (even a small one) will always move your game development path forward more than chasing a perfect one. Clear criteria keep you grounded and help you ship before you burn unnecessary time and resources. Successful game devs don’t win by polishing forever. They win by finishing, learning, and moving on to the next game adventure.

 As this year’s Gamescom was coming to an end, I couldn’t stop thinking about the state of the game industry, and game publishing in particular. I was looking for a publisher for one of my games. Thankfully, I met with some good ones, but more than half of the meetings were with companies presenting themselves as “publishers” while, in truth, they were Steam distributors or porting houses. It’s why I’m writing this post: to tell the good from the bad.

The Good

A good publisher is a real asset.

They invest in game development, marketing, QA, porting to consoles, and localization of your game. This not only makes a quality product but also exposes it to a wider audience. For example, Steam has more Chinese-speaking people than English-speaking ones. A good localization will double your potential audience.There is transparency around where the money is spent.They have clear acceptance criteria and vision. If your game doesn’t meet their expectations, they’ll contact you early on and inform you about their decision.They have released and marketed most of their games successfully. You have a general idea of what to expect from their marketing department.

The Bad

These publishers aren’t outright scams, but you’re better off without them.Their investment is low, yet they demand a 50-70% cut, similar to big publishers.The evaluation process drags on for months. One thing I noticed with these publishers is that they rarely reject you outright. Instead, they request repeated improvements and iterations over the course of 3 to 6 months. If the game you developed entirely with your own capital isn’t what they were hoping for, they’ll turn you down. No risk-taking for them.There’s a lack of clarity about how marketing, QA, and localization costs are estimated.A lot of the games they’ve published aren’t successful, which indicates little to no marketing effort.

The Ugly

This category usually involves “distributors” portraying themselves as publishers.Steam Distributors offer little value to the developer and do the bare minimum, such as sending press releases, release management (Steam page setup), etc., yet they take a significant cut of your game’s revenue for publishing it.Service providers or distributors are scouting for indie game developers through events (like Gamescom), or they reach out to you directly via email if they’ve seen your game somewhere.They usually earn money from the high volume of releases. If you check their Steam Publisher Page, you’ll realize they have multiple releases each month.In recent years, I’ve seen some porting houses starting to portray themselves as publishers. I want to point out here that honest and reputable porting houses are valuable partners to have, but a few present themselves as publishers, which is sketchy at best.

In an industry where the term “Game Publisher” can mean many things, you should look beyond the tag. If there’s one thing I learned from Gamescom this year, it’s that a fast “no” is way better than six months of polite maybes.

 Prototypes validate fun. Technical spikes validate whether the game is feasible to be made.

You’ve prototyped your video game idea or even took a step further and made a vertical slice of your game. Despite that, your video game isn’t progressing as expected. You’re constantly hitting one barrier after the other, and you wonder why. Everyone’s been preaching the last few years that creating a prototype of your game is a smart move to verify if you can turn it into a full game. Unfortunately, creating a prototype doesn’t equate to feasibility, and it’s what most devs are missing.

By making a prototype, you’re verifying if the game is fun to play, but it doesn’t mean you can turn it into a functional game. That’s one of the most common reasons we, as devs, fail or constantly pivot. The real problem isn’t that your team isn’t prototyping enough, it’s that you don’t evaluate the risks first. By the way, this isn’t something new game developers struggle with; even seniors fall into this trap.

Differences between Prototypes and Technical Spikes

Being a lifelong learner, I solved this particular problem by applying technical spikes, something I’ve been using more and more recently in my solo projects. While this might sound like a new or niche concept, its roots come from Extreme Programming, one of the Agile methodologies. Its application is just as relevant today, from indie teams all the way up to AAA games.

In my personal projects, I used to start with the concept, create detailed documentation, then build a prototype or vertical slice to see if the game could be made. The benefits were obvious: if we couldn’t implement the prototype or it wasn’t fun enough, we’d iterate or stop development entirely. The issue was that further down the line, we would face technical barriers the team wasn’t aware of. The prototype answered “is this fun?”, but it didn’t answer “is this feasible to complete?”

This reminds me of one of my failed projects where I was the project lead a few years ago. We were trying to make a horror game for portfolio purposes. On paper, everything was going smoothly. The programmers had years of experience, and our documentation was clear and specific. Despite that, progress was minimal. Once we tried to fully implement the documentation, we ran into a series of technical issues that no one had anticipated, eventually leading to the project being abandoned entirely. The warning signs were there; we just never asked ourselves if they were feasible. That’s why in the last couple of years, I’ve been using technical spikes as early as the paper prototype phase to verify whether certain things are even possible.

The term originates from Extreme Programming and describes a time-boxed investigation designed to reduce technical risk. Unlike prototypes, which focus on player-facing value, technical spikes exist purely to generate knowledge.

 What makes technical spikes different is that most of the work produced is throwaway. The code, assets, or setups exist only to answer a specific question. A lot of teams or individuals avoid doing this because it has no immediate gamer-facing value, and team leads or solo developers often assume these problems will be solved “later.” Trust me, they won’t. They’ll accumulate quietly over time. If you’re lucky, you’ll fail early. If you’re not, you’ll fail at a point where you’ve already invested months or years of time, energy, and money.

Technical spikes aren’t limited to programming either. They can be applied to art pipelines, animation workflows, content production, tooling, performance constraints, or even team capability. They are about exposing risk early, wherever that risk is.

For my newest projects, I always start with technical spikes to evaluate whether the game can realistically be made. In Parallel Pulse, for example, I initially created a 2D character sprite to evaluate the time and cost required. Very quickly, it became clear that this approach would be extremely time- and cost-intensive. Replicating this process across multiple characters and enemies made it obvious that I would never have the capital, time, or manpower to complete the game.

That spike didn’t give me a feature; it gave me a result. I pivoted and started exploring whether creating 3D characters in a similar style would be more efficient, since animations could be retargeted across characters. Because the game leans heavily toward an anime aesthetic, I’m now experimenting with 3D software specifically built to create anime-style characters quickly. Through this process, I also realized that quadruped enemies would be nearly impossible to support given the constraints. Without this spike, I would have discovered all of this much later, after committing fully to an unsustainable pipeline.

What surprised me most after adopting technical spikes wasn’t how often they killed ideas, but how often they saved them.

 If you’re a producer or lead in a hobby game dev team, identifying risks early on is critical to ensure the project remains feasible. Usually, the prime suspect is scope creep. Once the project balloons into something far larger than the team can handle, the project is in imminent danger of failure.

Most common reasons hobby game dev teams fail

I saw this firsthand in several of the teams I worked with.

When I joined my first hobby game-dev project as a programmer back in 2016, the team crumbled after a few weeks because the project kept expanding. More and more features were added, assets doubled and then tripled, and the design became too complex to develop. This happened because there was no clear direction from the lead, who eventually, out of frustration, abandoned the project. This was the nail in the coffin for a very promising idea. But as I learned the hard way, ideas are useless; execution is everything.

Therefore, strong leadership and solid game production are essential to execute game dev projects properly.

In 2021, I decided it was time to start a project of my own. With several years of project-management experience behind me, I finally felt confident enough to take on the challenge. A three-month game jam was happening at the time, so I immediately searched for collaborators on DevTalk, LemmaSoft, and Reddit. To my surprise, I found plenty of people who were eager to join.

From the beginning, I knew the project would never be completed unless we kept the scope under control. To do that, I asked each creative to estimate how much time they’d need for their tasks, and I started documenting all required features and assets. This allowed me to easily spot scope creep and excessive asset requests, which I cut immediately. A simple framework I used is MoSCoW, which organizes features into clear priority levels and prevents unnecessary expansion.

MoSCoW Framework

Three months later, we had not only one game under our belts, but two, since we also completed another one-week jam game during that period. Over time, more people joined the effort as word spread. By mid-2022, the team had grown to roughly 50 members, and together we had shipped seven (7) hobby games.

Looking back, the difference wasn’t talent or luck. It was structure, discipline, and treating even a hobby project with actual production habits. Clear scope, consistent communication, and firm boundaries turn “maybe someday” ideas into finished games.

It’s been a long time since I felt that good about my game development journey. I’ve learned a bunch of newstuff in Unreal Engine and Dialogic/Godot over the last couple of weeks thatkeep me focused and motivated.

As I mentioned in my previous devlogs,I’m focusing on two projects to get myself accustomed to new engines and tech.

Let me give you a quick breakdown.

Rogue Shifters

I’ll start with Rogue Shifters. Thisproject is basically a precursor in terms of learning and technology forParallel Pulse. I want to develop a full-blown visual novel in Dialogic,creating systems close to what I’m going to need for Parallel Pulse. Initially,I wanted to mimic the exact same approach by having multiple bubbles on thesame screen. It seems that making this type of setup would need a lot of codeimplementation, making things extremely hard for me to proceed with my game.The solution is simple, and I can pretty much do it with workarounds, havingonly one bubble at a time within the screen. It’s not what I wanted, but the difficulty levelincreases by X10 if I go with multiple bubbles. I probablyshouldn’t stress myself too much about it, and I have a lot of people tellingme they prefer only one bubble at a time because it’s easier to read. To myknowledge, the only engine capable of doing something like this efficiently is Ren’Py, which this year incorporated an easy bubble system.

Exploring Dialogue Bubble Presentation in Dialogic 2

In terms of assets, I have the basicposes for the two protagonists and the basic roster, but I’m missing a fewimportant ones. It’s not clear to me how I want them to be presented visually.That being said, I’m still polishing the assets, such as upscaling, cleaning,and outlining the characters. Also, I’m missing the majority of the backgroundimages, but I don’t see this being an issue since Idon’t have a lot of locations. When I wrote the script back in 2022, I wrote itwith economy in mind to save on assets. I’m a little bit concerned about theanimations since I’m not that familiar with tweens in Godot, but that’s why I’mmaking this project: an opportunity to learnthe engine and familiarize myself with Dialogic. I don’t have a clear timelinefor this one, but it could be ready in a few months if I focused myselfin it. A rough estimation for this one is Q1 of 2026.

Project Edenfall

This is a fairly ambitious soloproject since it’s the first time I’m making something as challenging as thisone. It includes making 3D models, levels, a combat system, and a dialoguesystem in Unreal. I’m trying to build my stack in anefficient way, so that I can build my next games usingthis one as a base. I’m surprised how manythings I’ve learned in the last couple of weeks, and what’s most important is that I encountered issues I would never have imagined, such asfinding proper animations, fixing fingers, and debugging the system. Thisproject motivates me the most right now because Ialways wanted to make games in Unreal Engine, especially 3D with a blend of 2dvisual novel style. I don’t have a timeline for this one either, and I’m not even sure if I’ll manage to finish it: level design is myweak point and dialogue systems in Unreal Engine can befairly complex, but similar to Rogue Shifters, this project aimsto help me learn the engine to make better games in the future.

Retargeting Animations from GASP

Objectively, the biggest issue I havewith this project is the lack of vision and direction. It’s not like I have aclear view of what I want to make, but I’m expanding based on what I can makeand what’s possible with my current level. For example, I started experimentingwith 2.5D environments to make a sidescrolleronly to realize this wouldn’t be possible given the lack of proper assets, letalone the complexity in terms of level design. The original idea was for theplayer to navigate the 2.5D levels in sidescroller mode, then have an RPGvisual novel style to interact with NPCs and get missions. I decided to changeit to a hack-and-slash arena game where you take on missions via a map, clearthe arenas, then interact in VN style with the rest of the character roster.This seems way more intuitive and fits the tone of the game. The reason I tookthis turn was because creating landscapes and materials in in full were easier to make given the existing pipeline.

Conclusion(of this post)

To wrap things up, I finally feel likeI’m moving in the right direction again. Both Rogue Shifters and Edenfall areteaching me different things: one helps me refine mystorytelling and systems, the other pushes my technical limits in Unreal. It’snot about finishing them fast but about building the foundation I need for thegames I really want to make. For the first time in a while, I feel confidentthat every hour I put in brings me closer to that goal.

 

With Cook or Be Cooked coming up next on Steam, and me having released roughly a dozen games so far (admittedly the majority of them jam games), I had decided to stop doing game development and potentially cancel Parallel Pulse.

What changed my decision was the arrival of new technologies—specifically AI—and my shift toward solo development for the majority of my projects.

Why this change of heart, you might ask, and why is it that AI convinced me to continue down this path? The reasons are several: solo development for indie games is more possible than ever. A single person who’s a generalist can now develop full games by themselves. It’s cost-effective and faster compared to traditional development. And finally, one person can now compete with teams made up of a dozen or more people.

Experimental VN style made with AI in a PC-98 aesthetic. It’s the kind of niche project I’d normally never pursue since it wouldn’t reach the market.
There’s a lot of talk about AAA replacing people with AI, and yes, we’ve seen that to some extent—but the real concern is actually smaller teams or solo devs who can use AI effectively and create high-quality games faster and more efficiently. That could become a real issue for big corporations and big studios. Adapting to rapidly expanding technologies is going to be much more challenging for AA or AAA studios than it is for solo or indie developers. That’s why I think incorporating AI as a solo developer, or as part of a micro team, can have a huge impact right now.

In a way, this reminds me of the early days of the internet, when small businesses or even individuals grew into big businesses because they embraced it early.

This doesn’t mean that every single game I make from now on will use AI. Parallel Pulse will still be developed the traditional way, since that’s how I started it. But for smaller-scope projects—things I want to test, experiments, or quick builds to train new skills—I’ll use AI as much as possible to push myself forward.

 It’s been roughly seven months since the last update, andwith the upcoming release of Cook or Be Cooked on Steam, I think it’snecessary to update everyone and also put my thoughts in order.

Cook or Be Cooked

Cook or be Cooked Key Art

The project wrapped up production around January of thisyear and is ready for release. Although I was planning for an earlier launch, Iwanted to give the game the chance it deserved and see if it could get a strongrelease. I’ve presented the game at Athenscon convention last year and thepeople who played it really loved the story and the artwork, which motivated meto apply to Gamescom through the Hellenic Film & Audiovisual Center.

The game was selected in the top 10 from the Center, givingme the opportunity to attend the biggest convention in the world once more.This time I focused on finding a publisher as well as participating in theSteam event, hoping to gain several hundred or even thousands of wishlists,which could boost the game’s visibility. As you might know, you usually needaround 7,000 wishlists before release, otherwise the Steam algorithm won’t pickit up.

Greek Video Games Booth at Gamescom (Business Area)

On publishers: I talked to a handful, and two wereinterested in the game. The first thing I did after returning from Gamescom wasto immediately send a working build as well as a pitch deck. It’s been threeweeks since then with no replies, which is a clear indication they’re notinterested. My plan was that if I could get enough funding, I’d expand the gameto 6–8 hours of gameplay. Since I don’t have the funds, the game will releaseas is—which, in my opinion, is in a good state, and the story is self-containedfor this type of game, so no harm is done.

Unfortunately, the Steam event didn’t go well this year. Igot only 200 wishlists, and from the other developers I spoke with (around twodozen), the results weren’t good for them either. The game currently sits ataround 400 wishlists, which indicates it’s heading for a weak release and won’trecoup the money I invested. That’s acceptable, since I wanted to familiarizemyself with Godot engine more than anything.

The game is scheduled for an October launch on Steam, but itis already be available on Itch. I’d also like to thank a couple of people whosupported the game more generously than expected, it truly means a lot. Thoseof you who supported the game’s release, if you’d like a Steam copy, pleasereach out ,and I’ll send you one. I honestly appreciate your contributions andhope you’ve had a fun time playing the game.

Parallel Pulse
Parallel Pulse's Protagonist: Laios

I made very little progress this year on my main game. Ifelt downcast and rushed to finish it but Cook or Be Cooked taught methat I should take my time. This game should be released when it’s ready, notonly because I love the artwork and story, but because I need to focus onlearning the engine better.

The reason I’ve managed to release a dozen games so far isbecause I did most of the programming myself, and the same should be true here.The most costly part of Parallel Pulse would be the programming part,and the budget would have been enormous. If I hadn’t gone through the processof releasing Cook or be Cooked, I might have poured money into it only torealize I didn’t have the funds to finish.

On the bright side, a big publisher is interested in ParallelPulse, but I’ll need to create a proper vertical slice for them toevaluate. I also submitted it to the EU Commission this year and scored 72 outof 100. While I passed the threshold, the enormous number of applications meantI didn’t get funded.

Still, things aren’t all gloomy. I now have a much clearersense of what needs to be done to complete this game. I love the story, andeven more so, I love the beautiful artwork the artists created. That said, Istill lack the programming experience needed to build the combat system and thedialogue UI, so for the time being I’ll focus on learning the engine more. Fromtime to time, I post updates on Bluesky, so feel free to follow my progressthere.

All things considered, development on Parallel Pulsewill resume at the beginning of next year.

Project Rogue Shifters (Codename)
AI generated Aat with the protagonist of the game
I don’t think I’ve ever mentioned this project here, but thehistory behind it is interesting. It’s an old project I started about threeyears ago. The initial characters for Parallel Pulse were firstdeveloped for Rogue Shifters, though the story and setting were entirelydifferent—it’s basically a yaoi visual novel. At the time I was burnt out anddecided to shelve the project, which was the right call since Parallel Pulseis the priority when it comes to allocating funds. I tried to find a publisherfor Rogue Shifters during Gamescom but had no luck.

I considered shelving it again, since I had little faith itwould recoup its costs, let alone become a success. The only thing I really hadwas the story and script, which are basically finished. So, I had two options:kill the project once more, or use it as a training exercise to learn theengine better.

I’ve decided to use it as a training opportunity to learnGodot and the Dialogic plugin better. Although I’ve used the plugin before andreleased two games with it, I wasn’t the main programmer, so my contributionswere limited. This means I still don’t know how to create a save system orcomplete the full UI. Like with Ren’Py visual novels I made in the past, I’llgradually build my skill set here too.

I’m not someone who learns well by studying blindly, I’mproject-driven, and I think most people are. To improve, I need to work on newsmall projects, finish them, and polish them. In the past, that was eithertime-consuming or expensive, since I had to join game jams (which meant alsohandling project management, not my current focus) or pay for assets to makenon-profitable games. At the current state I’m in, I don’t have the money ortime for that. The alternative is to use AI-generated art, which allows me tofocus on programming and writing.

I know some of you might not agree with this approach, but Iplan to use technology to improve myself so I can eventually commission properartwork for my main game. Rogue Shifters was dead anyway, but now it canserve as a stepping stone for Parallel Pulse. The script is around 50K words,and the dialogue UI I need to implement is nearly identical to ParallelPulse, making it the perfect training opportunity.

Project Edenfall

This isn’t a full project yet, and I don’t know where it’sgoing, but I’ve been delving into Unreal Engine on and off. For those whoremember, I first tried developing Parallel Pulse in Unreal, but itwasn’t the right fit, which is why I switched to Godot.

Even if I don’t know where Edenfall will end up, theimportant thing is that we can iterate fast and learn the engine along the way.Similar to Rogue Shifters, we’re trying to establish a pipeline togenerate materials and 3d AI assets where needed, so we can focus on the partsthat matter most to us. What’s great about this endeavor is that my partner isan artist, so when we have a blocker he can easy resolve things.

Final Thoughts

This summarizes the current state of my roadmap. Honestly, Iwas close to quitting game development for my personal indie project because ofthe pipeline problem: either join and manage game jams or pay for smallerprojects just to practice. Some might disagree, but incorporating an AIpipeline into my smaller projects is what motivates me to keep going andimprove as a game developer. Thanks everyone for reading and supporting me.

 

When I sit down andthink about the future of indie game development, well... I don’t feelconfident, to say the least. I think I massively miscalculated both the stateof the market and the potential for making a profit with indie games.

As always, I want toclarify what I mean by indie games. I’m not talking about AA titlesbacked by publishers that are essentially smaller AAA productions. I mean indiegames made with little to no budget. If you check my itch.io page, you’ll see that I’ve already published a dozenvisual novels and narrative-heavy games, with Spellbound Hearts beingthe only commercial release.

I think only a few ofyou know the story behind why I decided to make Spellbound Hearts acommercial game. The reason was simple: I enjoyed making it, and I felt itdeserved a commercial release. But the most important reason was because Iwanted to learn the process of publishing a commercial game on Steam so I’d bebetter prepared for my future projects. I did almost no marketing oradvertising, and the game has sold around 300 copies. Since it’s so cheap, itbarely made me $170 in profit. But still, it was a great experience that helpedme understand the process for my next commercial games.

When I first got intoindie game development, it was a hobby, and sometimes I feel like it shouldhave stayed that way. There are several reasons why I don’t think this is aviable path for making a living.

The Reality of theMarket

First, making a decentgame requires a massive time investment. At the same time, you’re competingwith countless other releases hitting the market daily. Unfortunately, the onlyviable marketplace for selling indie games is Steam, and we’re looking at 20–60releases every single day.

I get that some mightthink most of those games are low-quality asset flips, but I’d argue that asignificant percentage of them are high-quality projects. Many of these gameshave taken their developers 2–5 years to create. There's this misconceptionthat gets repeated all the time: that most indie games are low effort, but realitytells a different story.

Back in 2019, around9,000 games were released on Steam. In 2024, that number nearly doubled to 19,000games. If that’s not an indication of oversaturation, I don’t know what is.And this doesn’t mean that each new year wipes the slate clean. Every newrelease is added on top of the massive backlog of already great games.That’s why Steam now has over 100,000 games, many of them high quality.

On top of that, mostplayers primarily consume AAA content: Fortnite, PUBG, Call of Duty, LoLetc. The slice of the market available to indie games is already small, andwith thousands of new indie games fighting for attention, the chances ofsuccess keep shrinking.

The MarketingDilemma

Yes, marketing shouldstart from the moment you conceive your game—before writing a single line ofcode. But if you start making your game now, and it takes 2–4 years to develop,by the time you release it, you’ll be competing with 40,000–80,000 moregames in the same marketplace. Sure, there are exceptions: games that go viraland succeed, but luck plays a huge role, and you can’t just design indiegame content with the expectation that it will go viral.

Comparing Indie Gamesto Indie Book Publishing

When I say Imiscalculated the market, it’s because I initially thought indie gamedevelopment would work similarly to self-publishing on Amazon. I was sowrong.

It’s funny because thebook industry is way more saturated than the game industry, yet it’sstill easier to make money from books. Here’s why:

Writing a book is far less complex than developing a game. A decent writer can finish a novel in a few months, publish it, and quickly move on to the next project without a huge financial investment.

If a book fails, you can start a new one without breaking the bank. You don’t even need to pay for a book cover (though I recommend it).

Books have quick iteration times, meaning you can release multiple books a year. Some will fail, but some will succeed, and the process is relatively fast.

Following trends is much easier in book publishing. If you start writing a trend-driven book today, you can release it within months (and I know of some people who write books within a month). In contrast, if you start a trend-based game today, by the time you finish in 2–4 years, that trend might be completely irrelevant.

My Plan MovingForward

As I mentioned in myprevious blog post, I plan to release Cook or Be Cooked as a short gameif I don’t secure a publisher and my Kickstarter campaign fails.

As for my next game, ParallelPulse, I’m planning to take a break before resuming work. Indie gamedevelopment is incredibly frustrating, especially when balancing it with dailylife, especially if you have a kid and a job.

Right now, I’m alsoapplying for Creative Europe funding, hoping to secure support for 60%of the game’s budget. Unfortunately, competition has become evensteeper. Last year, many publishers stopped making deals, so a ton of studiosturned to grants for funding.

The situation issimilar to Steam’s 19,000-game flood. Just because all those games aren’tdirect competitors doesn’t mean they don’t impact the ecosystem. Two years ago,if your Creative Europe proposal met the threshold score, you’d receivefunding. Most of the times, Creative Europe applicants wouldn’t absorb theentire budget because a lot of proposals wouldn’t reach the 70% threshold. Butlast year, the number of applicants skyrocketed. Many proposals were lowquality, but plenty of good ones exceeded the threshold for the firsttime. The bar has been raised, and what used to require a 70% score now needsat least 80%.

To put things intoperspective, CD Projekt Red is one of the companies competing for thesame funding. So… yeah. Good luck with that.

What’s Next for Me?

That being said, I’mnot quitting game development. But I do want to approach it smarter, ina way that doesn’t drain me financially. After Parallel Pulse, I’mconsidering joining other teams, either as a programmer or writer, rather than managingand financing everything by myself. That being said, Parallel Pulse will take acouple of years to be completed, so this isn’t an immediate change of plans(despite my rant above).

At the same time, I’mthinking of taking a short break to write a couple of books after releasing Cookor Be Cooked. I think it was a mistake to abandon that revenue stream, especiallysince it’s something I enjoy as much as making video games.

I know this post mightsound a bit depressing, but it’s better to see reality early rather than wasteyears on projects that don’t make sense.

One thing I’ve alsostarted questioning is the idea that indie developers should release as manygames as possible to increase their chances of success. Given how manygames flood the market daily, this approach might be flawed. I’m starting tothink that YouTubers who also make games might have the right idea. Longdevelopment cycles might actually be better because they allow more timeto market the game while also producing YouTube content. Of course, this isn’tan ideal solution, since many YouTubers make part of their income from theirchannels, not their games. But for them, long development times mean morecontent for their audience, which in turn keeps interest in their game alive. That’ssomething I’m considering for Parallel Pulse.

That being said, ifyou’re just starting out, you should definitely release as many short games aspossible to learn the process. I released a dozen free short to medium sizedgames before releasing my first commercial game, and I find it as an excellentstrategy if you’re just starting out.

It’s been a while since I last wrote a long-form update, so I think it’s time to bring everyone up to speed. Well, at least the few people following me 😊

In the world of startups, there’s a saying: fail fast. The idea behind it is that the sooner you recognize something isn’t working, the better! It saves you time, effort, and money before sinking too many resources into it. And I think this applies to Cook or Be Cooked. Let me explain.

My target audience for this game is female under 25, something I confirmed last year during AthensCon, a pop culture festival in Greece. Everyone in that target group who played it was excited about it and wishlisted it. Having that direct feedback loop is invaluable since it helps you understand whether your game has potential.

The biggest challenge, though, is actually reaching that audience. For various reasons, I think it’s going to be extremely difficult for Cook or Be Cooked to gain traction without proper marketing. And honestly, I have no idea how to effectively reach potential players on my own compared to my other game: Parallel Pulse.

That’s why I’ve decided to take a different approach: rather than investing too much more time, I’ll reach out to publishers and see if there’s any interest in the game. As you all know, securing a publishing deal in today’s market is tough, and I don’t think my chances are very high. That’s why I’m also considering running a Kickstarter campaign to gauge interest and see where the project stands.

Now, I know what you're thinking: Kickstarter requires an established audience to succeed. And that’s the paradox: if you already have a dedicated audience, you probably don’t need a Kickstarter unless you're looking for initial funding. In my case, I don’t have a large following, nor do I have the financial capacity to run a big marketing campaign to attract backers for my Kickstarter Campaign. And honestly, spending a bunch of money just to fundraise for the game feels a bit absurd.

That being said, I’m not planning to abandon the game. Cook or Be Cooked is designed in a way that allows for a self-contained one-hour experience, that’s what the initial plan was anyway. So, worst-case scenario, I’ll release it as a shorter game, similar to my previous title, Spellbound Hearts. I’ve already invested significant time and resources into it, and it would be a disservice to both myself and my team if we didn’t ship it. Since the game was made to support a shorter playtime, I’m going to move forward with that approach. At the very least, it will serve as a solid portfolio piece where all of us will be proud of while still appealing to our target audience.

In my next post, I’ll go into more detail about my overall strategy moving forward.

 ​Hey everyone! I wanted to give you an update on my Spooktober jam game and share some news.

​​​​

So, here’s the thing: I wasn’t able to publish my game during the jam. There were a few reasons for this, but the main one was that it just wasn’t as polished as it needed to be. Despite that, working on the game was a blast, and I realized I wanted to take it further. That’s why I’ve decided to expand it into a full-fledged game, with plans to release it in 2025.

Cover image of our Steam & Itch page

To make that happen, we’ve essentially gone back to the drawing board. We’re programming everything from scratch to fix bugs and make the game scalable for a larger experience. Anis, our talented pixel artist is creating more assets and helping us refine the game’s vibe—imagine a spooky Harry Potter-esque atmosphere.

We’ve already submitted a Steam page for review, and we’re also working on an itch.io page. I’m holding off on making big announcements until we have the final graphics ready, but it’s all coming together.

On the story side, I’ve finalized the direction. The first part of the narrative, including the dialogues, is fully written and edited. What held me up for a while was figuring out where the story should go next. But after some brainstorming time, I’ve got a clear direction! If you’ve been following my devlogs, you know the game’s plot started with inspiration from Hansel and Gretel. The main storyline, however, is shifting gears toward something more like Oliver Twist. It’s a cool mix, and I’m really excited to see how it all plays out.

Our programmer, Nick, had this awesome idea to add a simple but engaging cooking mechanic. It’s shaping up to be a big part of the second half of the story, where you become a restaurant owner and get to cook for vegetarian vampires (and why not, werewolves).

[image error]

Cooking Mechanic

Overall, I’m glad with how this project is evolving. Thanks so much for reading and for supporting this journey—it means a lot! Stay tuned for more updates soon. 😊