Cohort 5 completes their 5th round of prototypes

Cohort 5 has completed and presented their final round of prototype games. This round was a polished build on a previously designed game with a 3-week time frame, rather than 2 as usual. It was both a help and a challenge to work with existing game components, as we did have a starting frame of reference, but also had to deal with the nuances of using someone else's raw files. Luckily, our programmer was also the programmer of the original game, so he knew his own code, but our artists were tasked with the challenge of working with someone else's models and animations.

Our final build featured 4 objectives: talk to the roof mouse and obtain the acorn bomb, find the informant mouse in the warehouse, take back the nut diamond from Big Ratsy's safe, and escape the building. Overall the game evolved more story without getting cluttered and boring and enhanced gameplay. While the original was story and sneaking, the polished version included a bit more of a combat mechanic with the acorn bomb.

With Darrell's help we managed to get the buttons on the splash screen updated and transparent, so that whole screen was a total revamp and I think looks awesome.

I did a 2nd version of the credits which was a bit more cleaned up and uniform, as well as the new credits for voice acting. I managed to steal Carl for 15 minutes to record the new mice dialogue tracks that I wrote and then exported those out after deciding if we wanted a nervous informant or a French one.

Ryan's work on the intro movie did a great job of getting the story across without boring the player. This was a change we made after the first iteration where the story was told in a longer format and was too much text to deal with. He also picked up on an oversight with the end screens where they didn't fit with the rest of the game, so he gave those the newspaper treatment as well.

Kait and Katie did a great job updating the animations, even with how difficult the originals were to work with. The updates to the textures, as well as a few extra ambiance pieces like the posters really helped add to the Film Noir feel. Their additional renders of Big Ratsy, his office, and the mice were also well suited to fit the environment.

Overall, our only issues we discussed as being "needs improvement" were that we needed to be a bit more organized and have clearer goals set. Play testing more would have been a good idea as well, as the enemy placement needed some tweaking to give more of a controlled challenge.

As for positives, it went over really well, we caught all the major bugs before presentation so it didn't crash, the redone animations worked very well, and the expansion of the story and additional game mechanics expanded the game without cluttering it.

My final contributions:
- Redesigned the splash screen and buttons
- Wrote the fake newspaper text
- Created a credits reel
- Altered the safe texture to desaturate the red text
- Wrote the mice's dialogue
- Recorded the mice's vocals, mixed and exported

Overall, I'd say we polished this one pretty well. I could see presenting this as a single level of a game with multiple 'cases' that Squirle has to go on during his quest to finally put Big Ratsy behind bars. We had discussed wanting a boss battle, and I'd see a final showdown between BR and Squirle as just that.

More progress on the final RPP round

This week was a heavy crunch week for producers, as we were finishing up our Design for Media projects (development documents for existing games). I was down to the wire editing my group's document, but we got it in on time, so that's one down and one to go. Now I can focus completely on round 5 which is due Monday...

After our second interim we had throwing implemented, as well as a "boss lair" complete with boss and the objective (nut diamond) hidden within a safe. After some assessment of our progress, time, and objectives with the game, we decided to finalize the plan as thus:

The player will begin on the roof and talk to a mouse informant who tells them his buddy is downstairs with the code to Big Ratsy's safe, where the Nut Diamond is being held. The player can pick up an acorn item to throw at the rats within the air vents and warehouse to stun them and get to Big Ratsy's office. Once they find the other mouse in the warehouse, they can go into the office and unlock the safe, grabbing the Nut Diamond and setting the alarms off. If they can make it to the exit doors without getting caught, they win.

We're recording some new dialogue for the mice and removing some of the old dialogue, as this was a 'story' game previously and was a bit heavy on the extraneous dialogue.

Recently I cleaned up the splash screen at the start of the game:


That involved creating some background images such as the crumpled newspaper:


I also did a preliminary credits reel using images mainly from the first iteration of the game:


I'm working on a second final version for the end build using the updated screenshots as well as adding vocal credits if we decide to have the mouse dialogue audible. We're also looking at the level design to see if we want to change up some of the barrier items inside to add a little variety and also to make sure it's balanced with the new acorn mechanic.

