DemoGirl Post Mortem

DemoGirl is a 2D platformer created by a team of 3 developers at SMU's Guildhall over the course of 8 weeks. The game employs a partially destructible environment, and a unique movement system in which players "bomb jump" by hurtling themselves off of the shockwaves of thrown bombs.

What Went Well

Open and Honest Communication

At Raptorsoft, we collectively agreed to be honest with each other. DemoGirl would be our first game, so we all had something to prove. When the first batch of playtests came in, we received negative reviews on our bomb-jumping mechanic. Player’s said it felt unnatural to throw bombs in the opposite direction of where they wanted to move.

One possible solution to this was adding a jump button, which automatically threw bombs at an optimal angle for the player. A Raptorsoft team member felt that such a jump button would take too much focus off of our core mechanic, while others felt that the increased accessibility would justify this lack of focus.

We ultimately decided to add a jump button because no matter how much we loved bomb-jumping, a jump button made the game playable. During disagreements like this, we would ask ourselves an important question: what result would be better for the game? By starting discussion from this point, we could all find common ground to discuss solutions as they pertained to the game (rather than our egos). As a result, Raptorsoft continued to choose and implement improvements to the game efficiently and without headache.

To Boldly Go Where No Clone Has Gone Before

One thing was certain from the start of development on DemoGirl: we wanted the game to be ours. While some other teams resigned themselves to clone an existing game, Raptorsoft chose to implement bomb-jumping, a mechanic we had never seen done in a 2D platformer.

Granted, this decision resulted in some additional development pressures that I’ll describe below, but it also empowered us. Every day in development was an exercise in discovery and exploration of our unique mechanic. From concept to RTM, we fearlessly established optimal bomb-explosion radii, detection angles for the Xbox controller, and jump heights that felt right.

We didn’t just emulate, we created—a distinction that both motivated and oriented our team toward a common goal.

Sometimes, a Dumb Fart Joke is All You Need

Over the course of development, our sense of fun and unabashed laughter often reenergized us for our next task, sprint, or milestone. For instance, level building can sometimes involve monotonous tasks, like replacing the box collider for every platform in the game one by one (true story). However, when your Programmer pulls up Goofy singing the Frozen soundtrack as background music, the ensuing laughter gets you through the hour.

Raptorsoft maintained a crucial sense of levity and humor that bolstered our team’s identity, and got us through the darker times. In our last days before RTM, we also had to produce a Kickstarter video for DemoGirl, in addition to finalizing the game. My immune system had long since left me, and the Raptorsoft team was run down. However, fatigue turned into humor for our Kickstarter, which included shots of us developing DemoGirl in our office’s bathroom stalls, and a Weekend at Bernie’s dance scene.

These jokes served as a common language for team member, and shared experience that strengthened our resolve.

What Went Wrong

Wearing Multiple Hats

When teams are short-handed, people have to fulfill multiple roles. While I was the Project Lead for DemoGirl, we also needed a dedicated Game/Level Designer. I enjoyed aspects of both roles, but doing both at once met I often could not accomplish either to the level of quality and professionalism I desired. Time spent polishing our levels meant less time for project planning. Conversely, more time spent documenting and communicating changes to the game meant less time for implementation.

Snowflakes Mean More Testing

As mentioned above, our mechanic was unlike anything we had seen before in a 2D platformer. While this motivated us and strengthened team identity, it also crippled the amount of useful feedback we could receive. Because bomb-jumping isnot a common video game trope, many players didn't know how to play or organize their thoughts from feedback. Furthermore, instead of polishing the game more with each iteration after playtesting, our limited playtest time was spent testing different bomb-jumping builds and controller configurations.

As much as we loved it, our unique mechanic consumed our playtesting time like a Hungry Hippo at a marble all-you-can-eat buffet. Had Raptorsoft merely put a twist on an existing 2D mechanic rather than create one whole-sale, we might have benefited from both from innovation and established references. 

Naming Conventions

Think of how a library organizes its books according to title, author, year of publication, and edition. Now imagine if some of the books had no author or no title, and if the people responsible for building the library just name each book they received as “Book 1”, “Book 2”, and so on… How long would it take you to find a book?

At Raptorsoft, we failed to establish a solid naming convention at the start of development, and fell into naming and categorizing assets on the fly. Our player avatar alone took on a new name with every iteration, ranging from "DG_player_sara01" to "DG_sara3". As a result, finding assets became a reoccurring time-sink.

What We Learned

There’s Always a Work Around

Sometimes during development, we ran into seemingly insurmountable obstacles. For example, while constructing floors in DemoGirl, we discovered that collision boxes in Unity can never be placed completely flush with each other. As a result, the player would randomly snag floor tiles as they ran, make our platformer unplayable. After consulting with other teams that had the same problem, we decided to create a custom-sized collider for each platform in the game. The solution was less efficient and elegant than what we desired, but it worked.

Agile can be Agile

When we began development on DemoGirl, we laboriously planned asset creation and implementation from our Proof of Concept Technology through Alpha. We created all of our tasks, and posted them according to each milestones’ Scrum board. While our Scrum boards were immensely helpful, by the time we got to Beta many of our tasks became more difficult to estimate.

As a result, we reduced the amount of time spent on projecting times for tasks, and instead created and recorded our tasks as we worked. We changed our process to better suit the current needs of the project, and it served us well.

Smaller Can Be Better

Raptorsoft was a team of three people, whereas our competitors had teams of four. While this disparity reduced our available man hours by a fourth, we surprisingly produced a comparable amount of content to the other two games. Because we had one less person, each member of Raptorsoft had complete control over his discipline. Because we had fewer channels of communication, less miscommunication occurred. By the end of development, the decision-making process between we three developers was both democratic and extremely efficient. Interested in playing DemoGirl or talking games with Jon? A download is coming soon here!