Archive for July, 2007
So I do. From Gamasutra news clipping:
A Casual Glut
On the casual game front, Hickey says it will be “very hard for the company to distinguish themselves in this market” with so many developers turning to the Wii with broadly-marketed titles.
“By CY08 we believe the casual game channel will become cluttered with games,” says Hickey, “most of which will not be good and will likely force retail game prices lower for the Wii,” which, he adds, can have “profoundly negative impact on a game’s potential economics.”
“The land slide of planned casual games,” he continues, “will also create havoc on retail shelves,” but he notes that EA “will benefit at retail by winning shelf space from smaller publishers/developers,” an important playing field with “relatively bulky” Rock Band on its way this holiday.
I think the growth is where Nintendo is heading – in the NON-gamer… i.e Guitar Hero, WiiFit, WiiSports, etc.. and that the hardcore gamer is being ignored to some extent to be filled up with quirky hardcore indie titles.
And I agree with broadly marketed titles comment. I wish games had more distinctive style than flashing triangles or generic minifigs… alas the cost of art is too great for small budget casual games.
July 30th, 2007
One of the four finalists in the “Great Canadian Video Game Competition” and it’s a programming by demonstration game – finally!
http://www.playarcadia.com/games_swarm.html

July 29th, 2007
I was ask to list 5 of my favourite games in an application form and had to think about it. I’d pick from this list:
- Jet Set Radio Future (Xbox)
- Loco Roco (PSP)
- Conker’s Bad Fur Day (N64)
- River City Ransom (NES)
- Super Mario Bros. 3 (NES)
- Bionic Commando (NES)
- Final Fantasy (NES)
- Pikmin (GameCube)
- Parappa The Rapper (PS1)
- The Neverhood (PC)
- Grim Fandango (PC)
- No Lives Forever 2 (PC)
- Need For Speed: Hot Pursuit (PS2)
- Indy 500 (PC)
- Populous (PC)
- SimCity (PC)
- Advance Wars (GBA)
July 26th, 2007
Having toyed with speech-based games and applications, I can say that Nintendogs uses it in a novel way.
The games doesn’t recognize words or phrases using a fixed dictionary, instead it asks you to speak the dog’s name and speak “trick” phrases that it stores as a phoneme list and uses that phoneme list to recognize what you say in the future – at least that is how I speculate Nintendogs is doing it.

Most speech recognizers want you to say their dictionary words in the “standard way” – any deviation, including accents, confuse the recognizer. Recognizers are typically large (memory-wise) and language dependent too… so for a game it’s overkill.
Here’s how I think the Nintendog system works: When I say my dog’s name – “Cupcake” – Nintendogs breaks that down to:
Kuh up Ke eh k
The recognizer is not looking for the English word “Cupcake” but rather a phoneme list that is similar to the above. This allows Nintendogs to use the same “speech” system for all languages. It’s brilliant and so simple! And works perfectly for the type of game they are using! And it’s not mouse click this and mouse click that… you are using your voice just like how you would with an animal.
July 25th, 2007
I’m releasing an OGRE-based game engine framework that is suitable for prototyping and creating music-based games. Tonight, I’m packaging up the source files for public release (zlib/lipng license) so soon the distribution should be available here:
Musicala SourceForge page
July 25th, 2007
NOT at all.
I know some rough numbers for Happy Feet and from the vgchartz.com website – it only lists the DS(250k) + Wii(60K?) when public reports state it has sold 1.8+ million copies.
Happy Feet sales 1
Happy Feet sales 2
The actual numbers are MUCH higher since 1.8M is from Jan 2007. And Happy Feet got terrible reviews – averaging less than 50% according to Gamerankings.com
Because people bought the game in droves, publishers will continue to make movie licensed games because people WANT them. Why they want them could be a number of reasons 1) Brand familiarity 2) Other games don’t “appear” to be as good 3) It’s actually a good game for it’s demographic.
Remember the word demographic… because even if you think something is terrible, it might be great for the intended audience. A case in point is High School Musical. A low-budget made-for-cable(!!!) musical that went ballistic – 40+ million CDs, millions of games sold, etc. I think it’s horrible (even though I like most kids stuff), but teens adored it and not because they were shoved full of advertising. Harry Potter had the same word-of-mouth following early on before marketing pushed it into the US as a blockbuster.
So who are buying these games? It’s not hardcore gamers for sure – it’s casual gamers or even non-gamers who love Happy Feet or High School Musical and then rush out to buy or rent the video game. They have no interest in playing the latest E3 buzz game or something from the Indie Game Festival… just like I have no interest in watching a French film showcased at Cannes.
Which means these gamers don’t exist in my sphere and I don’t exists in their sphere. As creator of entertainment (books + games), I create demand for my works and expand my sphere…
July 25th, 2007
The biggest surprise to me was the direction that Nintendo has taken the Wii with WiiFit. They’ve crossed the sacred line between casual gamer and NON-gamer. My friend in Montreal was gushing about how she loved her Wii and how fun it was… she’s a non-gamer (zero game playing experience). fLOw has the same weird appeal with non-gamers too (it’s not really a game either!), but few non-gamers have access to a PS3…

