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