Spring 2012 – Flux Disposition (Prototype 5)

Here is my first post since Sword Fighter.  It contains everything that has taken place during the course of our second semester.

In the beginning of our second or Spring semester, everything picked up right where we left off as if our first semester ended.  We began the voting process of all the various game pitches.  There was six pitches selected as potential video game thesis projects that our cohort will be developing for the next nine months.  In the end, three pitches will be selected and each pitch will have a designated team of about 2 or 3  producers, 3 or 4 engineers and 2 – 4 digital artists.  The remaining months will be spent developing a finished Alpha and presenting the proto-types.  Just like we did all semester long in the fall.  We began the process of rapid-prototyping for each of the candidates.  I was able to re-team up with my producer from Sword Fighter, Charlie Mimnaugh.  Felix Lau was an Engineer who I worked alongside with for our very first Prototype, Stress Busters. Our 4th and final team member was Derek Higgs.  Another programmer and author of the game concept for Flux Disposition.

I enjoyed working under Charlie because he has a great talent of managing stressful scenarios.  I believe Charlie and Felix both worked on a game together during their Undergraduate Capstone so the team environment was a comfortable one.

Flux Disposition

Flux Disposition was one of the six pitches selected.  The idea consisted the Tower-Defense kind of game-play.  However, the roles are switched.  Instead of defending massive hoards attacking the player generally with towers which usually are a variety of turrets.  Switching the roles to being the attack and the AI defending was our attempt to aspire towards innovation.  In my opinion, switching the roles of the player vs computer model is still a player vs. computer model.  It doesn’t add up that you can make a competitive play based game and only take the solely offensive function and devise a new genre of video gaming.  Even a sub-genre.  I don’t even think you can make that a sub-sub-genre.  It’s only a necessary asset of a style of game play that is required for the game to even be defined as tower and defense.  This alone made me think about how closely related Tower Defense games and Real Time Strategy games and the more I think about it… really this game was Real Time Strategy from the very start.

Our game was a lot simpler than WarCraft (not WoW) or Command and Conquer.  The player would have two factories that constructs your minions of bots.  The goal would be to get your squad of bots from point A to point B.  The rules of our game was a maze of turrets the bots would travel through and fight off to get to point B.  In the beginning the player is given a brief allowance of time to construct the bots, see the lay-out of the maze, where the turrets are positioned and so forth.  The player than would literally draw the pathing from manufacturer to destination and a line was drawn and visible to the player to confirm the routes the player is assigning to his or her troops.  Each Factory would have their own route the bots they each deploy would follow.  Then the game begins and an onslaught of tanks are released from their factories heading towards their assigned destination.

There was much concern about the player being static as all this played out, simply watching the action.  I don’t think that the idea of the player being static during this time should be of any concern.  It would just be turn based game play in essence and there would have been nothing wrong about that.  It seems that constant player interaction was the only kind of game that people expected to develop.  With that, we added the feature to be able to draw out and change the course of the bots on the fly sure during a skirmish.  Again, I had no issue with this.  It was a sound feature to keep the player immersed within our game.  During a second presentation of our idea, another thought that came to light was the feature to give the player a bot upgrade feature over time, however this would mean obtaining resources would be another element of the game.  This would be the defining change if we pursued it that would have taken the game completely out of the realm of tower defense, solidifying it’s foundation within a classic RTS model.

My task was to concept bots as our engineers developed the game.  Charlie and I were on the same page that if I was just working on conceptual design, specifically for the minions.  factories and turrets were secondary.  I didn’t need to draw out anything on paper first.  Charlie and I both thought just jumping into the design process in Maya from the get go would be more efficient.  Mainly because we only had 1-month to have a functioning white-box version presentable to sell the idea.  Keep in mind how I used the term white-box because I’ll be coming back to this.

During the course of Flux Disposition development, I was able to generate a decent amount of conceptual bots.  I also was able to have a basic turret modeled and used as an asset in our proto type.

Group shot

First concept

A bot that is quick an agile

Bot peripheral

Potential level 2 Bots.

Basic bot building blocks

Potential Bot Constructions

Fully upgraded bots.

Environmental Obstacle

After our final pitching process in front of a board of video game industry professionals, I was actually pleased to see the board argue amongst themselves on whether it was a proto-type worth developing further.  Mainly because all the members were unanimous in overall impressions of the pitches that were presented before ours.  In the end, we learned that Flux Disposition had the most polarized response from the board.   Apparently, an idea that can stir up the board of professionals as much as we did is not something that gets favor one’s video game idea.  Even if it attracts attention… the proto-type contained enough to show a solid game idea and get industry professionals to re-evaluate what it is that makes a good game should have been compelling enough to be selected.  Unfortunately that isn’t the case.

During the evaluation process, the proto-type was criticized for having absolutely no art during our presentation.  It is obvious for me that even professionals.  Retired journalists specifically that can’t see artistic efforts if it broad-sided that person with a semi truck.  Probably because that person would be questioning why he or she is waking up in the hospital confines in the first place.  Now, to return back to the assignment of having a white-box version of our game.  Charlie, our producer requested that nothing on the art side of things should go beyond this point.   We use the models as they are to demonstrate the game.  However, I was frustrated to only see my first bot concept be the face of the rest of the squadron.  I understand why however because in a white-box, you are putting emphasis on your core game-mechanic.  That is what the assignment was.

In any case.  Flux Disposition was put on the shelf.  In the end of the evaluations, our leading faculty made their decisions of the three pitches that would move forward.  Soon I found myself ironically in a project that attempts to take a classic game and reverse the roles of Player versus AI.  Last March of the Dodo, inspired by the classic game Lemmings, is where I have eventually found myself.  However, I will wait for the final installment of this post-mortem to discuss about Dodos.  It was around this time when both 2nd year and first year program affiliates spent time in San Francisco to attend the week long event of 2012’s Game Designers Conference.


