Development Blog

Nexus: Introduction

Sadly, it has been over a month since my last post. While I would like to be writing posts at a more frequent pace, it has proved quite challenging. Capstone work began almost immediately and second semester has just begun. I have been caught up in the rush of work and I have finally found some time to catch up on the blog.

Last semester, ten Producers pitched game ideas and each student ranked the games from 1 to 10. The faculty tallied up the votes and for the first time they allowed five games through.

Typically for Capstone they only allow four, but the voting was so close this year that they pushed five games through. Those games are Nexus, Organ Grinder, Erado, Dead West, and Scarfell.

Faculty then split up the entire cohort and placed us on the five games. They do their best to try and make sure you get on a game that you ranked highly on your list, but sometimes that is not always possible. But for the most part I believe everyone was pleased with where they were placed. With that said, I was placed on Nexus.

Nexus is a 3D Action/Adventure game set in a mysterious city underneath a legendary temple. Using satellite imagery, a source of very high energy was discovered beneath the temple. An archaeological team was sent to explore and find the source of the energy signature.

What they discovered was an entire underground city. Upon exploration of the hidden city, they discovered something they would have never expected. After a mysterious last recording, contact was lost with the first team.

In Nexus, you play as Chris Reynolds, the head of a second archaeological team. The team’s objective is to find out what happened to the first team and acquire the source of the power. The stakes are higher for Chris as his father was on the original team. With the status of his father unknown, Chris heads steadfast into the city to find his father and obtain the energy.

Little did Chris know that he was entering not just an underground city, but something that was a bit more alien. After falling through an unexpected hole, Chris is separated from the remainder of his team and finds himself in a separate section of the city. Pushing forward, Chris stumbles upon the energy source. Unexpectedly, the source reacts to him and Chris absorbs the energy.

Momentarily taken aback from this source, Chris discovers that he now has unusual powers that allow him to manipulate physics and matter. The powers are a conservation of mass and energy. They allow Chris to not only take mass from objects, but also release his own mass onto objects.

While still learning how to control these powers, Chris treks further into the underground city. Traps, puzzles, animals and other forces challenge him at every corner. He must use his powers to find his father and escape the underground city.

With that introduction to Nexus, I will stop here. I have a lot more to discuss about what we have been doing over the last month. However, to keep things a bit more organized, I am actually going to create a new separate post for that discussion.  Look for the next post titled Nexus: Status Update Week 1.

Castle Adventure Posted

As part of the Scripting class for Producers in the first semester, for the final assignment, we had to make a text-based adventure in Python.

For my text-based adventure, I created a game called Castle Adventure. In Castle Adventure, you are trapped in the Evil Wizard’s Castle and he is challenging you to a test! You must survive all 16 rooms of his castle and collect 100 Wizard Coins. Once you collect 100 of his Wizard coins, and visit each of the rooms, all without dying, you are set free.

I have posted Castle Adventure to the blog. Please click on the link below to go the game page where you can try out the game!

Play Castle Adventure!

Sprites vs. Spriggans – Gameplay Video

I finally got around to making a gameplay video for Sprites vs. Spriggans, the iOS game developed back in Round 3 of RPP – the emergent gameplay round.

I have posted the video to the blog. Please click on the link below to go the game page where you can view the video.

Sprites vs. Spriggans was created by a team of five in two weeks and was built for 480 x 320 resolution iDevices.

View Gameplay video for Sprites vs. Spriggans

Reflections of a Semester

Wow. Roughly four months have come and gone and semester one is complete. It’s hard to imagine how far we’ve all come. It feels like yesterday that we just started. We’ve been through 5 rounds of RPP, pitched game ideas, and completed dozens of assignments. We’ve also worked crazy hours (last week I think the programmers might have gotten 8 hours of sleep the ENTIRE week). And finally, we now have our Capstone games for next semester and we are already hitting the ground running.

It’s been a month since my last post and while typically I have been updating everyone about RPP, doing post-mortems, and writing super detailed posts, I am going to forgo those in lieu of more retrospection.

Looking back on the first semester, I can say with certainty that FIEA can and will exceed even your highest expectations. FIEA quite frankly might be the coolest place on the planet. Let me give you a few direct examples.

Over the past few weeks, all of us (faculty and staff included) have been dealing with a unique challenge. Gamebryo, our previously licensed Capstone game engine (the Engine used for all of the Capstone games last Cohort) is closing for business (well its parent company Emergent is at least). This put the faculty in an awkward position as Capstone was coming up and we had no engine.

We as a Cohort of course learned of this and we started researching our own options. A few weeks went by and we had no answers (from faculty or from any of the companies we contacted) So Rick, being the ever awesome pulling force, yelled at us Producers for being stupid and lazy. He told us to solve the problem. He wanted us to stop thinking like students and start thinking like developers. This concept is hard to grasp sometimes (because, well, we are students) but he wanted us to get that stigma of our heads. To paraphrase: “You do developer’s work, you might as well call yourself developers.” He wanted us to solve the engine problem.

What transcended after that conversation in class was quite frankly the best thing I’ve EVER seen in an academic setting. Literally DURING class, we got the entire faculty in the same room and talked about engines. For two hours the students had a REAL discussion with faculty on what we could do to solve this problem. I honestly watched and participated in amazement. Nowhere else could you have gotten this experience. What other grad program lets you set up impromptu “town hall meetings” and solve MAJOR issues related to the program.

