Currently viewing the category: "Photos"

In the theme park industry, soft opening is generally to detect technical issues that might cause problems from having a large volume of guests when they ride the attractions. Therefore soft opening prevent attractions from operating inefficiently in grand opening.

However, In CMU-ETC, soft opening is the time to show off our final works to people at EA. It usually happens two weeks before final presentation. On Nov 28th, we set up our work in an open space to demonstrate our projects. We shared ideas, got some feedback from the audience and mingled with them casually for three hours.

Bejorn, the producer of Xenon team, explained their project in front of people. The project was about exploring the possibilities technology will provide us in 10 to 20 years and made a short film.

Barreleye team had some technical issues in the beginning. There were a lot of latency because there were noise in the wireless network between the TV and mobile phones. While they were fixing the problem, the team played the game trailer on TV. After about one hour, the awesome programmers finally fixed the problem, and it worked!


West Turn presented a brilliant game to the audience. “Shake” the ipod to win the game!!

This fall semester, the soft opening was a little more quiet than previous years, but we learned how to setup countermeasure and demonstrate our work. In addition, sharing our work and having fun with people is always great!

And.. Team Photo  :)

 


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


Hello from BarrelEye! We’ve had a wildly busy week on Torch as we push toward November 20th, when we will turn our game over to our client for evaluation. The game is definitely coming together, and we are now pushing content in as fast as we can and trying to fix any bugs that hurt the player experience.

Our week started with a playtest, as members of our client’s team visited our workspace to try the game in its current state. We still find ourselves missing some of the important sounds and animations that communicate to the player, so we had some comments that combat was confusing, or people didn’t notice the boss’ HP bar. The feedback is always helpful because it tells us what sort of feedback players are expecting, and we can work on those elements first in the limited time we have left. Not all of our feedback was negative though – the client expressed pleasant surprise at how far we’ve come since we last demoed the game to them at halves.

Some of the key feedback we received came from Rich Hilleman, Chief Creative Officer at EA. He suggested that we swap out the coins in the game for actual arrows pointing players in the right direction. Because we were using the coins for indirect control but they had no other obvious effect on gameplay, they were confusing to players. With the arrows we are using direct control and removing the confusion. We’ve implemented that change and are working on several others.

In addition to small changes like that, much of our week was consumed either adding character animations to the game or fighting with the technology! At this point our artists have created lots of content but the programmers only have so much time to put it into the game. We’ve done what we can to speed this process up, even writing a tool to simplify the import.

The new art goes hand-in-hand with some our technical issues though, as we have started hitting the video memory limits on the TV. Our programmers spent considerable time adjusting our code to manage resources more efficiently, and make sure we only load the images that we need at any one time. This hasn’t been easy, since by design the TV represents the “world map” view of our game, and shows lots of different characters at once – we’ve had to downscale some art to compensate.

Finally, we’re putting together a whole cutscene system to allow us to script events that communicate more effectively to the player. This is a work in progress, and most of our cutscenes will have to be finished this weekend!

The team is ready for crunch time to be over, but we have a busy weekend ahead of us before we get to leave for Thanksgiving break. After that, we’re ready to get back to a regular pace. Thanks for sticking with us through this process – Torch is turning into an impressive game, and we can’t wait to show it again!

 

 NEWSLETTER #12  PDF FORMAT – DOWNLOAD