Team 4 - Arcane Furor

Hey all,
The fifth and final round of rapid prototyping for the semester is upon us. This round our goal is to polish a game we created in a previous round. Our team from round three enjoyed working together and created an all around fun game in Arcane Furor so we reformed our team. We had a lot of design ideas were weren’t able to get into the game on the first go around along with various challenges we simply did not have time to fix.

Our programmers jumped strait in and refactored the code. This fixed a big memory issue we had during round three that restricted us from adding some additional features. The programmers have also added in the ability to select the number of players. They have also added in game states including menu, game, and pause states allowing us to add in GUI system which is one of our main goals for this round.

Our artist has also done some fixing of his own. He has expanded the number of character models from one to four and the models are currently being tweaked to have more contrast with each other. He is also working to create two additional levels. Each level will incorporate its own unique feature such as level deterioration.

Our producers have done their share of work as well. We did initial design work to find what features would add to our current game and were within our scope. This round is about polish so we are making some minor additions while still focusing on making the game look and play at its best. Tom has already upgraded all the particle effects associated with the various spells. I am in charge of organizing the team including scheduling meetings, recording meeting minutes and maintaining team communication. I have been working primarily on the GUI including designing the menu structure and functionality and developing the assets for the GUI. I have also done some minor coding including adding additional controller functionality and creating additional build configurations.

Things I have done:
Designed menu structure and functionality
Minor code changes (additional controller functionality, added build configurations)
Created team schedule
Recorded meeting minutes

Until next time,
Reid

Final polish round for Cohort 5

For round 5 we're polishing a previously created game and our programmer Darrell convinced us to continue work on his round 2 project, Dick Squirle: Private Investigator.

The original gameplay relied heavily on audio clues to tell you what was going on and the mechanic was to explore the rats' hideout and retrieve the diamond without being caught by the rat henchmen. You could walk normally or use a sneak feature that allowed you to pass by the rats at a closer radius without them being alerted to your presence. The level began on the rooftop where you listened to dialogue between two rats, then you climbed down an airduct and traveled through the duct maze until you dropped out into the warehouse. From there, you snuck around crates of TNT, avoiding drawing the attention of the randomly placed rat henchmen, and eventually you'd find the stolen diamond, pick it up, and the exit door would unlock to end the level.

The flaws we found were that the sneak mechanic was a bit tedious and didn't offer any alternative way to navigate the level. So our first addition to the gameplay was to add a throwing mechanism where we could throw two different projectiles, cheese (to lure enemies) or acorns (to stun them on impact). Also in the original version the nut diamond was just sitting out in the open and once you picked it up, an alarm would sound and you had to get to the warehouse doors. We wanted to actually include Big Ratsy as a "boss" character, so we're making the doors lead to his lair rather than the game over screen.

The game originally started with the newspaper scene telling the Nut Diamond was stolen, Dick Squirle is on the case, etc. and then just dropped the player on the roof with little to no direction. We decided to remove the ambient dialogue of the two rat henchmen on the roof and replace that all with a mouse informant standing near the air duct.


Kait's mouse model, complete with jaunty cap

Upon approach he'll tell Dick the first part of the boss' password and tell him what to do next. This will lead the player down the air duct maze and eventually down into the warehouse.


The original level design

The warehouse was determined to be too bland and needed some variety, which upon analysis was seen to be too much of a linear maze - something we already had in the air duct area. So we're working on retexturing some of the crates and walls to make them pop a little more, some additional objects (barrels, signs on the walls), and improving the lighting. The diamond will also not be just sitting out in the open, but rather once the player finds the other 3 mice with the pieces of the password to the boss' office, they will enter the office door and confront Big Ratsy who holds the diamond.

I've taken up the task of redesigning the menu screens and doing the credit reel, using a Film Noir motif for it all to keep the theme of the game. I'm also going to work on the sound design a bit more as well as modeling some of the warehouse items.

Airfoil with lift

Fluid flow past an airfoil.

Any ideas for how to use this in a game?

Maybe a puzzle game where you have to get a paper airplane to strike a target...?

Final Thoughts on Wall E