An analogy of how successful Nintendo could become is the iPod. Before the second generation iPod, MP3 players were for tech heads – computer savvy types like me who bought the Creative Nomad (a tank!) and the first gen iPod (it sucked). Now everybody has an iPod and doesn’t matter if they are computer savvy or not – the device has become accessible due to infrastructure (iTunes on Windows!) and ease of use. The iPod has become cool… mainstream… accepted.

Wii is heading that direction too. It isn’t there yet because of the current crop of games still doesn’t reach a wide enough audience. I can’t see Soccer moms wanting to play Zelda or even casual fare like Mario Party, but I can see them playing WiiFit / WiiYoga which leads them to WiiSports which then leads them Big Brain Academy at best.
The worst surprise?
While I admire Gamecock media for doing something different, their funeral procession was anti-establishment but actually was “the establishment.” When you are trying to create hype for your publishing company (brand) and not individual games then what are you truly selling that’s different from EA or Ubisoft? Nothing. Gamecock has become a brand… their name overrides quality. It’s brilliant, but not worthy of revolutionary. I support their endeavor to create satirical games, but hope the games they published are good and not shoveled out.
July 24th, 2007
For most of my game development career, I’ve sneered at game design documents for being irrelevant. I believed concept art, technical design docs, storyboards (if any animation), etc. were satisfactory in guiding a team to a finished game.
But when I started designing my own (somewhat larger scale) game, I discovered game design documents were less about “design” and more about “communication.” GDDs are essentially what screenplays are in film: blueprints that can be ignored, but keep the team focused and allows work to be properly divided beforehand.
A recent article on Gamasutra also confirmed my thoughts:
“It would be nice if game design consisted of sitting around with your feet up and daydreaming about cool content and features, and I’ve met some designers who thought that was the whole job. It isn’t; they were slackers. The vast majority of design consists of figuring out the details.”