Final Prototype of the Semester: Swordfighter

Heh.  Swordfighter.   I am still dumbstruck as to how well this project happened.  This video game was definitely the most successful prototype that I got to be apart of.  Before  I explain the game and present the art I did, I would like to mention that this final project was a special one.  Our client this time was a Doctor from the Engineering department here at the University of Utah who created a new kind of controller that could potentially change how we play video games.  Like Sony’s and Microsoft’s controller, There are two thumb sticks that is used for movement.  Bumpers on the front and 4 push buttons, two on both ends of the paddle that rests in the palms.  Doesn’t sound like much doesn’t it?  Now what if I told you that even smaller joy-sticks or nubs as they were frequently called, were situated in the very center of these thumb sticks.  These nubs were not installed for the Gamer to use in order to make something happen within any given video game.  In fact, it is designed to work completely opposite of that notion.  They called the tech that characterizes the two nubs, haptic feed-back devices.  Using tachometers installed within the prototype that give the nub to vibrate and move in one and nine directions in relation to positions on a traditional wall-face clock.  Consequently informing the gamer about something that is or about to take place at any given time. This potentially can  also free up clutter in the GUI,  That can obstruct the players view.  No more visual cues anymore that would tell us gamers how to react.

That brings us back to our final assignment and showcasing this new technology.  As a cohort, we were divided up into teams like it always have been. The goal as a class would be that each team should develop their own unique way present 1 of a number of other possible functions this new paddle can be put to use.  It was almost instant once we got together to discuss what our plan of attack would be.  Sword fighting Samurais.  Awesome.  I’ve been to Japan and got one of two undergraduate degrees in learning the language and culture.  This was right up my alley.  There was no question at this point.  We would make just one environment and two Samurai that fight each other similarly to that of a Soul-Caliber title.  Your basic Street Fighter.  The Haptic feed-back in one thumb stick would tell the player when an attack is about to happen and the angle it will come from.  Now as the player, your biggest source of character control are the two movable thumb sticks.  One stick gets used to communicate an attack to your samurai, the other is utilized as a way to defend against your opponent.   There are three rounds, you get damaged by an attack a certain number of times and you lose the round.  There are 3 rounds in every one match.  And that was our game and all we knew we would have time to do.  So with solid planning early on, we were able to make a simple game and polish it up to a degree that the player can feast on with his or her own eyes.

So without further ado, I shall conclude the Fall semester’s version of this blog with pictures of the 3D environment that I designed as well as a title screen, a credits screen and 5 splash pages that signify the different round and a winner/loser screen.  I also will present two other pages that would have represented a loading screen and a “Fight!” screen to kick off a match.  Since they were not implemented, I would hate for them to be created only to get deleted.  So I hope you enjoy!

Here is a YouTube video sample of our game in action.  Simply just cut and paste the link below into your search engine to view the video.  At least until I can figure out how to make a hyperlink to this URL.

Spooky Chimes: 3rd prototype project

The latest project I have had the pleasure to be apart of, is to create a prototype video game for Siena Entertainment’s Story Chimes as they attempt to move from interactive story and sing along books to actual games.  The IP that we worked with is based off of an idea that is still in production.  The Name of which is Spooky Chimes: The Great Trick or Treat Adventure.

We are all very proud of what we were able to accomplish in the 4 week time frame that was allotted.  This project has definitely been the most challenging.  I am in the process of learning Autodesk’s Maya, a 3D rendering program used for modeling and animation.  This program (I believe it is safe to say) is not user friendly.  With that said, my main contributions to the project was some basic concept art assets I made using Adobe Flash.  I also was able to develop two of the characters that will makes up The Spooky Crew.  The game mechanic should be described as you checkout my .png’s:

Tombstone A
  •  One of the Tombstones that got modeled and rendered. The player needs to dig into the graves to find an essential quest item.
Tombstone B
  •  This particular tombstone and one other were the main tombstones that got modeled and placed in our demo.
Tombstone C
  •  This was the other Tombstone concept that was created for the prototype.
The Witch’s Home.
  •  Initially intended for The Witch to stand outside of this particular structure.  The NPC will be stirring a boiling concoction, waiting for the children to seek her help.
Decor art asset.
  •  This concept was intended to be one of the alternative items that gets dug up from the graveyard digging quest.
Concept Spooky House
  •  This isn’t the same Spooky House that the Spooky Crew lives at.  This picture was used in our power point presentation when we initially pitched our idea.  The pitch included our intentions of what kind of game we would make and how we would go about making the prototype.
Quest Destination.
  • This gate is the end goal for the Spooky Crew.  The quest involves acquiring two parts of a key that is broken.  Once the 2 parts of the key are found and put back together.  The kids would then be able to unlock this gate and move onward toward a new area and can go trick or treating.
Center piece of the town.
  •   Here is a concept of a gargoyle being the center statue fountain of a water well.  In front of the well, we initially intended for an NPC that acts as the second quest giver.
Fence Decor Asset
  •  Concept metal fence that could be used to surround structures in the area we have currently designed.
Cauldron for the Witch.
  • The Witch is an NPC that plays the part of a quest giver for the Spooky Crew.  Within this cauldron brews a magic potion that will bind the two keys together.
Invisible Boy.
  •  This character will be one of the characters the player will be able to control and use amongst the other characters that makes up The Spooky Crew.  The player will have the option at anytime during the game to touch a character and that character immediately becomes the leader while the rest automatically follows.
  •  This is Frank and another character I produced as a member of The Spooky Crew.