ASSIGNMENT
Wall E:Eve's Garden was made in exactly 2 weeks time by a team of five people. There were two producers, one programmer, and two artist's working on this project. The goal was to use an existing intellectual property(IP for short) to make a game that utilizes indirect control. Using indirect control, developers can give players the illusion that they have lots of freedom to explore,when really they don't.

OVERVIEW
Our IP assignment was Wall_E. We decided to design our game around both the IP and the demographic it targets. Specifically, the demographic we targeted was children ages 10 & up. Thus, our controls & puzzle's were only as complex as the demographic required. Once Steve and I finished the level design we separated into two teams to complete the game. The programming team consisted of Victor and myself. Victor designed the games architecture and then delegated me programming task's. Steve, Carlos and Katie made up our art team. Katie did all the character modeling while Carlos and Steve did the environmental modeling.

MY CONTRIBUTION
For this round, I played the role of both a designer and programmer. As a designer, I collaborated with Steve to create the core mechanic's and level design. Our level design was challenging because we had to implement indirect control. The two tools we used to create indirect control was orientation and line of sight. By starting the player off facing a specific direction, we were able focus their attention toward the first important location in the level. Using boxes to block the players view, we directed them in direction's we wanted them to visit.
As a programmer, i learned how to use XNA's audio authoring tool [called XACT] to create sound files called "cue's". I them implemented the code that allowed the engine to read the "cue's". I also wrote the code that allowed our roach character [Hal], to travel through cracks in the walls. I accomplished this by using collision sphere's as "triggers" to let me know when Hal was about to collide with a crack; then i reset Hal's position to the corresponding crack. Lastly, I created spatial sound triggers that allowed certain sound's to be played when the player is at a specific area of the level.

AGILE MANAGEMENT
Just as i did last round, i again implemented agile management techniques using SCRUM. Since RPP is very short on time with very small teams, i tailored SCRUM so that it would be most beneficial to my teams situation. The heart of SCRUM is the daily meetings during which each team member answers three questions. These questions are meant to "synchronize" the team so that everyone knows what each other is doing. Every day at noon we held our 15min daily meetings.

CONCLUSION
Wall E was warmly accepted as our IP on day one, and we all embraced it during the two weeks. The end result was a polished game with a fun mechanic and enticing sound. We were fortunate to have such a talented, well balanced team. Carlos, Katie, and Steve worked very diligently on the art assets. Our characters and environment not only look great, but they truly capture the feel of the IP. Victor is very talented and extremely determined; he accomplished everything asked of him and more. I would happily work with any of them again. Great job Victor, Carlos, Katie and Steve.

Rapid Prototype - Post Mortem - Round 4

Hey all,
Cohort 5 has just completed the fourth round (out of five) in our rapid prototyping class. This round we had two constraints. We had to work with an intellectual property (IP) and we had to use indirect control. Below is my team's post mortem for this round.


What Went Right
Indirect Control
Our goal for this round was indirect control and we met that goal. We were always aware of this goal and worked to design the game using indirect control. It turned out to be a bigger challenge then we initially thought. Our indirect control planning only took us so far. It was only through constant testing using different people and observing what they actually did that we were able to figure out what actually worked.

Pipeline
We established a solid asset pipeline early. Everyone knew what they were responsible for and keep the team abreast throughout development. The team worked together to make sure everyone knew how to use the tools relating to their assigned assets, sharing what we learned along the way.

Communication
As a team, we worked together to build a solid line of communication. We only had a few meetings and we kept them short and to the point. Each team member always knew what each person was working on and who to talk to if they needed information, assets or encounter a problem.


What Went Wrong
Overly Complex Puzzle
We designed a puzzle that was more complex then it needed to be. Our puzzle used the vertical space in our mall environment and many of our testers simply did not think or realize to use that vertical space. As a result, it was difficult to communicate how the player was supposed to complete the puzzle.

Complex Controls
Our controls were complicated and confusing. While we made sure our controls for movement were natural, our controls for grappling and defusing the bomb were confusing. We worked to address the learning curve by exposing the player to the controls only once they were needed and kept them readily available. Unfortunately, this wasn't wasn’t enough. In retrospective, we should have spent more time finding a control scheme that was simple and felt natural.

