Our fifteenth week is all preparation for the end of the semester – getting ready for our final presentation, our final demo, the hand-off to the OCCO, submission to competitions and more. And so, we’d like this our final newsletter to be a reflection on a few lessons we’ve learned over the past fifteen weeks, and what we will take forward to our future projects.

1. Schedule aggressively
We were especially fortunate this semester because on day one our client established this pattern for us. They told us the game had to be feature-complete by halves, which sounded like an impossible goal to us at the time. But we got right to work, and it’s amazing how much time you don’t waste when you’re under a tight deadline from day one. We responded by setting equally tough deadlines for ourselves during the semester, and as a result the team surprised ourselves with how productive we could be.

2. Assign roles
One reason our team worked well together is that we assigned clear, distinct roles to each team member. Not just one role per member either (that’s insane on a small project) but each person had at least six titles giving them authority and responsibility for those parts of the project. Not only did this help us know who to look at when a question or task arose, it also helped us not overlook any part of the project – it’s hard to say “oh, someone else will do that” when it’s only in your job title. Ironically, the one role we forgot to assign was sound designer, and it had to be picked up by two people late in the semester.

3. Designing for the unknown is hard
In week two when we pitched three game ideas to our client, we still had only the roughest idea of what the TV would be able to do. We knew it could handle 2D graphics, and had seen only a very simple 3D demo running on it. We had no idea what kind of trouble we would encounter with the GL layer, or how harsh the video memory limits would be. Knowing what we know now about the hardware, the team agrees we would have designed a totally different game.

4. Two is too many
This isn’t a hard-and-fast rule. In fact, we’re quite pleased with what we were able to do with the two different platforms working together. But having two platforms introduced a number of challenges that would rarely come up in a single-platform project. For instance, we didn’t anticipate what a mess we were getting into when we used Unity Asset Server to manage our Unity source and Perforce to manage the TV source. Two version control systems is definitely too many! Another challenge was building the same game world in two different game engines, then trying to keep them completely synchronized over the network. This introduced a lot of headaches we could have avoided with a different game design. If you’re working on two platforms, look out for these pitfalls!

5. Don’t save polish until later
We panicked a little during our first week when we learned that we were supposed to be feature-complete by halves. We agreed as a team that the first half of our semester would be devoted to building gameplay and playtesting, and that the second half could be implementing content, polish, and other small changes we needed at the time. We learned that some polish is absolutely critical to game design – it’s the details that communicate important information to the player, and make the game playable and enjoyable for them. We should have been polishing the game as we built. Our playtests might have been more useful that way.

Thanks for following our project this semester! We hope you’ve enjoyed reading about our game half as much as we’ve enjoyed building it! From all of us here at BarrelEye, have a great holiday and keep your ears open, since we’ll be entering some competitions in the near future. Thank you!

 NEWSLETTER #15  PDF FORMAT – DOWNLOAD

The highlight of week 14 of the BarrelEye project was soft open. We set up Torch in the atrium of Electronic Arts and invited everyone who walked by to stop and try the game.

Actually, soft open was punctuated by some technical issues for us. In the dense wireless environment of EA’s atrium we discovered that Torch might have a little trouble of a show floor. In spite of having a dedicated wireless router we were having very high latency on the game. We tried adjusting settings for a while, but eventually we had to bring down a laptop to use in place of the server phone.

After that things picked up, and we had a several people try the game. The response was great! People seem to recognize that Torch is a different experience, not just because it’s running directly on the TV but because it changes the way they use a phone to play a game. Our goals of having a short experience that’s easy to pick up really worked out, as our guests at soft open had no problem playing through the game and facing the boss at the end.

Unfortunately, we got some bad news this week when we were informed that Torch will not be shown at CES. In order to be shown, the game had to be approved by an exhibitor other than EA whose booth would host the game. After trying our demo, they decided against showing the game.

We are disappointed, and so is our client, but it’s not all bad news – now we are free to submit Torch to other gaming competitions. We are currently searching for places we can submit Torch to give it the public attention we think it deserves.

The next couple of weeks will be devoted to some final cleanup on Torch, figuring out what we need to do to make it competition-ready, and preparing for our final presentation. See you next week!

 NEWSLETTER #14  PDF FORMAT – DOWNLOAD