After that conversation, the wheels turned and we started getting all kind of engines situated. We now have at least six solid options to choose from for our Capstone games including: Source, Vision (by Trinigy), CryENGINE (with some contractual constraints), UDK, C4, Unity Pro, and XNA. This seriously was the coolest thing ever.

I know that was a long example, but I promise you that you won’t find that anywhere else. I mean we stood toe-to-toe with people who had been in the industry for dozens of years and we helped them shape these decisions, or at least had a chance to have our opinions heard.  And the best part? That’s not even half of it. Do you like NBA Jam? Mark Turmell came in and talked to us. Like anything EA Tiburon? We had the General Manager of EA Tiburon, Philip Holt, come in and talk to us. Dan O’Leary, Co-Founder and President of n-Space? Check. Our speakers are Presidents and GMs of REAL gaming companies. That’s full of win of my friends.

FIEA is not just awesome because of all of that. It absolutely prepares you for the industry. We’ve been here four months and we’ve learned so much. We all know how much more prepared we already are and we are just getting started. Capstone will blow our minds I am sure. And it’s not just the hard skills you learn either. It’s the mindset FIEA instills in you early on.

A fellow Producer, Matt Bloise, wrote an awesome post about how your perception of the industry changes so drastically once you start FIEA. Rick tells you this the first day of class, and in your naivety, you’ll probably chuckle at this thought, thinking you know the industry. You don’t.

To reiterate what Matt said, if there is one thing you take away from the first semester it’s this very fact: making video games is a business. You think Barbie games are stupid? Think again. Don’t want to make them? Think again. They push a lot of units and secure jobs. Think Wii Sports Resort is stupid? Are you thinking: “I don’t want to make that!” Think again. According to the NPD Group, it sold 442,900 units in Sept 2009 (it came out July 26, 2009). Batman: Arkham Asylum (wicked awesome game) came out August 25, 2009 (for consoles) and sold 421,100 units combined on Xbox 360 and PS3 (and Wii Sports Resort had been sitting on the shelf for a month already!).

Rick has made this statement in class a few times that sums it up nicely: “if you want to make money, make a [expletive here] Barbie game.”  It sells, period. I certainly didn’t want to make a Barbie game prior to FIEA. One semester changed all of that.

FIEA changes more than just your perspective of the industry. In these few short months I can say that this place has changed my life. And I don’t just mean from a professional stand point. I have learned so much about myself in the past four months that I don’t have enough words to describe it. I’ve changed as a person, I really have. I have become more social, more open to new things and risks. I try different foods, and I go out to different places. I am even playing different games. I’ve met people from different cultures, backgrounds, and ages.  I have had conversations about stuff I’d never thought I’d discuss. HLSL and different shader support, diffuse maps, bump maps, normal maps, immersion, emergence, indirect control. You learn the lingo here, and FAST.  All of this is stuff I didn’t do before FIEA.

Oh I can go on and on (lol, and if you’ve read any of my prior posts, you know I usually do). One last thing I want to touch on is all of the cool software that comes with your laptops (yeah if I haven’t mentioned this before, you are assigned your own laptop) that you will learn to love. Perforce. Oh how we love thee. Say hi to Perforce. You will learn it and love it. It is THE de facto standard version control software used in the industry. What’s that you say? Yup you get to work with the REAL Perforce here at FIEA. When you go to your internship, bam you know Perforce already! More win. Maya, Zbrush, Motion Builder, Hansoft, Photoshop, Engines (UDK, Unity, etc), Mindjet Manager, doxygen, Outlook (seriously this seems stupid but most people have NO idea how to REALLY use Outlook). And I can go on and on.

Most of all, I am amazed at how fast it’s all going. The first Cohort 8 Portfolio Review date has come and gone. That means there are Cohort 8 members who should soon be receiving their acceptance notices. To those individuals, let me be the first to say welcome. There aren’t too many happier moments in my life than when I got accepted. And after coming here and spending the last four months, I have been completely reassured that I made the right decision.

Is the first semester easy? No. Not all. It was tough. I won’t sugar coat it. We lost a few people. But you won’t find a more exciting place to be. Seriously, if you are on the fence, apply. It cost me $45 (app fee and transcript) and some time to apply. I’ve never looked back. It was the smartest decision I’ve ever made.

Life at FIEA: The Nitty Gritty Details

Looking back at all of the posts I have written so far, I realized that I have mostly touched on just RPP. While certainly RPP does dominate the first semester, I have been neglecting a lot of the other things that take place at FIEA that are just as equally important.

First off, we are in the middle of RPP Round 4 and I can say that we are doing something unique and exciting. It is so exciting that I am actually not at liberty to discuss any of it (seriously, I can’t talk about it). As such, I think I will take this time to discuss some of the classwork everyone has been working on, and then I will talk about round 1 of Capstone Pitches that took place this week.

Before I discuss classwork, I have to mention that any FIEA student, regardless of track, can sit in on any of the classes. I occasionally attend both the Programming and Art classes. As a producer, it is good to sit in on the classes as it gives you an idea of what the programmers and artists are doing. It’s great for scheduling during RPP as you know what assignments they have to work on. Having sat in on many of the classes, I feel relatively comfortable discussing the assignments.

In terms of classwork, I am actually going to start with the programmers as I don’t believe anyone has touched on what they have been doing in class over the past few months. Obviously they are very essential for RPP, but they also have quite a bit of homework that can be quite challenging.

