Ludum Dare 37 theme was "One Room". This was our entry for the Jam. Triskaidekaphobia. Game where mysterious room filled with people bound in straitjackets. They all want something and you want to be rid of them.
72 hours were spent in making this hopefully enjoyable experience. Lot of features that I wanted to implement never made it to the game and a lot of stuff scrapped due time constraints. Thankfully this was fun project to work on and never made me feel like I couldn't get a version out I was happy with. At the end of day two I could have released a version if needed to.

Papercuts and Backbone

Triskaidekaphobia had it's design in terms of objective and evolve through out the 72 hours of development, Only at the end of the second day we had clear idea what player objectives were. Game development started very quickly as we found the isometric world with "paper-like" characters to be appealing and it gave a clear idea of player and npc movement.
For character movement collisions I decided to keep simple 2D boolean array. While in semi turn-based games some sort of physics query could do the job, I was not sure how many characters I was going to have.

Character facing was very important for multiple reasons. First of all the player vision would play integral part, early on we decided that the end game big reveal was the player character's identity so we only gave hints of it as a siluet. Second reason for our facing system was character input. Single input turned the character and repeated input would move to that direction. This system of inputs made building AI around it easy.

Something to poke at

Speaking of AI, I originally was going through building simple A*-pathfinding but with the time constraints decided against it. Instead I went with mostly random inputs. There are some variables that different characters have. First is the "aggression", simply how likely the character is going to include attack-input in the queue. Second is the "activity", this is simply maximum delay between inputs. Third and final value is the "repeat", with high repeat value the character repeats the last input it did more often. The only difference between player and AI characters is the lack of Attack button for player.

What do they want?!

Fuzzy design for the game was giving the npc characers items they wanted, much like a memory game. You would talk to the character and figure out what it wanted. Later on we figured that the objective of the game could be simply getting rid of all other characters. The npc can kill each other and the player. So they can work for the player if they are clumped together or against the player if he needs to talk to them. The byproduct of our character facing implementation was that when character attacks, it attacks in front. If player talks to a character, it turns to face the player. As a result you don't want the characters facing you and you don't want to risk talking to them needlessly.

What am I looking at here?

Last big piece of the design was the "Interact" and "LookAt" inputs. Both much in the same way. All items and furniture and players have a box collider. I didn't want to make rigid system for the items you can pickup so I wanted them to fall on the furniture naturally, this meant I would need to do physics query at the target tile. This gave me flexibility to make the dropping item from hand more natural.