You may want to play the game before reading this, if you’re reading this:

https://ldjam.com/events/ludum-dare/47/time-hog-day

Theme:

Upon hearing the theme my mind went to ground hog day and office work. I decided to use a ground hog day type scenario and apply it to an office worker stuck in a grind at work.

I wanted to make it so much of the time would be spent churning out levels so a simple game use idea.

In terms of mechanics, I quickly considered stealth a natural fit. I have played enough Hitman to know the joys of repetition in the genre, but understanding some of the difficulties I decided to model it on very early stealth games, namely metal gear 1.

This means that guards follow very set patterns and see, instead of the more standard cones, in straight lines in the cardinal directions.

For this clear signposting would be needed for the guard viewing direction and therefore animation would be needed, something I have mostly avoided in previous jam projects up until this point. So this would be part of what I hoped to learn with the project.

Stealth lent itself naturally to trying to sneak out of work, so enter out poor office worker trying to leave work early, he would have an array of other unique workers trying to talk to him and waster his time, each with a unique line of dialogue.

Problems:

• Not enough testing: When I started I decided to use Unity's in-built character controller which I though would work with 2D square colliders and my initial testing seemed to indicate it does, but that was without fully fixing position and it turns out a 2d object will rotate but not step the player. Once it realised this I did the inelegant solution of adding 3D colliders for movement and 2D colliders for vision ray casting which had already been implemented instead of using a combined system. I was hoping to use the system of rotatable objects that I had discovered to add doors you could hide behind but it didn’t end up working consistently, but instead fixing rotation and not position allowed for an easy movable table that could be used more many of the puzzles I ended up with.

• Layering: In 2D games you have to have some method of layering the sprites so the correct sprite will be displayed ontop of the others. Not wanting to work out a good solution, I hacked a solution whereby each object gets a script that sets its z position to its y position multiplied by a small amount, which works… I guess.

• Restricting the resolution: Wanting to be as lazy as possible meant not wanting to deal with a plethora of different resolution option, this was not a terrible idea in itself but I decided to restrict it to the default option that itch gives which is something around 640x360px, a truly tiny screen. This restricted the possible levels massively because I wanted to make sure the game state was understandable from a glance. Why did I not simply allow multiples of this resolution? I did, but only right at the end so it didn’t change the design.

• Planning too much content: I realised the idea of adding a set of unique office workers to each level with unique dialogue was too time consuming for the jam, and on top of this I realised that the theme fit the same guards where everyone in your work looks and acts the same. On top of this it made adding the easter egg really easy. This allowed me to focus on making levels, more of which could’ve been added but at some point I called it, which was a good thing because...

• Animation error on compilation: Usually when I do a game jam I am working right up until the final hour. With this project basically complete with the only expansion required being additional levels to be added, or the current set of levels to be tweaked, I decided to release with what I had. This was a good decision because it turned out the build version did not work in the same way as the version in unity editor. Specifically the enemy animation and vision did not work, after being stumped for a while I tried a dev build and it turns out dev builds are super useful and it highlighted the issue with the game immediately. Basically, if I recall correctly, at the start of a level the enemies would when I tried to find the player with find object with tag “player” and then find the child of that which also had tag “player”, I assumed because it worked in the editor it would work in the build but it did not, this was easily fixed once the error was identified. Sadly footstep sound effects still do not work with the web build but I dunno whats up with that.

What went right:

I wanted the game to feel like you were stuck in a loop. This did not mean it had to be fun. I nailed that. The deliberate choice to load from the beginning if you were spotted, or even if you finish the game (hopefully) makes it feel like this guy is stuck in a dead-end job. Mechanically the game works fairly well for what I intended at least, I did not foresee adding movable cover which was a nice bonus.

What went wrong:

This restricted the level size due to the choice of resolution restricted the design immensely, which when combined with the choice of blocky level layouts meant some extremely bland levels. In each level I wanted to vary the size and challenge, with many of the levels trying to teach the player about how specific mechanics works, as well as giving players some shortcuts on earlier levels when they were caught and looped. But unfortunately many of the levels ended up just being a pain to get through. I also don't think I ever really implemented the crouch feature in a way that is useful to the game. It can be used to hide behind tables, but not being able to move with it makes it nearly useless.

Going forward:

I do not intend on continuing this game. Although I am not happy with the design of many of the final levels, I think the game provides the experience I wanted to provide and it helped me get a handle on some of the animation stuff used in unity. If I were to go forward with the game I would likely change the stealth mechanics to something more along the lines of Metal Gear 2.