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