We have finally released the game, available on for $0.00 or more! Along with it, we have a short, one-level demo, on the Scirra Arcade and Newgrounds, that hopefully showcases what the game is about and how it works without revealing too much. I am really happy with the result, and hope that lots of people enjoy the game.

I want to take this opportunity to share some details of the development and the game, to give you an insight of how much work went into creating it.

The Construct 2 project contains 1262 events (!!!) on 28 different event sheets, 35 layouts (of which 16 are game levels) and 8 object families. The source repo has over 250 commits, 3 open branches and 5 tags. We’ve been working on this project for over 5 months, with development starting at around January 2017.

Here’s some great graphs from the git repo:

(Commits over time and punchcard)

The Taker Devblog: Rain on maps

The rain effect was originally meant to be used on every map, and all of the early prototypes had rain on them. Then we added an option for new maps to disable rain, and basically every map we made afterwards we disabled it. It’s not that it’s a bad effect, I think the sound adds atmosphere to the game and the visual effect looks pretty good, but for every map that has rain, we have to:

  1. Enable it, since it’s off by default
  2. Create invisible entities that say what the volume of the rain sound should be
  3. Specify what surfaces the rain should splatter on, since it shouldn’t be inside the house

It’s not a lot, but for a pretty pointless effect to add this to the already long level creation pipeline, we don’t really use it much.

The Taker Devblog: What’s so hard about making games?

Unfortunately, development has slowed down a bit. We’ve nearly got the engine done, and we’re starting to get into designing the rest of the levels. The thing is, after a while, everyone loses interest in their projects. Even when working in teams, people start ambitious projects, and even if they have the time and resources, they don’t finish what they’re working on. When planning a project, it’s really important to not just think of what you can do, but also what you’re willing to do. If you do game development as a hobby and start on a project that seems like it will take a month, not only will it probably take more time because your initial estimates weren’t accurate, you’ll also lose interest after a while and look at your project thinking: do I really want to finish this, or do I want to start a new project as I have more experience? This doesn’t look that bad at first, but it’s likely that you’ll abandon that project as well for many of the same reasons, and so on. It’s really unfortunate and a lot of great projects are lost because people lose faith in them, or just get bored.

It’s happened to me too many times, and now I try to plan everything in a way that it doesn’t happen again. If you think some features are missing from The Taker, or you’re wondering why we didn’t spend more time on some parts of the engine, it may be that just putting that work in would have made progress even slower, to the point that we eventually don’t even finish the project.

I really hope that The Taker will be finished, and right now I’m pretty sure it will be. I just wanted to share this short update on what I think is the biggest danger to our project. If you’re developing a game I wish you the best of luck finishing it.

The Taker Devblog: Trap System

Hi, I’m Zia, I generally make more of the ‘initial implementation’ as in the quick and dirty program which shows off the idea, its generally Dylan or Csongor who clean up my mess! Now my most recent addition is the Trap System! Something I have had on my mind for a while, and finally decided to implement the bare bones. As it stands it serves its purpose but it has its bugs definitely! The AI may crawl along the floor on occasions!

Currently only works with hideable furniture (E) but there will be many more traps to come!

I got the idea when i realized as much as stealth only would be great (And maybe with more balancing, and future additions its all we will need!) the police tend to overrun the player after a while. Now as the game stands its in a very early stage of development and were exactly this goes in the future, i can’t predict.

Now as for previous implementations, well there isn’t too much, you will most definitely hear from me again, i have a few ideas in mind but only time will tell. As it stands, I broke quite a few things so i’ll be looking into that.

Have a blast,


The Taker Devblog: What We Use

In case you were wondering what’s going on behind the scenes, I’m going to tell you in this post what we use to make The Taker.

Construct 2: to make the actual game, we use Construct 2, which is an amazing game making tool by Scirra. It’s great for beginners, but can also be used for bigger projects.

BitBucket: we’re a small team with no real budget, so we use the free plan of BitBucket. Since GitHub is only free for open source projects, and since we didn’t want to reveal the source code, this was our best option.

SourceTree: this is the desktop client that comes with BitBucket, since it’s also developed by Atlassian. Even though SourceTree is a bit more complicated than GitHub’s desktop client, it has worked great for us.

Skype: other than email, we use Skype for communication inside the team. It may not be the best, but it’s reliable, easy to use and it’s good enough for us.

I can’t really say for anyone else on the team, but I also use these:

Paint: if you want to quickly edit, crop or resize something, Paint is always available and it works.

iMovie: for the second gameplay trailer, I just used iMovie, not because it’s the best, but the result looks good enough and it’s fast.

OBS: I can’t really recommend OBS for recording Construct 2 footage because of performance issues, but my other option would have been Fraps, which doesn’t work with C2 at all.

We also use WordPress at for our blog, Windows as our operating system, I use Notepad++ as my text editor and my server is running Ubuntu and Apache. We currently have no 3rd party plugins in our project. We use custom-recorded sounds or sounds and music from the YouTube Audio Library, and I use Audacity to edit audio. We use Chrome and Firefox for development and testing.

The Taker Devblog: Dynamic Rain Sound

The rain sound in The Taker pretty much functions as an ambient sound, providing some sort of atmosphere. This sound is dynamically changed based on what room you’re in in the game. Behind the scenes, there are areas with specified volumes that set a variable to the desired volume while the player is standing in them. This variable is then used to set the volume of the rain sounds with lerp, a function in Construct 2 that linearly interpolates values. That just means that changes in volume are gradual, which makes them sound a lot better.

lerp(Audio.Volume("fx_Rain"), fx_rainShouldBe, 0.05)

Fun fact: this rain sound is the third variation of the same sound we’ve used.

The Taker Devblog: UI Sounds

Hi, I’m Csongor, I made most of the menus in The Taker. Currently, all the menu items change color when the cursor is hovering over them, and they also make a sound. You might think that these sounds are connected to the colors changing, but it’s actually independent. When the cursor object collides with one of the menu items, it just plays the hover sound. The click sound is triggered along with the functionality of the buttons, that wasn’t too hard to set up.

The sounds I got from the YouTube Audio Library, their collection is pretty expansive. I downloaded a long recording of keyboard sounds, and just cut out two of the key presses, one loud and one quiet. I thought the repetition would be annoying, but since the sounds aren’t too loud anyway, you don’t really notice it.

One of my favorite games, The Stanley Parable, also used keyboard sounds for its UI, although that was more obvious and the sounds were also used for any interactions within the game. It also randomly played different versions of the sound, so it wasn’t repetitive at all.