Got Ahead of Ourselves
We worked hard to have a good showing at interim but lost momentum afterwards. We were able to get ahead of schedule and as a result, we unintentionally slowed momentum for a few days. The momentum picked back up toward the end of the second week once we realized what had happened but it took some time to ramp back up. We should have maintained the momentum by pushing each other. It would have allowed us extra time to polish the game and fix a few issues we simply did not get a chance to address.


Closing Thoughts
Despite hitting a few bumps along the way, the team worked well together and we met our assigned goal. We were able to use indirect control to predict what a brand new player was going to do at a few key points in our game. We build a solid asset pipeline along with establishing and maintaining communication between the team members. Unfortunately one of the main aspects of the game, our bomb puzzle, was more difficult then we intended due in part to confusing controls. Not to mention the fact that the puzzle itself ended up being too complicated for the average player. Overall, Batman: Maniac Mall was great learning experience and a blast to develop.

Rapid Prototypes - Working with an existing IP

Cohort 5 just finished their 4th round of Rapid Prototype Production where each team of 5-6 members was handed an existing Intellectual Property (IP) to create a game around. This meant that we already had artwork to base our design off and fiction to work with, making the game design easier in some respects but harder in others. The following is documentation of one team's work over a 2-week period on this round of projects, as seen through the eyes of a producer:

Our IP is Avatar: The Last Airbender and my first task was to get a better grasp on the subject material. So, 8-10 episodes later I’m remembering the little bit I knew about the series and have a pretty good feel for what elements make for an interesting game. We also made sure to take into consideration the idea of indirect control within the gameplay.

Our first meetings were spent learning about everyone’s strengths, weaknesses, and passions as well as their needs for assignments. After discussing the possibility of the Wii balance board with the Wiimote as a control scheme, and TorqueX, we ended up deciding on normal-flavor Torque. Our game mechanic evolved from a temple exploration game, to a balancing pole game, to a flying game, and finally we reached a decision on an obstacle course/gauntlet challenge.

While doing my IP research, we were still on the idea of a flying game, so I mindmapped the various nuances of flight in Avatar:

The hows, wheres and whys of flight in the Avatar world

So now I’m working on designing a obstacle course layout, and playing with the ideas of how to use the 4 bending elements in gameplay effectively.

Work done so far:

• Gained familiarity with the IP (read: watched cartoons)
• Worked with Brian and Darrell on a plan for the gameplay
• Discussed art styles and needs with Pam and Lauren
• Analyzed concerns with the other team members in regards to workflow and assignments
• Came to agreement on what is needed for Monday

---------------------

Our interim presentation went very well. We had the Aang model in the environment and a basic temple structure in place. Aang can do the fire and water bending attacks, as well as a boosted air jump, so our mechanics were well in place. When mentioning the puzzles Ron suggested we concentrate on that and make them really reflect the use of the different elements. Currently in our design, which can be seen here:

Preliminary level design

We have a multi-chambered level with 4 elemental chambers, a central chamber, and a training corridor. The air chamber is tranquil and acts as a starting/ending point, as air benders are more peaceful and non-combative. The fire chamber is combative and intense, as are fire bending skills, while the earth chamber is more catastrophic and destructive. The water chamber, even though we are using an offensive water bending attack in the gameplay, is a puzzle chamber to reflect on the reserved nature of the water bending tribes. Upon hearing the idea of the puzzle chamber, Ron suggested we concentrate on that puzzle aspect and make use of the unique properties of the 4 elements to solve those puzzles.

I am now reviewing the various powers and coming up with ideas for puzzles that would require a specific bending technique to solve them. Some of my ideas are scanned below.

Some water bending puzzle ideas

Some fire bending puzzle ideas

I think for the purposes of a prototype of this game, we should do one large chamber that has a different puzzle for each element to solve. That way we can illustrate how the different elements can be used to solve puzzles and the puzzles can be shown as examples of obstacles that could be put in place should we build a more expansive level.

------------------------

Final build is done, amazing, and it’s only 5:30! Today was spent implementing sounds, finishing the AI, and testing.

