Design in the Box

Today we got a new team and a new assignment. This time, we’re supposed to make a serious game using Unity. Like last time, I am the only producer with three engineers and two artists (one of whom is a technical artist).

The idea we came up with that we all seem pretty excited about and dedicated to is a game that teaches non-programmer high school students the concepts of debugging a program. To do that, players will help a band who’s instruments are coming from the factory totally messed up. Players will look at the instructions the factory is using for the instruments, find where it’s not working, and fix it so that the factory starts making awesome instruments for the awesome band.

This is actually the strongest concept coming out of the gate yet for me, I think. I feel like everyone is behind this one even more than my first two prototypes and as long as we stay flexible and work hard we should have a pretty solid prototype come four weeks.

One reason for this success is definitely the design box session we had. Roger taught us today how the design box works, writing the technology, audience, aesthetics, and problem/mechanic then pitching only ideas that satisfy all those restraints. It went really well in our team for it being our first time trying it out. Here’s the results:

DesignBoxSmall

It definitely helped us to understand we were targeting high school students and we knew we wanted to appeal equally to boys and girls, especially since coding is still so male-dominant and we don’t want to reinforce that. It also helped us a lot to figure out how we wanted the user to feel–challenged, but empowered and smart when they succeed, included, accepted, and smart. I think if we can just keep this work we did on the design box in mind (part of my job as the producer, for sure), it’ll guide us to a much better game than we would have had otherwise.

Another One Gone

Well, Entropy is done! For now! We did our final pitch today. Here’s a for-some-reason-terrible-quality video of gameplay from the final (for now) product:

And here’s a look at the beautiful team that made it:

TeamTronSmall

After our pitch, we did a postmortem where we talked about everything that went well and everything we could’ve done better. Here’s our timeline of events (in practically unreadable handwriting–mine):

EntropyPostMortemSmall

The main points we came out with to improve our next prototypes were the following:

-Stay on task in meetings–don’t just turn every meeting into a brainstorming design session.
-Don’t be afraid to give feedback and ask for changes–even if they don’t all get done, they’ll help improve the game as everyone communicates more.
-Constant communication between all departments is key.
-Make sure you play to your team’s strengths, and make sure everyone always has something to do that they know how to do.

Overall, I really enjoyed this project and this team was really easy to work with. I think we made a great game together. The reason I kept saying it was done “for now” was because I hope to keep working with some of the team to change a few things and put it up for people to play somewhere. I’d love to share this game around to my family. We’ll see what we can do.

Wrapping Up Entropy

So it looks like this prototype is coming in for a fairly smooth landing. Everyone’s been working hard and we’re going to wrap things up nicely in time for the final pitches on Thursday.

Our game is now called Entropy. We now have a destroying planet, enemy patterns, difficulty levels that ramp up as you play, gun art, and displayed quotes. Take a look at a couple screenshots below:

EntropyScreen1

 

EntropyScreen2

I’ve had a lot of fun with this game, and I’m having a hard time distinguishing now between when I’m testing and when I’m just playing the game because it’s fun. I think that’s a good sign.