Games
News
Sponsored Links
Project hosting provided by:
Radius Engine
Development: The Grind (LD21)
2011-08-27T04:10Z
The Grind
Last weekend, I participated in Ludum Dare 21, a 48-hour game development competition. Here's what I came up with:
The Grind
The Grind is a simple game about escaping from work at a reasonable hour by avoiding responsibility.
The goal is to acquire as little work (as few "to-do's") as possible throughout your 9-5 workday. Wander around the cubicles and hide from the men in suits--if they're coming your way, that means they want to give you work!
Use the arrow keys to move, space to start, and escape to exit.
Gameplay video: http://www.youtube.com/watch?v=rKPY5R4reJY
Download the game here:
Post-Mortem
This was my first experience with Ludum Dare (really, accelerated game development in general) and it was certainly a learning experience. I went in with a goal to finish something (anything), and I certainly achieved that goal, but in the process I ended up having to cut the vast majority of gameplay features, graphics, and all sound effects. Next time around, I'm going to need to start working with a much simpler/narrower scope to avoid having to cut features until there's virtually nothing left.
In the end, though, I had a blast and can't wait to play through the other entries. Thanks to the Ludum Dare community for arranging this event!
Feedback
Most of the feedback I've received so far has been extremely helpful and actually more positive than I was expecting. The two most commonly-suggested improvements are 1) allow the player to "complete" their "to-do's" and 2) give the player a compelling reason to do more than just hide in a cubicle all day (while the current game is perhaps more realistic, staying in one spot is not very entertaining).
Interestingly, these were both concepts that were in my original design for The Grind but which were cut due to time constraints. My original vision was to have the player be able to complete tasks (to-do's) by running around between different areas or sitting in front of specific computers for some amount of time. Doing these tasks would allow you to get work done, but still put you at risk of being found by a supervisor and given even more work.
Additionally, my original plan was to allow the player to complete all of his/her tasks and then (sneakily) exit the office completely (for an early win).
If I have time, I'd like to implement both of these mechanics to see if I can bring together a genuinely fun game. If so, it would certainly be worth improving the graphics, adding more levels, etc. and releasing a more complete game.
Critique (originally posted here)
The Grind is a very shallow game, but it is entertaining to watch the player get hounded by many bosses at once. I enjoyed watching 3 different guys in suits all say "Have some work!" right as I turned a corner.
Obviously, the game could use more polish. There are no menus to speak of and the smart phone isn't really used very effectively (the original plan was to have various tasks show up on the phone--in the end, it's just your score). The graphics ended up being a strange mix of 2D overhead (for the walls) and 3/4 (for the characters); this was simply a function of running out of time to make the wall graphics look good from a 3/4 angle. Lastly, the lack of sound and music is regrettable, but these were last on my list of priorities by necessity.
Time Breakdown
- Planning: 1 hour
- Map design/editor: 6 hours
- General coding: 6 hours
- Graphics: 3 hours (including unused art)
- Testing and bug fixing: 3 hours
- Real life and sleep: 32 hours
Lessons Learned
A narrow scope leaves time for polishing. I came into the contest with a vague notion of how time-constrained I'd be, but I didn't truly appreciate the level of urgency until about 3/4 of the way through the contest. At the beginning, I tried to scope my project down to make it achievable, but honestly I brainstormed ideas I had no chance of implementing in time. This led to wasted time working on features that were later cut (e.g. smart phone text, nicer looking wall graphics).
Don't underestimate time needed to implement algorithms. I had a rough idea of how to implement simple collision detection/resolution and line of sight detection, but I really underestimated how much time it would take to implement something acceptable. My first few attempts at collision resolution could lead to the player getting "stuck" and it was so frustrating that I had to keep iterating until I found something that "just worked." On the plus side, I managed to come up with a simple line-of-sight algorithm late at night that works very well (set "debug = true" in the main script file to watch it in action).