Since my last post, I finished up all the game sounds (which I would normally preview here, but I don’t think .ogg files work with our blog), modeled and textured a Pai Sho piece as our in-game pickup, and I managed to at least get the attack sounds to work in the script, but couldn’t get the BGM to work. I figured it was just my novice programming skills against me, but Darrell had some struggles with it too, so I don’t feel quite so bad. He’s awesome, though, and got it working, so all is well.

I’m really proud of the Pai Sho piece:

I can't believe I actually did this...

I knew making the physical model was simple, just a cylinder flipped around to the side. But I had never tried to do a texture map before from scratch (I just modded a sample file for my donut in Intro, and my vehicle was just colored, not textured). So I sat down with the Maya tutorial files and battled my way through it. Luckily I had vectored out the White Lotus symbol way early in the production stage, so I had that readily available. Here’s the flat texture:

This may not look like much, but it's impressive to me

And the white lotus symbol I vectored out before finally got some good use:

Basically redrawn by hand from a reference image, easily scaled

-------------------

The game presentation went very well and overall, we were pleased with the end product. After the presentations, our group met to discuss how we felt it all went. We came up with the following:

- 90% of the audience agreed, they knew that the balls were supposed to go on the pedistal.
- Everything we wanted to get done was accomplished
- Troubleshooting went well, when things didn’t work we powered through them
- Torque was a good choice for our mechanics, Constructor worked out well for our environment (saved us on size)

Things we would change:
- Animation for flight, maybe the air sphere Aang rides on
- Color code or illuminate the ball/pedestal puzzle so it’s more obvious

And, a final list of my contributions:
- Researched IP, developed game mechanics and puzzles
- Kept running updates on changes and level design
- Designed temple puzzles (some of which weren’t used)
- Modeled and textured Pai Sho piece
- Developed all sounds and implemented weapon/character sounds in game code

Vortex splitting

Vortices which separated now spawn new particles, maintaining a contiguous thread of them.
Have a look.

See you at SIGgraph.

Fluid simulation update: SIGgraph 2008 poster

SIGgraph 2008 accepted my poster and I've prepared source material for it. Jon Tran and Todd Deery are working on the actual poster and Jon's first few passes at it look great. I'll provide a link to the PDF when it's ready for public consumption.

Meanwhile here are some new movies.

Heading into Production

Hello good people,

I know it has been a long time since I last penned some words about the industry. There are so many things that happened in FIEA and the Interactive Entertainment industry.

First off, Take Two's Rockstar label launched Grand Theft Auto IV. I know that announcement did not need to be made on this blog, but it is big news. The first weeks sales eclipsed the sales of Halo 3 with $500 million, thus making it the highest-grossing opening week of any entertainment property. As we patiently waited for the release of GTAIV, EA was courting a buyout of Take-Two for a couple of billion. The negotiations came to a halt as the launch day came closer and closer. Now, I wonder will EA still entertain a buyout of Take-Two while they are riding high on the GTA drug or will they wait for the high to come down before opening up discussions, again? We know all the publishers out there want a Rockstar on their team, who will be the first to get one? Enough about the industry, let's talk about two games that are changing it-- Zephyr and Meat Mechanics.

Our preproduction stage came to a close late April. The presentations were excellent. The Meat Mechanics came in with a heavy hitting, body slamming, death match presentation. Their presentation was similar to watching an episode of WWE Smackdown! They showed off their real-time strategy game in real-time. They also created a real-time strategy game for your ADD gamer and gamers that dislike violent games. For the first time, I said this may be an RTS that seems really fun before playing it for myself.

Next, Team Zephyr was up to bat with a sky high final pre-production presentation. As the presentation snowballed into an action-packed climax, I thought about how much blood, sweat, tears, and sleepless nights that the team's producers, artists, and programmers put into the game during the semester. Zephyr's leadership pushed us through to the finish line. But, credit has to go to those team members that accept the vision and plow through the work to make it a reality.

Now, for some more rules.

RULE 4: Good leadership is important, but followership is more important.
Once the team completely aligned with the leadership, we were able to make miracles happen. As we struggled through the vision, the team was able to focus on a single course of action and make it happen. Everyone wanted to present a good prototype and demonstration of the game. The team learned to put all their differences and problems to the side to concentrate not only on the game, but the presentation. For once, meetings felt essential in order to deliver a fun prototype. The team was measuring every step and hoping the best result came from every decision.

