I’m Steve. The programmer, designer and musician on MOODFOOD.

MOODFOOD is a little game we made for Ludum Dare 42! This is the first time I’ve taken part in Ludum Dare and since we’ve been getting some really nice feedback from other developers I thought I’d write a post about it.

The theme for LD42 was “Running out of space”. Once we found out the theme, myself and the other guys who worked on MOODFOOD had about an hour or so of chatting about different ideas.

The most important thing for us was to incorporate the theme in such a way that the core gameplay loop was affected - and hopefully strengthened by it. I’ve been thinking for a long time that I wanted to make a procedurally generated doom-like game. Toying with the idea of playing a doom-like game with a mechanic in place that “removes space” from the playing field, we eventually came to the idea of an area shooter where crushing blocks would remove space steadily from the play space. Essentially the goal of the player would be to just survive as long as possible with endless and increasing waves of enemy difficulty.

The most important thing for me is that the game plays well and feels fun, and so heading into the programming that was my ultimate goal for this project. I set time aside from programming to just play the game and balance it as much as possible to create a good gameplay loop. Obviously this is where time allowed since there is such a huge time constraint during Ludum Dare.

We focused entirely on implementing the elements that would allow us to start tuning the gameplay as quickly as possible, while trying to maintain a data-driven approach.

From a programming standpoint, I made heavy use of the singleton manager pattern for this project. This is where you essentially have GameObjects that have a “Manager” script on them. This script is a singleton (only one per scene) that is globally accessible via a static field. An example of this might be the “WorldGenerator” singleton which was entirely responsible for generating the game world. It would instantiate (and keep a set of references to) all of the tiles in the world and their containing state. This WorldGenerator object was also in charge of managing and mutating the state of all of the tiles (such as when they become “dangerous” i.e. when the crusher is about to drop onto that tile). This is similar to the Entity Component System pattern, but since Unity doesn’t play well with ECS (collision detection on components for example) it has to be some strange mix of the standard Unity pattern and the Entity Component System pattern.

From a design point of view, there have been quite a few comments about where the game could go and gripes with the gameplay. I completely agree with the issues that people have risen with the movement speed. Ideally the movement speed would’ve been higher but I only made this realisation later into development. Further to this, all of the balancing I’d done thus far would have to be reassessed and adjusted to match the new player move speed (for example, the speed of the cyber spyder movement would need to be increased, and jump rate and speed also). At the time it was too late into the jam to realistically be able to adjust the speeds even though I’d wanted to. Another gripe that people bring up is the impact of the shotgun feeling weak. Originally we wanted to have multiple weapons in the game with different styles of play but this became too much work to support. I agree that the shotgun doesn’t feel particularly impactful and thought about ways I could “juice” it like shaking the screen, adding tracers and a better ricochet particle effect. This could have also been improved by knocking back enemies.

People also mentioned enemies spawning behind them. I knew this sucked but I couldn’t think of a decent solution that I could implement in the time constraints provided. Obviously, nobody likes enemies spawning right on top of them. Currently the spawning algorithm just looks for a random “free” tile (i.e. a tile that hasn’t had its crusher dropped on it) and then spawns there.

Overall, I am extremely happy with the feedback we’ve received from MOODFOOD. Almost all the issues that people have risen with the game I completely agree with. If we continue the project in the future then I’ll address them, but in all likelihood I’ll end up moving onto what MOODFOOD is supposed to be!

Thank you to everybody who played and left feedback. I’ve never worked on a project that’s received as much feedback as this and it’s really inspired me to focus more on developing interesting and unique projects.

If anyone would like to know anything about the game, then just ask and I’ll be more than happy to answer.