Take IT Studio!

Facebook-f Gamico-icon-twitter-x Youtube Linkedin Discord
Home > Blogs > News
CategoriesNews

There’s a Gun in the Office – Devlog Series #3

Making a Game as a One-man Army

Hello again!

It’s Maciej, the creator of There’s a Gun in the Office.

Or should I say: the solo creator? Well, mostly. For the vast majority of development, I worked alone — though I couldn’t have finished without some key support along the way.

So far, we’ve covered two main topics: the game’s origins and its development timeline. Today, I want to talk about what it’s like to tackle a game project (almost) solo, where I sought help, and what I learned from the experience. Hopefully, this will offer some insight to players curious about how solo games get made — and maybe help other aspiring developers too.


Designing for Success
Main reason the game was completed? I designed it around my skills rather than my ambition.

There are two ways to approach design like this: lean into your strengths or steer clear of your weaknesses. I chose the latter — avoiding animation, AI, complex modeling, and clever art direction.
 

Instead, I focused on what I do best: programming logic, system design, and puzzle design. This led me to a game concept I knew I could handle:

  • First-person perspective: No need for complex character animations.
  • Logic-based puzzles: No enemies, weapons, or intricate systems.
  • Realistic environments: Easy to find reference material and generic assets.
 


Since I already wanted to make a horror game, these constraints fit naturally. With some basic audio skills, a microphone, and a keyboard, I could also record the sounds and music. My past experience in UI design from web development rounded out the necessary skills.

With all that in mind, I set out to make a first-person horror puzzle game in 3-5 months. It ended up taking 15 months — but the initial realistic scope was key to staying on track.

The Ups and Downs of Solo Development

Working alone has both advantages and drawbacks.
 
The biggest downside? There’s no one to pick up the slack or surprise you with brilliant ideas you hadn’t considered. Some parts of your game will inevitably be weaker than they could be in a larger team. And you wear every hat — from marketing and trailer creation to bug testing and localization.
 
But there’s a major upside: agility.
 
When you’re the sole decision-maker, you can pivot instantly, knowing exactly what the game needs next. There’s no need for lengthy meetings or waiting on consensus. That speed and clarity are invaluable for maintaining momentum.
 
Staying Focused: The Art of Cutting Features
When you’re passionate about your game and have the skills to bring new ideas to life, it’s easy to keep adding features. The temptation is strong — after all, you want to make something great.
 

But knowing what to leave out is often harder than figuring out what to include. This is where a clear core vision becomes crucial.

Every time I wanted to add something or realized that a feature wasn’t working as expected, I asked myself:

  • Does this make the game scarier?
  • Does it make the experience more tense?
  • Does it make the story more compelling?
  • Does it fill a gap that the game is missing?
If the answer was “no,” I knew it wasn’t worth pursuing — especially if other parts of the game needed attention more urgently.
Imperfect Execution

Did I follow this principle perfectly? Definitely not.

There’s a system in the game that procedurally generates a city in the background — completely unnecessary. I also implemented a seed system meant to generate different puzzles with each playthrough, which didn’t make the final cut.

Some puzzles had to be removed entirely, and various systems (even multiple difficulty levels) still leave traces in the code, remnants of ideas I had to abandon.

In the end, I had to prioritize finishing the game over endlessly perfecting it.

The Importance of Feedback
Though I did basically all of the development work myself, I wouldn’t have finished without early and consistent feedback.
 
In the beginning, people said, “The idea is great, you should make it.” Later, it became, “The potential is there, but it’s not there yet.” That evolved into, “It’s almost there,” and finally, “I think you have a game here.”
 
This feedback came from friends, family, and fellow game devs — people I knew would be brutally honest. Their input helped me narrow the game’s direction quickly, cutting down on wasted exploration. Without that feedback, I doubt I would have finished in 15 months. 
Getting Help at the Finish Line
As the project neared completion, I received two major forms of help:

Publisher Support: Take IT Studio! provided essential assistance in getting the game to consoles and ensuring quality.
 

Cinematic Assistance: A family member and his friend helped create the dream sequences players see between days. Their work elevated the game’s polish and purpose far beyond what I could have managed alone.

Lessons Learned
Releasing a game solo is invaluable for understanding every stage of development and recognizing where outside help can make a difference.
 
It’s absolutely possible to make a game on your own — but it has to be realistic. Early in my career, I dreamed of making massive, epic games like the ones I played. But those projects are simply unattainable for a single person, no matter how passionate or dedicated.
 
It’s far better to create a small, finished game than chase an impossible dream that never materializes.
 
Maciej “ragir” Dyjas
 
https://store.steampowered.com/app/3291220/Theres_a_Gun_in_the_Office/
 
devlog_discord_01

Take IT Studio!

We make games