Extra kudos to the programmers for sleeplessly working in the cohort space to make sure the game was worth viewing during the final presentation.

RULE 5: A combination of passion, planning, and action is the fuel to overcome ALL obstacles.
I know this sounds like common sense. But, you will be surprised how many people in the world do not use all three to overcome obstacles. Most people believe planning and action are enough to overcome obstacles; however, without passion they never overcome the obstacle because they do not care about the goal. People that are passionately active without planning become too broad and not focused on achieving their goals, thus never making it to the finish line. We all know what happens to those that only passionately dream without action. They wither away with time. So, the correct balance of all three is necessary for success.

RULE 6: Use success for momentum to conquer higher goals and not to celebrate. This is not the time to celebrate. The successful completion of pre-production empowers action in production. It is too early in the game to celebrate. Both teams need to take the feedback from the higher powers and hone in on fixing our mistakes and striving for success. If we celebrate now, we are bound to lose momentum and potentially fail. Nothing is perfect, but we should strive for perfection. One battle doesn't end a war. Both teams are not only in a war to complete an enjoyable and fun game, but in war with the other student games currently being produced at other institutions.

This enough for one entry, I'll be back next week to deliver the highlights from the Production kick-off.

Campfire with smoke

I added another test case for my fluid simulation.

Thanks to Max Acree for the campfire model.

Semester 2 - Post Mortem

Semester two has come to a close and a big congratulation belongs to team Zephyr. Their vertical slice dominated the vertical slice presentation. That's not to say that my own team, team M.E.A.T. did not meet expectations, simply that we got beat out. After talking it over with others on my team we've decided that we could either lick our wounds or we fight harder to raise the bar. We elected the latter.

This semester has been a whirlwind of excitement. From the beginning more has been asked of us than ever before. While some management decisions resulted in about a month of lost programming hours on our team, it did result in a well thought-out programming architecture and heavily researched approach. It also exposed us to new ways to think as a result to the classes of FIEA. While some of the programmers think it was a month lost, I can't help but wonder if our architecture (which has resulted in much praise on our own behalf and amazing results later in the game) would have been as well planned out. I dare say it would not have been, and our development time would have been littered with game-stopping delays.

I owe it to Sean McVey to say that he's done a wonderful job modding the scene designer to work with the terrain manager which was designed for the game. Although in retrospect we have identified this decision as one of the bigger mistakes of our team. We invested a huge amount of time into the terrain system on all ends, and we have been receiving feedback that “the artists could have done it better”. While this is usually the case, and probably is the case in this particular instance we wanted to free the artists of the level design burden and give that to the producers where it belongs. Doing the terrain programmatically also allowed us more control of terrain at the programming level and simplified our path-finding algorithms. I suspect that our post mortem at the end of the project will rip to shreds the time spent on the terrain manager, and in a future project of this scale it might elect to have the artists work more closely with the designers to generate levels. Although with our current solution if we decide to have more than the proposed two maps our producers will be in a good position to crank out a ton of them.

I'd also like to do a shout out to the other programmers on my team (Paul Watkins and our Lead Billy Bramer). It has been an incredibly stressful semester and it helps to have a support line of like-minded individuals. It is even better when you've developed what will prove to be lifelong friendships with the guys you've spent a year of your life "In the trenches" with. Stressful or not I'd like to believe we've all grown, and that in the end the semester was successful and well worth the effort expended. If even one of us dropped the ball, I would be writing a very different post mortem.

As a team, as a whole, the necessary comraderie has been missing to produce the best possible game. A lot of blame was flying around at the end of the presentation and I think we all owe it to ourselves to take a step back and ask the question if we are treating the other team members the way they should be treated. I know that I have managed to subconsciously treat some individuals less than they deserve, and I intend on working on that over the next semester.

I also think we as a team need to reflect on ourselves and verify that we gave everything we could to our project, our team and retrospectively to our education. Speaking for myself, I can happily (although somewhat wearily) state that I have given it my all.

