Summary

• 2D side-scrolling puzzle game
• Main mechanics rotate around a character with a dandelion on its head
• The more seeds the dandelion loses, the older the character becomes
• Different abilities at different ages
• Combine abilities to solve environmental puzzles

Personal Highlights

• Very difficult project
• Learned the hard way about how difficul it can be to work with graphics programming when there’s no debug tools available
• Learned about the pitfalls of uninitialized memory values
• Learned to animate objects on screen using sprite sheets

Video

No video available for this project; files have been lost

Project Description

Dandelion was a very hard project for me. Looking back on it, I understand why my team and I were so overwhelmed and why we should have approached things differently. We were overly optimistic about our abilities and the time it takes to develop things. DigiPen is also a very demanding university, with a very wide set of topics covered in very little time. Deciding to develop an ambitious game as a third serious game project, with a wholly custom engine, having never worked with modern OpenGL (or any kind of graphics API for that matter), having barely touched on Visual Studio, and not really grasping what building a C++ code project entails, it was bound to be extremely challenging.

The premise of the game is about a small mouse-like woodland creature that is attempting some kind of pilgrimage. The creature has a dandelion flower on its head, and when seeds get blown off, it ages. The creature has three age states: child, adult, and elder. As a child, it can crawl into smaller spaces, and it can move quickly. As an adult, it’s able to jump higher and push and pull boxes. As an elder, it is able to spawn plants from fertile soil that can act as platforms and ladders. The player has to get past the obstacles in a level taking into account the different states’ abilities and what they can do to either make the creature younger or older. The woodland environemnt lent itself to highly detailed environments with very nice hand drawn art. Unfortunately, it also caused some of the problems we ran into.

Because we wanted more naturalistic environments, we tried to make levels by having artists paint the levels and us overlay the collision data on top with an editor. To be able to have slopes and uneven surfaces, we implemented oriented binding boxes, but didn’t quite nail down the collision restitution. The editor was also unstable, because we didn’t understand how to sync separate C# and C++ threads at the time. The mistake which caused us the most hardship, though, was uninitialized memory. There were a series of graphical bugs and weird behavior that didn’t seem to have a pattern. When I looked back some time after, I realized a lot of it was down to variables not being initialized correctly, so the values that they received were random when running outside of the debug environment. These days, I always opt for initializing to 0 or whatever other default value that makes sense. Learning from mistakes isn’t always the prettiest or the most fun of experiences, but it is the kind of mistake I am glad I made as a student and no longer make as a veteran programmer.