For roughly the first month and a half, the programmers spent a great deal of time coding in 68000 Assembly (using EASy68k, which is an Assembler and Simulator). Their first assignment was to create a sort method using Assembly. The programmers were left to their own devices to figure out which sort algorithm to use.

To keep the assignment interesting, Tom Carbone, the Technical Director at FIEA, made the assignment into a little contest. For the sorting assignment, the programmers were all given the same set of data to run through their Assembly program. The programmer who could perform the sort using the least number of clock cycles won a prize.  Tom has continued these little contests throughout the semester and it is definitely a cool incentive.

After the sort method, the programmers had to take a bitmap, read its data, and redraw it using Assembly. This assignment segued perfectly into the legendary assignment that is discussed and passed down from Cohort to Cohort: Pong. The programmers, during the height of RPP Round 2, were tasked with making a two-player version of Pong in Assembly. This was certainly challenging and it seems to be routinely the most difficult assignment of the first semester.

After Pong, the programmers began working and learning more about C. They did a few brief assignments in C (working in Microsoft Visual Studio). After those short assignments, they had to complete their final Assembly assignment which was a combination of Assembly and C. It required they create a binary file in C and then read it in using Assembly. Since then, the assignments have been solely C. They have worked on a bit stream conversion assignment and they are now currently working on a Boggle solver.

On top of all of this, the programmers have also had to take several tests as well. One test was on hex conversions, and the other was a coding test on Assembly. While the programmers certainly have had their hands full with the assignments, RPP, and tests over the last few months, the artists have been in the same boat as well.

The artists first started out by creating three concept sketches. They chose a game and were tasked with drawing concepts that matched the art style of the game. After that, the artists began dabbling in Maya. Their first Maya assignment was to model a character using one of the concepts they drew from the previous assignment. For the next few assignments they were required to tweak the model and even make a low poly version of the model as well.

Once the model was ready to go, they learned how to UV the model in Maya. Once it was UVed they had to texture the model. The assignments continued down the line all using the same model. After texturing it, they learned how to rig it. Then finally, they animated the model.

During the animation portion, the artists, and the entire Cohort, were able to sit in on two sessions that showed us how to use the Motion Capture studio here at FIEA. Needless to say, this was pretty cool as fellow Cohort members dressed up in the Mo-cap suits and a good time was had. After those sessions, the artists learned how to take the data from the Motion Capture sessions and import it into Motion Builder.

Eventually, the artists moved on to environments. They started out by making a piece of concept art for an environment, which they then had to make using Maya. After a few assignments with the environment, they were then asked to recreate it using the Unreal Development Kit. They are still in the process of completing that assignment at this time.

Meanwhile, they have also had a few Zbrush assignments as well. They have also begun their final projects which entails choosing a specialty. Each artist has to choose a particular specialization that they are interested in and then create a piece of artwork. It could be an environment, a character model, or even a rig/animation.

On top of these assignments, the artists have also had to do a lot of side drawing. Every Friday, they have Life Drawing where they complete human sketches. They also have to constantly keep up with a sketchbook and their portfolio.

Finally, even more than that, the artists can choose whether or not to participate in Tech Art. This is a non-required class that takes place twice a week that goes in-depth into Mel scripting in Maya. Those who do wish to participate do have assignments and final projects in that class as well.

Then there are the producers. We spend a lot of time in class talking about production concepts and game design. Early on, we discussed several ways on how to go about creating unique and cool game designs. As I have alluded to before, we have also conducted several brainstorming sessions. Typically, someone gets called up to the front and conducts a brainstorming session, either using everyone in attendance or just a small group of producers.

These brainstorming sessions vary in format. Sometimes it is a standard brainstorming session, while other times we deconstruct a game and then apply new fiction to those mechanics. We have also had two classes where we went up and pitched a game idea. One day we came in to class and had an unannounced test. Every time you go into class you never really know what to expect. It certainly keeps us on our toes and I think we wouldn’t have it any other way.

In terms of assignments, at least once a week (sometimes twice a week), producers are required to write a three to five page core mechanic document. With these documents, you lay out the ground work for a game design. The goal is to write about the core mechanic, or what it is the player spends 60% of the time doing in the game. The documents typically include a brief section for narrative and environments, but those are typically included to support the mechanics.

As a producer, get comfortable with these assignments as you will do a lot of them. We have written ten of these documents so far and each time there is a new flair. At first you will do one on whatever you want. After that, you start getting constraints. Create a game that has combat but no HP, or create a game about werewolves. Sometimes the document will focus on a particular genre, or maybe even a tone word. You will have to write one using an IP as well. Our last few ones in particular have been very guided. We were given the fiction, demographic, genre, and tone words and we had to create a game design using those criteria.

On top of those core mechanic documents, the producers eventually have to worry about Capstone pitches. As I mentioned earlier, this week was the first round of Capstone pitches. All producers must pitch a game to the class. Artists and programmers are also welcome to pitch Capstone game ideas, but they must have sat in on a majority of the Production classes. We had 22 pitches, 20 producer pitches, 1 programmer pitch, and 1 artist pitch.

For the first round, you have to make a short pitch (about five minutes) to the producers who then vote on them. Ten of the pitches make it to Round 2 for the big pitches in December. The pitch can be set up in any manner you like. It could be a video, you could have audience participation, or you could do an old fashion PowerPoint.

