Animation Principles

Looking at both good and bad examples of the Twelve Principles of Animation.

1. Squash and Stretch - Defining the mass of an object and its flexibility through motion and distortion of its shape.

Good Example:

In Pixar's first animated short "Luxo Jr" The smaller lamp bounces on a ball, the ball distorting in response to the weight placed upon it.

Bad Example:

In the online flash-based animation "Ctrl+Alt+Del The Animated Series" characters faces have no squash and stretch, expressions are merely pasted over the head. The lack of squash and stretch means that expressions look flat and stilted.

2. Timing and Motion - Spacing actions to define the weight and motion of an object/character in animation. Can also be used to show aspects of a characters personality.

Good Example: 

In Pixar's "Luxo Jr" the smaller desk lamp hops around a lot. The motion showing a lot of hyperactivity you would see in young children. The motion also gives it a sense of weight

Bad Example: 

http://www.youtube.com/watch?v=wtsek8E0eNY#t=4m0s

  

In the Ctrl Alt Del Animated series on the web, motion is choppy and gives no real sense of mass.

3. Anticipation - The preperation for an action

Good Example: 

   In "Luxo Jr" the smaller lamp is about to jump on the ball. The way it contracts its "body" like a spring before jumping is anticipatory of the jump that it's about to do.

Bad Example:

In CAD: The animated series this character runs towards a vehicle and just immediately jumps inside without any preperation. It looks off and makes the world feel as though it has a lack of physics.

Apple App: Week 4

The game has moved towards having a more humorous bent. The story line has been written. It was written to be comedic and light hearted. This ties in with the comedic and colourful art style. The idea being to make the game cheerful and friendly to all potential players.
The control scheme is based around the tilt action of the Apple Platforms. The only other controls being a pause and jump action. These are going to be areas of the screen and not buttons that get in the way.
The enviroments would be varied. Level concepts so far are: Burning building, sinking ship, A jungle being consumed by a lava flow from nearby erupting volcano. Middle of a city during an meteor shower, Monster attack on a harbour and  the escaping of a space station as it crashes to earth.
These enviroments should have enough variety to keep players playing on until the end.

Apple App: Week 3

I've decided upon modifying the setting of the game. Originally it was going to be set in real disaster areas. However I felt that there would be difficulty in building a narrative structure that encompassed all of the seperate disasters that would make up the game's levels. So thinking back to what inspired me; ie 1970s disaster movies I decided that the game itself would be set following a series of disaster movies.

Most of the work this week has gone into the art direction. Art wise i decided to go with a simple sprite based look similar to 8-bit or 16-bit platformers of the early 1990s. This is in part due to wanted to free up the Apple Platform's processor to dealing with the enviromental physics more than the graphics.
I also felt that simple cartoony 2D graphics would open up the game to more potential gamers. It also lessens the fact that the game is taking place in disaster areas. Cartoony stylised graphics will sanitise the setting.

Apple App: week 2

Looking for a setting for my game I decided upon using disasters as a setting. That would then explain how the player can control the enviroment, if the enviroment is already falling apart. So I looked at disaster films including The Poseidon Adventure, Towering Inferno and Armegeddon. The idea forming that the main character would be someone trying to escape these situations and needing the player to control the enviroment to let him through.

Ideas for ways that controlling the enviroment could work: Tilting the screen allowing a suspended platform to swing over to the character's position for him to run onto then tilting it over to the other side of a chasm or something to allow the character to cross.
Tilting the screen to allow water to overflow a container to put out a fire
Shaking the screen to cause a wall to crumble and fall.

It occured to me that this could turn into a puzzle game with the player trying to figure out what could be done to bypass obstacles. I though if that was added to the side-scrolling platforming idea then you would end up with a very frantic timed puzzle platformer. This would make it more necessary to allow the player limited control over the main character. A stop/start button perhaps as well as a jump command. However I didnt want to cover the screen in buttons as the smaller Apple Platforms already have fairly small screens.
But due to the screen being touch sensitive the entire screen could be divided into invisible "sections" that act as buttons. This is used in the app Star Wars Trench Run and it works well. This means the player can keep the screen clear, letting him see more of the action and without the controls being limited to "button areas" but instead being an entire section of the screen it would be easier to make snap jumps as the player wont have to be accurate when using his thumb.
But with the inclusion of the pause to allow for puzzle solving there is a chance to increase difficulty by removing the pause button meaning the game can have two levels of difficulty adding to replayability.

