What Worked
- Time bounding the whole project
- Roughing out one chunk of game play at a time, stitching roughed segments together, and only doing polish at the end
- Pushing input capture into a single object and reading its state
- Tiny amount of issue tracking (via trello) for a tiny project
What I Got Wrong
So, the biggest issue was in how I decided to draw things. I just made gobs and gobs of mistakes in the sprite work, and that made it impossible to have good animations overall. Despite how simple they are, I’m pretty happy with the throwing animation and the thrown ball animation. The real problem is in the people, the dunking tank, and the drinking animation.
The above doll is the basic player / rest representation for Drunk Tank . The problem is that it’s the whole character in a single image, and that makes animating it from within the code a giant pain. If I’d split out the head, the arms, and the legs of the body into separate sprites, the following would have been possible rather than prohibitively expensive:
- Walking around
- Idle animations while seated
- Drawing the character select portraits on playing characters rather than a string display of “Now Throwing / Drinking”
I made this mistake again and again in the project. You can see it in the seated / hammered sprites where I put the chair in the image with them, rather than compositing the things in the object itself:
I made it even worse in the dunk tank and drinking animation. There, I did an entire sequence of images of the character falling into the beer, then the tankard getting low as you crossed certain thresholds in the drinking button mashing input. In each case, those images were put together by hand, rather than letting the object build them based on how much time had passed or how many times the player had mashed the button.
Part of the mistake had to do with not knowing the API intimately. Being able to draw a sprite with a color overlay to say, show that they’re dunked in a clear glass of beer, was a thing I knew I could do in the image editor but didn’t know I could do in code. Moving the sprite around in each of the frames rather than compositing it was just laziness supported by the first decision made out of ignorance. Then, by the time the month was over, I didn’t have the time, or really the inclination, to go back and change all of the animations for the game.
Going Forward
- Do as little animating by hand as possible
- Really think hard about splitting sprites up, especially faces and torsos
- Read the docs
- Use time bounding more frequently
- Least Playable Unit is a good starting point for game projects