At the end of all 22 pitches, the producers got to rank them. Of these 22 pitches, the producers got to choose five to go onto the next round. Initially, Rick (the Production Director) was supposed to choose the other five. However, this year, since so many programmers and artists watched the round 1 pitches, he gave them two votes. As such, non-producers were able to choose two games. Then finally, Rick chose the last three.

The ten pitches have been chosen and they will now go onto the next round where they will have twenty minutes to pitch their idea to the entire cohort, faculty, and even industry pros. Of those ten, four will move on to be Capstone games next semester. The four are voted on by artists and programmers, with the faculty having veto power. Producers do not get a say in what four go through.

It certainly has been a hectic week. While my pitch did not make it through, I am very excited to see how the ten pitches will grow over the next month and I look forward to assisting those pitches in any way possible. Congratulations are order for all of the pitches that made it through!

Well, that is pretty much most of the first semester in a nutshell. I certainly am amazed at how fast it has gone. In a few short weeks it will be over and we will start work on Capstone games. In the meantime, I will continue to post updates. While I can’t discuss RPP Round 4, I will be able discuss Round 5 when it starts up next week. Thanks for reading!

Sprites vs. Spriggans Postmortem

Working with the iDevices was an awesome opportunity. We started this project on a high note as we were all excited to have the chance to work with the devices. They offer so many different and unique design decisions. Working with them was really a fantastic learning experience.

With that initial boost, the team had high expectations for Sprites vs. Spriggans. With the game, we wanted to create this over the top experience. We wanted funny destruction animations and goofy sounds. The game was to have fun gameplay and an overall theme that was just zany and whacky. With that said, the main focus of the project was to create game mechanics that would foster emergent gameplay.

In the end, we found ourselves disappointed. While we were certainly proud of the work we were able to accomplish, we all felt we ended up just short of our initial vision for the game. Even with the disappointment, there were many things we did right with this project. We just wish we had more time. But what team, on any project, does not wish they had just a little more time?

What Went Right

  1. Everything Art Related – The artwork was nothing short of pure magic. Everything thing that was created, when put on any of the devices, looked amazing. Everything seemed to just pop off the device. The art had great, vibrant colors, and it had a very awesome style that fit very well with the theme of the game. Also, the animations matched the theme and style very well. Both artists worked together extremely well and they were able to match styles almost perfectly. They were also able to create most of the artwork extremely fast. Sprites vs. Spriggans is a gorgeous looking game on any of the iDevices.

  2. Good Team Chemistry – As mentioned earlier, there was certainly a level of disappointment at the end of this project. However, we worked very well as a team throughout. We were always upbeat and maintained a good morale, even as the end came near and we knew we were going to come short of our original vision. Throughout the entire project everyone remained on the same page and communication was excellent. On top of that, everyone did their part and completed what was asked of them. We had a great time working together.

  3. Got the Idea Quickly – In the initial brainstorming session, we started out by tossing around a few ideas from the group. After we discussed a few options, we all settled on one idea very quickly. Everyone seemed to really like one particular idea. It was easy to see the potential and we just grabbed onto it and ran with it. Everyone was on board from the beginning. Less time was spent debating back and forth on ideas, and more time was spent on what we wanted to do with Sprites vs. Spriggans.

What Went Wrong

  1. Platform hurdles – While certainly the iDevices are awesome devices to work with, they can be impressively difficult to manage in a two week time period. From the initial set up, to adapting to the awkward objective-C, working with the device certainly comes with a pretty large ramp up time.

    Developing for any of the iDevices requires a Mac, which comes with its own set of issues. First, we had to get Mac Mini’s setup and we had to get all of the devices registered as developer devices. Just that basic setup took a solid two days. This was tough as we had to wait two days before we could dig into the code. The code itself then took almost another two more days for ramp up. So it was almost the fourth to fifth day of a 14 day project before we could really dig in and get anywhere with the device.

    In the end, this was our biggest bottleneck. The iDevices required a great deal of programming. While our programmer worked extremely hard, what we were trying to accomplish was very difficult for one person to handle given the short time period. The hardest part was that the objective-C was so difficult to pick up that the Producers struggled to help out at all. Perhaps correcting the next item on the “What Went Wrong” list would have alleviated some of our issues with the platform.

  2. Scope Issues – With the issues we were having with the platform, we should have reassessed early and often. We romanticized so much about the project when we should have revamped things to make sure we first got a core prototype working. We were all so excited about the project and we had all of this great artwork, sound effects, and ideas ready to go that we just kept hoping to get everything in. We should have instead assessed what was possible, accepted it, and cut things where appropriate.

  3. Not Able to Playtest – With the challenges we faced with the platform it was very difficult to ever playtest the game. It took a while to get things up on the screen to the point where we could try it out, get a feel for it, and iterate accordingly. With this lack of playtesting, it was really hard to figure out what needed to be tweaked or added/changed. Since we didn’t get a chance to play it very often, it was also quite difficult to conceptualize, especially when you consider it’s the iDevices. We had to deal with very unique constraints such as the touch based only controls, accelerometers, and the small screen sizes. Not having that ability to just load up the game and see how each of those elements worked made it that much more challenging.

  4. Cutting Art – Cutting anything is never easy. Loss aversion is a difficult beast to tackle as no one wants to throw anything away, especially something they spent a lot of time on. Sadly, while the art was absolutely tremendous, there was just so much of it that never made it into the game (especially animations). Perhaps this is connected to our struggles with scope and not cutting when we should have, but a lot of the art was done so fast and so well that the artists just kept on wanting to make more. Had we sat down and figured out what was feasibly going to make it in the game, we may have been able to cut back on how many assets the artists needed to create.

