Updated. The ending isn’t finished, but it’s getting there.
Dec
05
2011
Mississippi Mud Pie – Alligator Model Sheet
Well, it’s been a full week since I last updated, so here we go. I’ve been working out the alligator character so that he is animatable and sensible to work with. Surprisingly, there was very little to work out from my original design, just minor simplifications here and there. Specifically, the scutes on his belly and the frills on the back of his head. Instead of the frills going all the way to his tail, he only has four – three on the head and one on the upper back. And the scutes are formed only on the belly and tail – using the sphere form of his stomach to create the upper ones (one at the top, one at the bottom, and two splitting the sphere into thirds), and the cylinder forms for the ones on the tail. The chest area, on the other hand, has no splits in it. After a few attempts, I can get him roughly on model consistently, so that must count for something.
Still to do: Man model sheet.
Nov
29
2011
Preproduction – The Unbearable Stiffness of Using Maya
I’ve decided to do my film in 2D instead of 3D. The reason for this is not because I dislike Maya, or hold any particular grudges against it – it merely isn’t suitable for what I want to achieve. The low poly models I’ve created will go into my portfolio, and I will be still using maya for some background assets and other things. But, for now, at least, the story I am to tell, the movements the characters will make, will be in 2D.
Nov
08
2011
Mississippi Mud Pie – Character Texturing
Today I have been texturing my characters.
Neither are 100% finished, but I think I have made enough progress to post an update. Once these characters are complete, I will work on the environment.
The man is demonstrating the flipped normal polygon shader I researched, which is actually quite elementary. It will form the basis to most of the objects in my film, as I do not have enough polygons to do everything I want with the characters and props. His ear is the most obvious beneficiary of it.
Along with the UV Offset controls and Flipped Normal shaders, I will also be researching other ways to make my film look good while minimising the amount of work the renderer has to do. For example, a fake fresnel shader made with facing ratio hooked to transparency and some kind of colourisation. I’d know how to do it in a game engine, but not Maya, surprisingly!
Nov
02
2011
Progress Update – Posh Man Complete
And unfortunately, 400 polygons over budget – but for a reason. Most of the extraneous mesh is to make deformations more pleasing on the big screen, something I could get away with half the total on a games console.
Update:
Aligator: 100% modelled, 100% UV Mapped, 0% Rigged.
Posh Man: 100% Modelled, 100% UV Mapped, 0% Rigged.
Nov
01
2011
Progress Update: Character Meshes
Now that the animatic has been made, I can start work on the 3D models for the characters.
Since there are two characters within this short, I can spend a lot of time on them. I found out early on that using absolutely authetic methods for creating the characters is unfeasable – in a film you would need a lot cleaner, deformable meshes, so I increased my initial poly count limit from 600 to 800 (not including external “flair” mesh). The current mesh progress is:
Aligator: 100% modelled, 100% UV Mapped, 0% Rigged.
Posh Man: 80% Modelled, 0% UV Mapped, 0% Rigged.
Here are some progress renders:
Oct
26
2011
Mississippi Mud Pie – Rough Animatic
Finally finished the first pass of the animatic, had to go in and actually animate some of the shots to get them to read.
1:51, just under my 2 minute cutoff point. I’m pretty pleased with it.
Oct
21
2011
Mississippi Mud Pie – Movable eyes on a static texture.
One of the challenges I have to face when doing a low poly piece is getting the right amount of subtlety when there isn’t enough geometry to accomodate for it. One of the subtle things I like to do is have nice eye movement in a character, so that they aren’t blankly staring out into space while performing their action – something that is a death knell to PSX characters rendered in high resolutions.
I had to create a method of moving the eyes cheaply and effectively, to keep within the zeitgeist of the era I am mimicking, while lifting the work to a new level of sophistication. To do this, I created a layered shader:
The Pupil – Just the eye, in the middle of a texture. It moves by changing the UV Offset attributes. An Alpha map is created to fill the entire eye area, eyelid included, so that no whitespace is visible where it shouldn’t be.
The Eyelid – This alpha map simply cuts out the eyelid so it can be placed upon the eye.
I created a proof of concept render with some programmer art, and it worked out pretty well. I faked an aim constraint by using a set driven key to drive the UV Offset with the XY translate attribute of a nurbs circle.
Since this is just a test, I plan on several improvements:
– Driving several eye expressions with the same nurbs controller.
– Using image sequences to drive eyelid expression with eyelid alpha and pupil alpha together.
– Changing the size of the eye area, the pupil, and enable complex deformation as to create smear-frame substitutes.
Regarding rendering, using a flat plane is inefficient for viewing the eye from different eyes, so two angled planes would be better, so that from the side, there is the illusion of three dimensionality. Another two faces need to be present for proper deformation.
Oct
21
2011
Mississippi Mud Pie Model Sheets
I’m well into the preproduction for my newest animated short, “Mississippi Mud Pie”. Here are some model sheets for the two characters. Animatic pending!
The main character is an alligator. I wanted him to contrast the posh man, so I made him short, squat, and with big, expressive eyes. It was difficult to have a chunky character who also has a high dynamic range of movement. To counteract this, and make him look more like a gator, I opted to make his upper arms thin so that animation wouldn’t be hindered by having to take into account fat deposits there. It also gives a rather nice contrast between body and forearm.
The hardest part of the design, and what required the most redrafting had to have been the legs. I tried to come up with a compromise between my usual “stubby” choice and the more lithe, but more animatable legs I kept drawing for him. The wholly stubby leg design would limit animation and movement.
The Posh Man is the polar opposite of the aligator. Tall, lithe and composed, with a large cranium and hat (compared to the flattened cranium of the gator). I think the contrast will be fun to animate.
Aug
28
2011
Veritas Ex Machina: When Mechanics Break a Game
Here are a few muses I have regarding jarring mechanics in videogames.
A lot of complaints people have about promising games is that there are certain parts that do not gel with the expectations built up by the rest of the game. That is to say, there are certain parts that do not seem to take place with the same laws or tenants.
Imagine you’re reading a book. You’re thoroughly enjoying it, it’s a pretty standard genre piece, but at a pivotal moment, it turns into choreography for a baroque dance. This is an unsettling experience, since you are not familiar with dance, you just want to read your book. Unless the book you’re reading is House of Leaves, it’s probably something you don’t want in your library.
Why, then, do we accept this in videogames? Part of game design is to create a consistent, believable (if not realistic) world for the player to play in. The player should not be asking at any point “Why can’t I use the other mechanics to solve this puzzle?”.
There are a couple of types of immersion-breaking inclusions.
The Broken Cog
Sometimes, it’s just one thing that when included, will break a game. Something that runs against the stream, makes the machine that is the game hiccup occasionally, but will nonetheless mar the experience for the player.
One big thing in videogames recently was Quick Time Events. Every game had it, and it seemed like a cheap way to make cutscenes interactive. It’s an old mechanic, from the days of Dragon’s Lair. But in most games, it didn’t mesh with the rest of the game – players were left frustrated that they had to use twitch reflexes to solve something their mind wanted to do. But it is not the quick time event itself that is to blame – games like Heavy Rain show that consistent use of this oft-hated mechanic can create a good game. But even within itself, Heavy Rain is consistent. Buttons do particular things, and never change. But Resident Evil 4 will randomise the buttons in it’s QTE segments. This was a major complaint amongst players. It just didn’t feel right amongst the survival horror.
Most recently, however, a bruhaha has begun amongst players of Deus Ex: Human Revolution, over the inclusion of mandatory boss fights – something taken for granted in a lot of games. DEHR advertises four different styles of play, but the boss fights facilitate only one. Whether or not this is intentional is not part of this discussion – no amount of rationalisation can subtract from the fact that this breaks immersion three out of four times a player encounters this situation, since it is asking for a gameplay style they have not chosen to play. No matter how many interesting, immersive features you add to a game, the inclusion of one which jars against the theme you have decided will ruin it.
The Incredible Machine
Sometimes, however, a game will try to do too much. It will try to be everything, mechanics wise. A good example of this is Uncharted: Drake’s Fortune. It contains four distinct sub-mechanics:
While the Quick-Time Event system is a given, there seems to be a dichotomy between the platforming and the cover-based shooting sections of the game. Neither blend together very well, and all attempts are forced and rather lukewarm. This is because the shooting subsystem is designed counter to the platforming, that is to say, the cover shooting has to stay in one place or duck into cover, while the platforming has you jumping around and being dynamic. Having to stop one style of play and pick up another is cumbersome, and especially in a game where the protagonist is shown to have the reflexes of a rhesus monkey, cover based shooting just doesn’t work. I can see why it was in Gears of War, but I can’t see how it was in Uncharted.
A better implementation can be seen in Assassin’s Creed, where the combat system encourages you to move from place to place and never stand still, so the transitions between the two subsystems are fluid and seamless, instead of being audible gear changes.
An older example of two subsystems that work together but have a distinct difference is the Core Design version of Tomb Raider. In Tomb Raider, the protagonist had two modes – platforming, and shooting. Drawing your guns (of which there are two, to avoid having to program in clinging to ledges and shooting simultaineously – more on that in another essay) activates a combat mode which is very primitive and rudimentary. You shoot, and you continue to move and jump in order to avoid your enemies’ attacks. Entering the combat mode robbed you of your ability to cling onto ledges, but it [i]did not[/i] rob you of the ability to do your basic platforming moves. Enemies were few and far between, and often the most entities fighting you were three or four, as opposed to the countless waves in Uncharted. While your health was finite, you could withstand a lot of punishment before dying.
Another game whose design works against itself at all turns is Alone in the Dark 5. It is a survival horror, with shaky handgun controls and scarcity of ammo, but it requires precision aiming to defeat even the most rudimentary of enemies. It has “realistic” vehicle controls (that also crop up in games like GTAIV, but done much better) but demands action-movie style driving for it’s vehicle levels. You cannot design a game for one purpose and force it to do another.
Conclusion
So what can be done to stop all of these problems? Not much, unless you have a super organised team who is willing to make sure the game is tested in the right way (for game enjoyment rather than just bugtesting). When in preproduction, game design choice should be based on the style of game you are making, not on what mechanics are popular. This is a problem that has always been in games – back in the early 90s, games inexplicably became 3D without regard for how this would change the game’s paradigm. The refusal to publish 2D games by some publishers (like Sony) resulted in hasty and poor game design decisions by designers who had very little experience with the style of game 3D is made for (Simon the Sorcerer 3D being a prime example).
The Design of a game is just as important (if not more so) as it’s story, sound, graphics or engine. It must harmonise with itself, be believable in the context of the game, and most importantly: Never make the player angry at it’s existance. A player can be frustrated at their own skill, but if they feel the game has cheated them by including a broken mechanic, that is a black mark on the game’s report card.