You know that saying, “When life hands you lemons, make lemonade“
Well, my week has been something like that. I was showing our Spirit Lake demo at a school and realized that it HAD NOT BEEN UPDATED IN THREE YEARS !! The demo was supposed to look like this:
… and instead, it still looked like this!
You might wonder how that happened. So did I.
It was, as the book said, a series of unfortunate events. We updated the actual game three times from the initial beta version. Each time, we focused on the game actually used in schools, for which people were paying us, instead of the free demo. Makes sense so far, right?
Each time, someone was supposed to update the demo version or test that the demo had been updated, but that person would leave the company or be assigned to multiple tasks and by the time the other tasks were done, the demo had been forgotten in the push to finish the next game.
As you can imagine, we had some “conversations” and some new procedures to insure this doesn’t happen again.
How our (let’s be honest) screw-up with the demo is helping students design software
Someone – okay, it’s me – often says that we compare our own first drafts with other people’s finished products. It’s easy to get discouraged when your efforts and making a game or a website look nothing like the games you play or sites you see on the web.
This semester, we are working with several schools in project-based learning where students participate on a software design team, testing games, filing bugs, suggesting enhancements and presenting their ideas to the team. Students are unclear on what their role could be, what type of suggestions they should make.
Our very old demo gives us a starting place as a before and after. Students can play the demo, which is quite short – half of one level – and see the types of improvements made. They can see that our initial efforts are pretty rough, but that a lot of small improvements add up to major differences. In the kickoff meeting for the game design, we’ll review the types of changes we made, not just in cosmetics, but in game play.
In the software design class we will be asking students to play both demos, then play all of our other games. The reason behind this is to get an idea of scope and audience. We want them to come in as part of a team that can really do something, not just throw out random ideas.
After they have played our existing games, they’ll pick one to work on a redesign for our next version.
We’ll create a couple of shared folders of Google docs for each design team in which they can add their notes, artwork, sound files, videos and anything else they want to suggest for the game. Once they have these suggestions and have discussed them within the school, we’ll meet with the team to revise their ideas into specific enhancements that can be put into our change management system. Our software developers and artists will meet with the students, in-person or over Google hangout to discuss their suggestions in more detail.
We are working with four schools this semester and we can take one more, so if you are interested in implementing a software design unit at your school, email firstname.lastname@example.org