Fixed a couple of bugs in my Jam submission Consumption, one potentially preventing the inventory from being opened, the other preventing the world from ending. If you tried my game before and had either of these issues, they are now fixed. Please try again and rate my game.

I’m actually very proud of Frenzy Inc, the game my team and I made for this jam. It was my first time entering with a team, and my other team members first game jam. I’ve been working with them on games for a while, but the time-limited nature of a jam was new to them. We made a game that we’re all proud of, and thats really the most important thing about the jam. We have also got some excellent comments and useful feedback on our games page, which give us a warm fuzzy feeling and help to make the game better.

What went right

• Time and resource management. I was the only one on the team able to dedicate a whole 72 hours to this game. But we were able to plan and work around this to use the team members whenever they were available. And I still managed to get a total of 18 hours of sleep over the weekend, so overall a win.
• Visual Style. I’m a programmer, but I ended up doing all the 3d modelling on this one since I was the only one on the team with any experience doing it. I’m happy with how the game looks, even if it is very simplistic.
• AI. This was really my first time writing a proper AI for the player to work against. I learned a lot from the process, but I think the key part the the AI for Frenzy Inc is how they behave when not in combat. You can actually just stand around and watch the AI for a while and see how they behave, and I spent a fair amount of dev time doing just that.
• Small level. When you limit time, you have to limit some aspect of your game. We decided (reluctantly) that the best thing to cut back on here is size of the level. Having a smaller level enabled us to do a much higher level of detail on the level we did have, and devote more time to other features.

What went wrong

• Lack of warm-up. My team is largely used to working within pre-existing frameworks, so we spent a fair amount of the first 12 hours spinning our wheels trying to get back into working in plain Unity. We got there, but if we had spent that time before the jam less time would have been wasted.
• Lack of gameplay testing. Because we were all working remotely, putting together all the pieces to make our game feel complete didn’t really happen until the last few hours. This meant we really didn’t know how the game would be played to fix a few things, such as a few strategies which are far too effective, which really isn’t good for a high-score based game.

We’re working on fixing the problems with the game and adding a few features we wished we could have added for the jam for a post-compo version, so if you liked our game stay tuned for that.

You can play Frenzy Inc here: http://ludumdare.com/compo/ludum-dare-32/?action=preview&uid=22124

This was my third Ludum Dare, and I think it went the best so far. It was my first time ever trying to work with Unity’s 2D tools, but they work pretty much the same as the 3D so it was much easier than I had expected to learn. It was also my first time building a game from the ground up to run in a browser, which if anything removes a task, since I can control what sizes the game is played at.

If you’re interesting in checking out Rubble, it’s here

What went well

• Idea – I chose a simple idea, and because of that I was able to have the core mechanics and a few levels implemented before the end of the first day. Simple platforming mechanics are relatively easy to implement using Unity
• Time Management – I did a pretty good job of making myself stick to a schedule. I told myself that the first day would be all code, with maybe some art, and the second all level design. I stuck to this pretty well, but of course I had a few more ideas during the second day that I couldn’t not implement.
• Rubble – I’m really happy with how the rubble mechanics look and work, and how the rubble interacts with other objects.
• Performance – Considering on some levels I have upwards of 100 pieces of rubble on the screen at any one time, I’m quite happy with how Unity and my own code worked to keep the load relatively light, which is important for deploying a browser game.
• Brainstorming – As soon as I saw the final 20 themes, I started jotting down simple ideas for almost all of them. This meant I already had the basic idea for my game before I had to start really designing when the theme was announced.

What went less well

• Level Design – In hindsight, I think it would have been more interesting to use the rubble so that the player moved ‘down’ the tower, and the rubble falls on top of the level. This would have allowed for the rubble to have been a much more interesting part of the game, and not just constantly getting used as a ‘floor’, which made all the work I did on the rubble seem somewhat pointless
• Time Management – I stuck too rigidly to my schedule, which meant I ended up wasting time implementing features like trophies and additional obstacles, instead of making more interesting content, since I still had time left at the end of the first day.
• Sleep! – I ended up not getting enough sleep, and so burnt out with a few hours left that I could have used to make a few more interesting levels. I just added a simple end screen, called it done, and submitted with hours left before the deadline; because I was too tired to think of any more levels.

Our team is just over halfway through actual working time. And it is not looking too bad. (stand in character and textures until we get the actual characters from the artists)

This is the first screenshot of my team’s project for the jam. Going on 6 hours of work, and it’s looking good. Playing… ok. Thats the next step.