With Another Week

  1. All boulders & properties – This was the core for our emergent gameplay. In the final build, most of the boulder types and their properties were not fully implemented into the game as they were originally intended. With another week we certainly would have been able to fully flesh out all the boulder types and their unique abilities, as well as add the special properties to them.

  2. Trails and Destruction FX – Our vision for the damage to the village was epic. We wanted cool explosion effects and just overall funny, over the top destruction when it came to hitting the houses. However, we simply where not able to get even close to where we wanted in terms of house destruction. The animations and FX were in place, so with another week, we would have easily been able to make very cool destructive scenes.

  3. Tutorial – One of our original ideas was to create a clever tutorial that would briefly explain the somewhat complicated combinations for the boulders. We had a lot of this already planned out and the assets ready to be placed in the game. We just needed more time to implement it. Another week, and there would be a sweet tutorial in Sprites vs. Spriggans.

  4. Potential for App Store – With another week, we could get everything in and polish it up to make for a very awesome iDevice game. We still feel that the potential for this game to do well on the App Store is very high. With one more week, we may have been able to get it up there.

RPP Round 3 – Emergence

November is near and the adventure that is RPP continues. We are almost through round 3 and final presentations are just around the corner. It has been a busy two weeks for a lot of teams as everyone continues to tackle new engines and the new challenge for the round.

For round 3 we have to create a game that is emergent. Emergence is one of the more complicated concepts to explain. Emergence can be defined as giving the player tools or abilities that allow them to play the game in ways you could not have anticipated as a developer. It can be helpful to point out games that show emergence such as The Sims or even Chess.

The Sims is emergent because you can do a lot with the given tools. With the earlier versions, the developers probably never intended for users to build basements for their house (something that later became a feature in The Sims 3). On top of that, they probably didn’t expect players to lock Sims in a room and find out how long they could last without food, bathroom breaks, or sleep. Even the characters you create and the stories you can tell with your families is emergent.

Chess is another example. It has been around for hundreds of years but even today new strategies are formed. Although it has simple rules, the number of possible moves and strategies is staggering. The players can continually create something that was never expected.

Knowing the goal, we started another round. However, before we could begin, the entire cohort was required to move desks. This was an interesting afternoon as we all had to pack up our stuff and move around the cohort space. Moving desks is not an easy task as a lot of students have posters and swag all over the place.

The move is part of a research project, the details of which I will keep hidden as a precaution. But I can say that the move has been interesting as the entire cohort had to adapt to the new seating arrangements. It has been a good change as it has kept things fresh and has allowed us to sit with different people.

With everyone situated, my new team started our initial brainstorming session. After some discussion we came up with a quirky iDevice game called Sprites vs. Spriggans. We decided to develop for the screen resolution of 480 x 320. This would allow the game to be played on pretty much any generation iPad, iPhone or iPod Touch.

Sprites vs. Spriggans takes place in a fantasy world where a sleeping earth Golem named Formian houses a Sprite village on his back. The Sprites mine him for fairy dust and in return feed him delicious boulder meals. This harmony is broken one day when the Spriggans move their village up the hill close to Formian, who sits on top of the Majestic Mountain. The Spriggans want to colonize Formian and harvest the fairy dust for themselves. The angry Sprites demand action and call forth the power of Formian to launch boulders and destroy the Spriggan village. To aid Formian, the Sprites enchant the boulders.

In Sprites vs. Spriggans you get a certain number of boulders to use against the Spriggans. Your goal is to throw these boulders down the hill to destroy all of the houses found in the village. Using the iDevice’s accelerometers, you have to navigate the boulders past three different obstacle types (tree, rock, and Spriggan barricade) to reach the village and houses below.

At the beginning of the game, the player can use the touch screen to pan the playing field and study the path they can use to reach the houses. A boulder will be placed in the center of the starting area and once the player touches a boulder the accelerometers will activate and the player has to navigate the objects.

Before they release the boulder however, the player can change the boulders. Thanks to the Sprite’s enchanting powers, the player can change various properties of the boulder. This is where the emergence comes in.

The player can choose from three types of boulders and two boulder properties. There is the standard boulder, the hyperboulder and the multiboulder. The standard boulder has average speed, durability and ease of navigation. The hyperboulder has amazing speed and devastating power, but is really hard to navigate. Finally, the multiboulder is two standard boulders with the same power and speed, but with two boulders it is harder to navigate. There are also two properties to choose from. The player can apply fire or explosive tar to the boulder.

With these combinations, the player has a variety of unique possibilities and strategies. This helps drive the emergence. As mentioned earlier, there are three types of obstacles and each obstacle has different durability. A standard boulder can’t get through a rock, but a hyperboulder can destroy most anything. So depending on where the obstacles are placed, the player may have to destroy one to make it easier to reach the houses below. Or perhaps they can take a chance and try to maneuver through the obstacles.

The fire boulder and explosive tar boulder hold the greatest potential for emergence. A fire boulder does not add any extra damage. It keeps the damage of the boulder type, but it does set things on fire. If you hit a house with a fire boulder, a Spriggan will come running out of the house on fire and will potentially run into other houses which will then set those on fire.

