A fast-paced platformer set in a dream world of imaginary friends and cartoonish monsters, In Dream emphasizes non-aggressive gameplay, forcing the player to reimagine methods of navigation, conflict, and defense.  

What Went Right

Open and Assertive Communication

During the process of creating In Dream our team maintained open and assertive communication. Assertive communication being defined as speaking neither passively nor aggressively, while expressing your opinions in ways that others can understand and respect. Having assertive communication permitted the team to address ideas or differences head on, allowing us to master any conflict that arose. This turned invaluable when features and mechanics were up for debate.

Scope

The initial planning of In Dream kept the game in scope. Looking back at previous works we realized the extent of the time requirements and engine capabilities. We wanted to focus on only a few mechanics, jump, double jump, and dash. Having these mechanics as our primary focus during pre-production allowed us to remain in scope for the project.

Playtesting Feedback

Having playtester give us feedback during the development was invaluable. After each playtest we held meetings to discuss if the information should be implemented into the game. We took this information seriously and kept us from getting to close to the game to see what was wrong. Our communication skills definitely came into play during the playtesting reviews. After each change we had outside people play our game. We realized that even the smallest things that seemed obvious to us could become a tiring situation for our players.

What Went Wrong

Low Skill Variety of Testers

We were thankful for all of the playtesters that we got. In the beginning it was mainly our friends that played our game. Unfortunately our friends are all really good video game players. During a milestone demo we soon realized our mistake. The person playing our demo died several times in the tutorial level and gave up. It was an awkward moment, and a hard lesson. We immediately set out to get a larger skill variety in our playtesters.

Short Pre-Production

During the development time we were restricted by how long we could take on pre-production due to the imposed class schedules. Our focus on a few mechanics kept us in scope, but the game felt like it needed additional mechanics to spice it up. Additionally, having the short pre-production didn’t give us enough time to iterate on our mechanics. It wasn’t until we were well into our development that we started to really come up with unique mechanics that complimented the existing ones.

Engine Limitations

For development we used the schools proprietary engine GuideED1.3.1. We contacted people with prior experience with the engine. Feeling that we had a good idea of what to expect, we proceeded with our development plan. The team wanted to add sounds for a variety of aspects of the game. Once the sounds were being implemented we ran into memory issues. After trying to remedy the problem with changing the size of the music we ended up having to cut numerous sounds.

What We Learned

How to translate theory to reality

The team was a fresh batch of faces ready to dive into video game development. Before the project started the team was going through two months of game development classes. During this time they were going over definitions and industry expectations. This was finally a great opportunity to take what they had been learning and put it to use. Some of the theories were really best learned by doing and experiencing them first hand.

How to Filter Feedback

We had great playtesters throughout development. However, some of the feedback wasn’t good or it was too good. It is a unique problem to figure out for the first time experiencing it. The bad feedback was easy enough to filter to the side and move on. The really great feedback was harder. These were the ideas that required us to take some serious time on. We had to keep our scope in mind and what was possible based off of our backlogs.

Finding the Fun Early

Our focus on our mechanic was easy because it was fun early on. Having the fun figured out early allowed us to focus our efforts on other aspects of the development, like sound. We were not the only group developing a game and could see others struggling to make sure their game was fun.  This made it more obvious of the importance of a good pre-production and finding that special something to focus on.