Lastly, just because I have to give a warning to all other future FIEA programming students; Dr. Gourlay is not half as scary as he appears to be, but his assignments are ten times as vicious. Stick to it, don't fall behind, and by the end you'll be proud of what you accomplished.

Astonishing April

I got a big surprise this week. The powers that be here at n-Space elevated me to the position of lead designer. I'm now in operational control of my entire design team and in creative control of the game. For those of you not keeping count, this happened about a year and a month since my first day at the company.

Making video games for a living at a great company with great people is about as close as you can get to "the dream." Actually being in charge of the whole operation is that much closer. It's a real thrill -- and a real change from my usual duties -- but I'm confident that I'll be able to get the job done.

All of my superiors were incredibly supportive and encouraging when I was given the position. But the greatest compliment is from everyone else -- my day-to-day coworkers. Upon receiving the news, they immediately started treating me as though I'd been lead designer all along. There were no jokes, or jabs, or smart remarks, or expressions of disbelief. It was simply business as normal. I felt really appreciative of that.

Exciting times!

Tree-based far-field interactions

I added tree-based far-field interactions.

I provided two movies: pretty and nifty.

This diagram tries to explain how the influence algorithm works. Obviously I need to throw more words at that, which of course I will do in the near future. Stay tuned!

A Difference a Day of Production Can Make

Team Awesome is almost halfway through the Pre-Production phase of our final game project. I am going to share some insider knowledge on our progress for the Cardinal of Zephyr , an airship battle game. Every Thursday, Team Awesome presents a status report to Executive Producer. The EP is the gatekeeper for keeping a project online. The moment he or she feels like your project is a waste of time or money, then the house of cards built by your development team will come crumbling down to fall into the fiery pits of hell.

Rule 1: Keep your Executive Producer confident in your ability to complete your game project. It may sound rudimentary, but you will be surprised how many games crash and burn because the EP has no confidence in the project.

Thus far, we have been able to successfully relay our vision of the game to the EP. Without fail, week after week, Team Awesome moves forward on Cardinal of Zephyr. Here are few more rules that I've learned by working on the best game development team this side and the other side of the Mississippi River.

Rule 2: Construct a rigid flexible schedule. Yeah, I know that sounds like an oxymoron. But, you want to make sure that your team can adhere to realistic deadlines, but flexible enough to shift dates around if necessary.

Rule 3: Trust your teammates to do what they are good at and encourage them to perfect their passions. This is quite tricky because some of your teammates may not know what they perform well. They may also assume they're distinguished at doing a task, but they are not that proficient at it. Even worse, their assumption may be their passion. This can be detrimental to the team's overall performance if this person's ability to complete the task is the weakest link. In order to avoid such misjudged mishaps, the leaders need to do a skill assessment and skill utilization management. While assigning tasks, the leaders need to zealously encourage their teammates to be passionate about what they are good at and build new passions around their strong skills. Sure, feelings may get hurt and egos may get bruised, so reiterate how important they are to the team and their skills are detrimental to the teams overall performance.

Those are enough rules for today. I'll give you some new ones in later posts.

We're back and "trying" to make a game...

Semester two at FIEA has begun and it is hard to believe it is already almost four weeks in. I’ve been meaning to get to the blog since the first week, but somehow it kept getting pushed back “until I have more time”. Unfortunately as things usually work out I’m writing this blog now not because I have “more time” but because I’m just trying to get things off my plate, and this is a good place to start.

Since returning to FIEA we have been inundated with meeting requests from across the board; meetings for paper prototypes, board games, tone words, razor statements, tech challenges, feature lists, and meeting requests for presentations from industry leaders. It seems like every time I turn around a new meeting request is sitting in my inbox, and my TODO list is growing not shrinking. It wouldn’t take much for a panic attack right now, but somehow we trudge along.

Last I checked the programmers have their lives on life support and several are seriously considering pulling the plug. From what I’ve heard nobody wants to live the rest of their lives hooked up to machines like a vegetable. The latest diagnosis reads “no improvement expected over the next 9 months”. Bleak news indeed.

Somewhere in the next month or so I’ll try to keep you dedicated readers posted… All those non-dedicated readers will have to wait. Until next time!