If you hit a house with the explosive tar, the tar will spread onto other houses. When you hit these houses with a fire boulder they create massive explosions that will instantly decimate the house. As such, a standard explosive tar boulder with a fire multi-boulder could be a recipe for destruction. Perhaps the player could use a hyperboulder to take out obstacles and then just send down multi-boulders. With all of these options available to the player, the possibilities for emergence are formed.

Emergence can be difficult to work with for all three tracks, but the team has worked very hard on Sprites vs. Spriggans. Valmin Miranda, our programmer, has been working extremely hard learning how to develop for the devices. The objective-C used by these devices is definitely unusual and it creates a great challenge for the programmers. It is also a challenge because developing for them requires a Mac, which involves a lot of set up time as we have to check out and set up Mac Minis to use for development.

Aside from programming, the device has given me and fellow Producer Pat Dietz some very interesting design decisions. It is definitely a difficult device to design for, but it can be very rewarding. There are a lot of constraints, but also a lot of awesome possibilities. You have to design for smaller screens and figure out how to best use touch and accelerometers. You have to decide what makes sense to touch and how the game will play with only touch at your disposal. It is extremely different than working with the PC engines we have used in previous rounds.

The art for Sprites vs. Spriggans is also amazing. The artwork created by Luke Gamble (my second time working with him) and Michael Bakerman has been outstanding. Their work looks so vibrant, colorful, and amazing on the iDevices. Their style matches perfectly to what we were going for and the game looks awesome.

While the iDevices can be a bit tricky, and they come with a steep learning curve, I highly recommend working with them. It is an absolutely greatly learning experience for everyone involved. These devices are gaining a lot of traction and a lot of companies are beginning to develop for them. Thus having worked with them before is definitely a helpful bonus. Aside from that, you can also show off your game wherever you go if you have any of the iDevices.

As usual, I will leave you with some screenshots and artwork from the game. Enjoy!

Under Dog Postmortem

The main focus for Under Dog was to make a fun story that was simple and easy to grasp. We did not want to spend a lot of time telling the story through long cutscenes, nor did we want to have to preface the story with a long explanation. We also wanted to weave the gameplay mechanics seamlessly into the story to make a complete package.

By the finished product, we were quite pleased with how well it matched our initial goals. Our story was very simple, so much that the title screen was really able to capture a great deal of the narrative (with the use of a newspaper article as the title screen). The rest was then explained naturally through the gameplay progression. Even though it was simple, the theme was strong and the story was impactful and relatable. This was further helped by the fact that the gameplay wove nicely into the story and they were in unison throughout. While it was simple, it still had an amazing amount of depth as the gameplay mechanics and the story tied very nicely into the Greek mythology.

While the final product was certainly excellent, there were certain aspects of the project that went very well, and others not so much. But that is to be expected with any development process. In the end, we are all very proud of Under Dog.

With the preface aside, let us take a look at the project a little deeper.

What Went Right

  1. Well Defined Mechanics & Story – Early on we were able to define and really narrow down the mechanics. This really helped throughout the project. The story we developed also tied so well into the gameplay that they both fed off each other and the combination of the two was awesome. The herding mechanics found in Under Dog matched perfectly with our premise and they also tied very nicely into the Greek mythology. Having everything well mapped in advanced gave us a focus throughout the project. It allowed us to make assets and features that made complete sense to the project and there was never any real question on what direction we were going with the project. Having these defined early was crucial to our success.

  2. Solid Communication – The team initially had some issues with communication, but it improved rapidly, and by in large, we communicated very well. Everyone always knew what needed to be done, what was done, and where the project stood. Everyone was very easy to reach if there were questions and everyone made sure to keep up-to-date on progress made. This made for a smooth process as we always knew where we stood and this allowed us to focus in on what needed to be done.

  3. Switching Engines – On a cursory glance, one would think having to switch engines during the project would be something that would fall under the “What Went Wrong” category. However, we switched very early on in the project, and in the end, we all felt it was the right choice.

    It may have been a bit tough initially to scrap what we had already done in Panda 3D, but switching to Unity was honestly the best decision.  Since we were able to create the entire play environment using Unity’s terrain building tools, the artists were able to focus a lot more on the 2D art, and they could spend more time on the 3D models.  Coding and implementation also turned out to be easier as well as a lot of the elements such as camera and loading assets was incredibly easy using Unity. Overall, the engine switch, and Unity in general, went quite well.

  4. Positive Attitudes – There was a surprising amount of work that had to be changed or either cut completely from the game. This is never easy to do and is one of the harder parts of the process. Even through all of that however, everyone maintained a positive attitude. Everything that was cut made sense to the team and everyone understood why it needed to be done. No one was offended or got angry when it happened. We were certainly all disappointed, but it was all handled very professionally and this helped immensely.  It may have turned into something that could have easily derailed the project. But the great attitudes from everyone kept the project on the right track.

