Postmortem - Crunchtime: the revenge of feature creep, or mo’ monay mo’ problems
History
Starting this project we all decided because of work and university, that we'd do a small game. We always say we'll do a small game, but they never end up being small because of feature creep. Our first successful ludum dare we made 'Barbarity' for ld36 a boat game that ended up being us trying to replicate Sid Meier's Pirates. So not a small game. Next we made 'Silicon Boulevard, a robonoire story' for ld39, a narrative game with combat and basic puzzles, so it was smaller, but still quite big for what we were able to accomplish in 72 hours.
We wanted this game to be smaller.

The Idea
When the theme was announced we didn't really know what to think. It seemed like the curveball choice got in but we started talking about ideas. Specifically to think of ideas we listed things that might get worse the more you get and built games around those ideas. The most prominent early on was a boat game where if you take on too much water you have to start throwing it out your ship, but as we had already made a boat game we let that idea slide.
Our final idea, as it often does with us, came from one of us off-hand suggesting an idea as a joke and then someone else latching onto that idea and building up a game from it. The idea was feature creep, you were a game dev studio and having too many ideas would be bad for your game, and this was the start of our feature creep.
At this point it was 3am so I went to sleep with a vague idea of what the game could be, but not what could make the game fun. When woke up I found out that @soldierbear had already made a prototype in Pico-8, this made me realise what could make the game fun. We had already decided to make the game in Love2D so we started out remaking that prototype.
The Pico-8 project was just a simple game where you run to people, slap them if they have a bad idea and don't slap them if they have a good idea. What we decided to make a new version of that, with a game development tycoon slapped onto it.
Development
Our first idea was a lot bigger, we would have moving employees, publishers, a boss character, a literal feature creep, random events etc. While we never worked directly on implementing them we had to generalise a lot of our systems to allow for them to be added, which took time.
Being new to the engine we were not really aware of how to do things like collision detection easily without the physics system, but we had been advised to not use it for simple projects so we wrote a movement system while we thought of how to do the collision. Then we rewrote it when we gave in and used inbuilt physics. But we didn't know of any method to work out what we'd collided with so we made a basic system for checking who was in the area, that needed refining. It was not refined.
Meanwhile, we made many of the systems without testing them, and since some of them were implemented only much later, they carried bugs throughout nearly the entire process. When we did test we found out that '=' for tables in Lua doesn't work like variables in most cases. It only sets the pointer equal to the same section of memory. Which caused problems when we wanted to make a copy of an object from a database, so this required some work to redo.
All this extra time spent working on things meant we left things like map design and making the controls feel nice to later and later, or not at all. It meant we didn't realise how unreadable the font we had chosen was, or how little time you actually have to get to people, until it was nearly too late. We never implemented any of the game ideas we wrote, partly because I didn't know if reducing the clarity like that would make the game any better, so we kept with the placeholders.
But unlike in previous years, we managed to finish the game ahead of time, and it was relatively stable (apart from a few bugs in later levels) release.
What was good about the game?
Both the graphics (due to @david-mason) and the audio (due to @soldierbear) worked really well I think, also I think the humour worked quite well, even if it did get in the way of a clear description in the opening cutscene.
Things we could've done better
Controls were awkward and the systems were not fully explained to players due to poor font choice and large amounts of text.
How We'll Improve For Next Time
We've said this after every ludum dare we've done, but we intend on making a smaller game. Specifically next time we will concentrate on a single aspect of the game, polish that and build a game around that instead of focusing on too much at once.
How to Play
Finally, I want to explain the idea mechanics because many people have been having trouble making money.
Basically our money system in Revenge of Feature Creep is linked to the review score, you get 1 star for a completely finished game, to ensure a game gets finished slap the crunchtime gong to stop employees having ideas and adding work – the green bar at the side of the screen – and you have to do this before you lose too much money – the yellow bar.
To get a higher score you need ideas, but only good ones. At the start of each level you choose a genre for your game. If an idea is bad (or in a different genre and risky) then you lose score, if you have risky ideas (or good in a different genre) then there is a 50/50 chance it count as very good (effectively as 2 good ideas) or bad, and a good idea in your chosen genre increases your score.
The number next to an employee is their happiness, it increases for ideas let through and decreases if they are slapped. If happiness is below zero at the end of the level they leave.