Another thought occured to me, if the player had more control over the character, say movement as well as jumping, then it could be possible to make the game have a versus multiplayer. One player playing the character having to get from point A to point B in this disaster area and the other player controlling the enviroment, using the tilt controls to cause scenery to topple and fall and the touch screen to direct lightning or other disasters.
This could work as the Apple Platforms do allow for wireless multiplayer. However controlling the player character would go against the main idea behind the game and would be a completely different experience from singleplayer. I believe if the mulitplayer experience is completely different from the single player experience then that will cause frustration for the player as none of his skills acquired playing singleplayer would be applicable to the multiplayer game.

Apple App: Week 1

When looking for inspiration for my apple app concept I wanted to focus on utilising the apple platforms accelerometer technology. It is the tilt-detection that I think makes the apple platforms stand out so I wanted to make them the star of the show.

Taking a look at games already on the apple platforms there is one called Canabalt. A side-scrolling platformer where the only control is jump. I liked the idea of a constantly side-scrolling platformer and wanted to impliment more control into it for the player. Originally I had thought about doing something atmospheric, maybe have a horror or survival horror game. However I felt the screen for the platforms was too small for a truly atmospheric game, that and the speakers aren't of a high enough quality for really atmospheric sounds

Linking these two ideas together I thought about designing a game where instead of controlling the character moving across the screen you instead controlled the enviroment via the tilt controls of the apple platform.
The idea being a switch of the classic platformer, instead of navigating a character through a level, you navigate a level around the character.

Problems with this would include the ipad possibly being too big and unwieldy for the tilt controls to be useful.
Also how much control should the player be given over the character? Would just jump be enough?

Another issue with the Apple Platforms. The screensize. With the Ipad it's not as big an issue, but with the Iphone and Ipod Touch the screen is just a bit small.  This is another reason why I wanted an app completely controllable through tilt motions. If the screen is kept clear of a control scheme and interface then the player can see more of the action and feel a bit more immersed. Also with a platformer where timing is essential I believe being able to see whats happening on the screen would be very important.

Board game development: Play testing

Our playtesters ranged from 18-26 years old and were a mix of male and female players. Some had experience playing board games before and some had very little interest in board games.

When playtesting our game we found that at first the combat system was a bit confusing. It was a rock-paper-scissors type of combat with certain equipment combinations beating others. This however caused a big concern with game balancing and our playtesters found the system itself fairly daunting.
So we went back to the combat design. Instead of equipment being good against one thing and bad against another we decided to make it a simple bonus system. This equipment will provide a bonus to your dice roll during combat. This was found to be much simpler and let the game flow much more. Play testers preferred the new combat system to the old and it made balancing the game much easier.

Aside from the combat, there was little else that needed balancing. A couple of issues, for example hyperdrive making it too difficult to defeat a player, were tweaked in order to make the game easier and more enjoyable.

Play testing the game at the beginning found that a game would last around 2 to 3 hours. However this could be put down to many things, a lack of familiarity with the game system, a convoluted combat system (that was later fixed). However after a couple of fixes to the system we found game time went down to about 1 to 2 hours on a full size board with smaller boards cutting the game time down even more. This was indication that the concept behind an adjustable board would work. Smaller board meant a smaller, less time consuming game.

By taking on board what our playtesters said we ended up with a game that played very tightly, it didn't drag on and everyone enjoyed it. One constant piece of feedback from every playtester was: "This is a fun game".

Board game development: Board

We had trouble with the board originally. The original prototype ended up being a bit too complicated for what we wanted. So after a redesign we came away with a board that fixed the problems of the previous board and retained what we wanted from the concept: A board that could be assembled in many different ways to make for a changeable playing area.

The end result was tighter and more visually pleasing than the original prototype too.