What Went Wrong

  1. Bark Mechanic – From some of our earliest meetings, we wanted to create a bark mechanic. Dogs bark, and herding dogs especially. So it seemed natural to include this functionality given the nature of the game. However, even with the final version of the game were still unable to include the bark mechanic.

    We spent several meetings trying to determine how we wanted the mechanic to work and we could never really finalize what it would do. Would it just greatly push the souls towards the gate or would it freeze them and make them easier to push? We bounced back and forth and we could not settle on one particular idea. It was not a lack of ideas that hindered us it was a lack of any strong motivating ideas.

    What we came up with was certainly functional, but it wasn’t anything particularly exciting. We could not settle on a mechanic that would have made the bark a must have item. Since we couldn’t find a wow factor for the mechanic, it just kept getting pushed back and back. Eventually it got so late in the project that cinematics, the tutorial, and storytelling all took precedence. Had we been able to finalize the mechanics of the bark, we would have probably put forth the extra time to make sure that it got into the game.

  2. Difficulty Splitting up Programming – While Unity was an amazing engine to use, it did make it quite difficult to break up the programming. Unity uses a ton of files in its builds and it’s hard to share all of those files. It certainly is possible, and Unity does have some integration support for Perforce, but it seemed like a huge hassle to deal with in the short period of time. Usually it was just easier to create the files separately in two separate Unity files and then merge them. This is what we did with the environment. However, this limited us a lot as where were constantly weary of trying to add new separate files, to the point where features were cut (Bark Mechanic) or more work was placed on our programmer.

  3. Did Not Research Engines – We choose Panda almost immediately. It was the very first decision we made, even before deciding on the theme or the mechanics. Was this the best choice? Probably not. But we felt that we needed to know what engine to work with because that would dictate what kind of game we made. For example, if we chose iPhone right off the bat, then that would certainly influence what kind of game we would design. The tricky part is that it can sometimes be a catch-22 as on the other hand you really need mechanics in place to know what the best engine will be for the project.

    We picked Panda right away and it really did not fit what we needed. This led to the Unity switch. Had we researched immediately what each engine’s strengths and weaknesses were, we may have decided initially that Unity was the way to go. This would have avoided the entire engine switch which would have saved us the time spent getting a few things set up in Panda. Had we gone with Unity from the beginning, we probably would have had enough time to implement the bark mechanic for the final version.

  4. Initial Difficulties Finalizing Art Style – Initially we wanted this underworld theme that was dark, but yet was cartoon like and humorous. We wanted Cerby to be this cute little dog, and we wanted the other hellhounds to be polar opposites. We spent a lot of time redoing the Cerby concept art as we could not finalize what style we wanted to go with. We wanted him to be cute and cartoon like, but we still also wanted him to be serious and still have a bit of a hellhound in him. Eventually we got to the perfect spot, but it took us a long time which delayed the creation and animation of the 3D model.

With Another Week

  1. Bark Mechanic – As mentioned in the “What Went Wrong” section, not getting the bark mechanic in was a disappointment. With more time, we would have perfected its mechanics and we would have implemented it in the game.

  2. Redo Souls – Early on we talked about the souls actually having a somewhat human like appearance. Throughout the project we discussed changing the souls on several occasions, but just never got around to it. Instead we added particle effects to them directly in Unity and that seemed to satisfy everyone. For the final version, they remained spheres. Even though they had awesome particle effects, it still felt a bit like placeholder art. With more time we definitely would have stepped them up.

  3. Subtitles/Message boxes – This was something we really wanted to get into the final version but were not able to. We had a decent amount of voice over work for the game and for the final version we were not able to offer the player a way to read it. We wanted to have message boxes and subtitles pop up over Cerberus, right above the Impression meter during all cutscenes. This would have helped with clarity as some of the effects we added to the Cerberus voice overs made a few lines hard to understand.

  4. Cerberus Model – With more time, we probably would have gotten in a physical 3D model of Cerberus. That way the player could have had a reference point for where the voice overs were coming from. We also considered having Cerberus play a role in effecting gameplay in some manner. With a 3D model, it may have been something we could have investigated further.

  5. More Cerby Animations – The Cerby model had a great walking animation. It perfectly matched the style we were going for (this cartoon like movement). The sit animation was just pure awesome and cute, exactly what we were going for. However, with more time, we would have gotten in a few more animations. The tail could have started wagging while he was sorting souls. We also would have added in a bark animation for the bark mechanic. Finally, we would have had his head tilt when he moved left to right or maybe even have him do something more with the idle animation like him scratching his head with his front paw.

Under Dog – Full Version Posted

Under Dog is complete and is posted to the blog. Please click on the link below to play the game.

Under Dog is a rapid prototype built for Round 2 of Rapid Prototype Production. Under Dog was developed using the Unity 3D engine.

Play Under Dog by clicking here

RPP Round 2 – Story Matters

Time has certainly flown by. It is October, we are already six weeks through the first semester, and we are almost done with RPP Round 2. The entire Cohort is starting to settle into this lifestyle of sleep deprivation, crunching for deadlines, and being bombarded with work from the core classes and RPP.

One of the first things you will discover is how hard it is to find time to do the simple things, like laundry or grocery shopping. They are seemingly simple tasks, but they are really hard to slot in sometimes. While it certainly can be overwhelming, you never lose sight at how much fun you are having. This passion we have to create interactive entertainment constantly drives us forward.

With that said, it is almost the end of RPP Round 2 and I have not spent any time discussing what it is we have been doing this past week and a half. As I alluded to previously, each round of RPP has a new theme. This round’s theme is story.  On top of a new theme, with this round, and each round hereafter, you are free to choose the engine you want to work with (last round you had to use Flash).

In Round 2, we are learning how to create and incorporate high quality stories into our games. We learned how to create better dialogue and how to create more impactful scenes. We learned to show, not tell. Finally, we discussed the Monomyth (hero’s journey). There was a lot of information to take in regarding story, but with the seeds in place, we were broken up into a new set of teams and we began work on our new games.