Details… that’s what is so challenging about writing novels and screenplays…. details. It’s also what makes creating games so time-consuming also. Small game developers can organically grow their games, but any project with more than 5 people will suffers from “ill-defined-osis.”
July 24th, 2007
There, I admitted it.
I suck because I lack experience. I have always been the game coder and not the game designer. And while, I’ve been designing my first real game, I’ve realized that I am like when I first starting coding, writing novels, and screenplays – brutal.
To rectify this I should create a dozen mini-games to explore my gameplay creation skills and I’m NOT talking about creating a shooter or a platformer or another clone. I mean original/small games – whether in Flash or otherwise like Gesundheit!. A game that doesn’t feel… worn. It’s not a stupid shooter. It’s not a match-3 puzzle. It’s pacing and art is unique…
However, I’m knee deep in teaching and bootstrapping my company and it’s the first project so I can’t divert myself long enough to build these small games… unless I start organizing monthly game jam like how others organize monthly sketch sessions.
July 23rd, 2007
I’m in Montreal talking to ex-coworkers and their continuing struggles getting art looking “right” into their respective games. It’s amazing to hear how these gigantic studios are still struggling to get the fundamentals rights.
Anyhow, the process of putting 3D art assets into a game is called the “art pipeline” or “toolchain” or “asset conditioning” or how I call it generically “3D pipeline.”
The 3D pipeline has two major bottlenecks: software and people. Let’s ignore software one until a later post and focus on people. Oh the people…
Far too many producers and art directors think 2D assets can be managed like 3D assets: just create them and throw them into the game. Luckily this causes them to get fired or bankrupt the company.
The problem is that 3D assets like models, textures, and animations require more consistency and art direction that 2D assets like images. With 2D images, all that an art director needs to worry about is compression artifacts, film grain, gamma / colour uniformity. With 3D assets, there are scale, lighting, texture/UV mapping resolution, FPS, etc. issues.
Guideline for modelers:
- Use approved concept designs only.
- Ideally check for “3D” consistency issues between the concept designs that can make impossible to model. i.e Mickey Mouse’s ears can not be modeled typically in 3D – his ears always face the camera and are perfect circles. This requires a model + rendering hack.
- Use the same scale reference for all models.
- Know the polygon budget for the level/scene/world.
- Know the approx. polygon budget for your model.
- Understand how the model will be UV mapped if not by you.
- If you UV map, please keep it organize and try to use as much of the UV space as possible.
- For certain 3D packages, please clean up the construction history and temporary junk so it is not passed onto animators and texture artists.
- Check all normals for a consistent direction. In technical terms, all polygons should have a consistent winding order
- Check all polygons for T-junctions, bow ties, non-planarity and other degenerate problems.
- Reduce the number of polygonal intersections.
- If also creating physics collision meshes, keep them “manifold” – closed, non-intersecting, planar, etc.
- Check with riggers + animators on what areas of the model need to be deformed so more polygonal detailed can be added there.
- Preview all work regularly in the game or in a model viewer.
Guideline for shading + texture artists:
- Use a standardized lighting rig for all work – this guarantees shaders + textures created by different artists will at least be uniform (lighting-wise) in the game. If this is NOT done then a clean-up artists will need to fix all shaders and textures before the game can be shipped. In the film business this is the “colour timing” process, but in 3D it is lengthy and expensive – and requires art to be redone.
- Calibrate all monitors (if possible).
- Know your texture resolution budgets.
- Unless approved, do not use lossy compressed textures (tools will compress later). i.e. JPEGs bad. TIFFs, TGAs, PNGs, BMPs good.
- Try to create “unlit” textures as previous lighting will conflict with the in-game lighting. i.e Using photographs as textures is a bad idea because if say grass is being lit from the left by the sun and in the game the sun is on the right… the shadows will look wrong. The human brain can tell if something is wrong, but not always identify exactly what. This advice is crucial if bump or normal mapping, but not as important without.
- Ignore the advice if you are creating textures that requires “pre-lighting” or not using bump or normal mapping.
But…. Understand all photographs have pre-built in lighting that will conflict with CG lighting unless perfectly “matched.”
- If you UV map also, please keep it organize and try to use as much of the UV space as possible.
- Keep the number of shaders to a minimum – the game will perform better. Modern GPUs / games prefer fewer shaders due to the “batching rule.”
- Worry about texture stretching and texture resolution to object space consistency across different object. This is an advanced topic, but you can notice this problem in 3D games easily by comparing the floor/ground to the character. The ground is typically poorly mapped and textures are stretched/blurred but the character has clean + sharp textures.
- Preview all work regularly in the game or in a model viewer.
Guidelines for riggers:
- Know the maximum number of bones that can be assigned to each vertex.
- Check the number of bones assigned to the vertices (usually in the 3D package or examining the mesh XML file).
- No IK
- No constraints
- No complex deformers (lattices, wire deformers, 3rd party plugins, etc.)
- Name the bones! Something human readable.
- Normalize weights!
- Keep the rig simple, but too simple.
- Create nulls/locators/control curves for the animators, but make sure the exporter doesn’t export these.
- Add geometry when necessary, but avoid changing UVs / texturing when doing so.
Guidelines for animators:
- Know the frame-rate in which you’ll be animating to.
- Understand the animation curve limitations of the game engine – linear curves, splines, in and out tangents – so you what you are animating will look as it does in your 3D animation package.
- If cycling an animation, check for that the first and last frames match. Better yet, copy the first frame onto the last frame.
- Keep track of the stride length (the distance a character walks in one cycle) – this will prevent feet from sliding.
- Feet will almost always slide in 3D games, but it’s best the animation cycles don’t have that in the first place!
- If you use constraints or IK or an advanced animation tool you may be forced to bake out the animation into keyframes.
- Don’t bake out all your keyframes unless told by a TD/programmer.
- If you are also the rigger, consistently name the bones and keep the number of bones to a minimum. A named bone can be exported and used in a game easier than joint34124.
- Preview all work regularly in the game or in an animation viewer.
Will continue with the software side next week and polish this posting up at a later date.
July 20th, 2007
Previous Posts