Naturally, the first thing you do as a team is conduct a brainstorming session. These typical dominate your first few meetings as a team. We’ve learned to love brainstorming sessions as we have done a lot of them. This is especially true for Producers as we do a few of them in class as well. The Producers have a few classes where we learn how to lead and direct useful, structured brainstorming sessions.

After just one brainstorming session, my team had most of our main story and mechanics down. However, we needed a few more meetings to finalize all the ideas. From our sessions, we came up with a game called Under Dog (not to be confused with the cartoon). The premise of the story is that Cerberus, the gatekeeper of the Underworld, has decided to retire. You play as Cerby, his up-and-coming replacement. You are his apprentice and you have to prove to Cerberus that you are capable of the job. Cerberus is a tough master and he doesn’t think Cerby can do the job, but Cerby is out to prove him wrong.

The gameplay ties nicely into both the game’s story and the mythology. In Under Dog, you are sorting and placing souls into gates. There are three types of souls, and each soul requires a different method. The green souls, the Followers, will cling to the player and you have to bring them to their green gate. Then there are Chaser souls (orange color). You have to herd (push) them into their gate. Finally, there are purple souls called Runners. They are trying to escape the Underworld by heading towards the river Styx. You just have to catch them and they will fade back into the Underworld.

This concept of sorting souls into three different paths actually fits well with the mythology. In Greek Mythology, the souls enter the Underworld from river Styx and they appear in Tartarus to be judged and sorted. The good souls go to the Elysian Fields (Follower souls), the equally just go to Asphodel Meadows (Chaser souls), and the evil souls (Runners) go down a path to the depths of Tartarus.

We were quite pleased with how the mythology, story, and gameplay all tied together nicely. Cerberus as the master, and Cerby as the apprentice, is a new story arc however. We originally planned to have Cerby, Cerberus and three other Hellhounds as part of a pack and Cerby would have had to face each Hellhound in a challenge before getting the job.

During our Interim presentation, Ron gave us very helpful feedback. He didn’t think the other Hellhounds were necessary. Afterward, we had a meeting and agreed that we could spend more time focusing on the Cerberus-Cerby relationship. We decided to cut the Hellhounds. This was tough to do as the artists already had spent a good deal of time creating assets for two Hellhounds. It is never easy to throw away work. However, we have since found a way to at least use the art in the game.

Independent of what was going on with the story, we always had this idea of an impression meter. The impression meter is the feedback tool to show the player how well they are doing. For each level, you have to reach a certain amount of impression in order to please Cerberus. You gain impression by properly sorting souls into their correct gate. Chaser souls are worth more than Follower souls, and Runners are in the middle. You can also lose impression by sorting the souls into the wrong gate, or if you let the Runners escape.

While the story and the mechanics went well, we had two issues in the first week of development that caused us a decent amount of trouble. First, let me discuss our choice of engine. For Under Dog, we originally decided to go with Panda 3D. We worked a few days with Panda 3D and ran into a variety of issues with Maya 2011 and the entire art pipeline (the method of getting assets into the game).

This issue, and having seen the power of Unity, pushed us towards switching. This was the toughest decision I’ve had to deal with as a Producer thus far. It was a really tough call because Carlo Mixco, our programmer, had a good amount established in Panda already. We did not want to just throw it out so quickly. In the end though, we decided it was in our best interest to change to Unity.

Unity made a lot of things easier and Carlo got comfortable with the engine very quickly. Unity also freed up a lot of work from the artists, Jagruti Patel and Justin Ervin. With Panda, the artists were going to have to create the environments in Maya. With Unity, Michael Luongo, our other producer, was able to create the environment and gameplay stage using Unity’s tools.

On top of the engine switch, we had a lot of trouble nailing down the art style. We originally were going for this cute puppy dog look for Cerby, but we wanted him to still have this sense of a Hellhound. It was a tough challenge and it took us quite a bit of time to finally find that right style. This is definitely something we should have gotten down much more quickly as it was tricky to find that right balance. We eventually decided to mostly drop the cute side and just make him a Hellhound looking puppy. Ironically enough, with the cartoon-like proportions we were aiming for, it made it look cute anyway.

Aside from that though, we are very proud and excited with our game. The team has had to work through a lot of challenges, but we have worked well together and we have made a great game. We just have a few more things to get in the game before Tuesday. We want to get in a bark mechanic and the cinematic events. After that, it will be a few more tweaks and we will be ready for final presentations.

Before I wrap this up, I just wanted to send out a thank you to my team for their hard work. Carlo has been awesome as our programmer, pumping out high quality work quickly, and he handled our engine swift gracefully. Justin and Jag have been balancing a lot of homework in their core classes and have been getting us some great artwork for the game. Thanks to them for being patient with us Producers.

Michael has helped create a level environment in Unity and has helped out in various ways from the story script to ambiance music. This freed me up to focus on scheduling, making sure everyone was on the same page, sound effects, script writing and any other tasks that were required.

That is about it for Under Dog. Since I got to this post so late, there won’t be a second post relating to Under Dog. I will more than likely write a postmortem for the game sometime next week. Until then, below are some screenshots from Under Dog.

Under Dog Ferry Screenshot Under Dog Three Soul Types Screenshot
Under Dog Followers Into Gate Screenshot
Page 3 of 41234