Casually Hardcore devlog

Artists sketch all the time, so what do programmers do?

Ever notice artists always doodling? They experiment and experiment and experiment… programmers read and read and read, but not too many go out and create something.

Well, I’m going to continue with my little 2D / physics experiments for a while and treat it like artists sketching – crap but a skill-building exercise.

Add comment September 27th, 2007

Tech demo kinda of finished… (old post)

A couple of things worry me about my current project. My characters have large number of polygons and a large number of bones…. added to the fact I have large scale environments.

Prototype (fully playable) starting real soon now

Add comment September 27th, 2007

People bottlenecks in the 3D pipeline

Last time, I discussed the “people bottleneck” in the 3D pipeline (aka getting 3D art into the game). This is a MAJOR problem in the game development process. How does one get a level + character + animations into a game AND have everything interact properly? Well, let’s look at an example.

I have the following things in a 3D fighting game:

• Office room
• Door
• Table
• Two chairs
• Policeman
• Robber

I need to:

• Model room, door, table, chairs
• Model policeman + robber
• Texture room, door, table, chairs
• Texture policeman + robber
• Light room, door, table, chairs with policeman + robber
• Rig/weight policeman + robber
• Animate policeman + robber
• Name animation cycles and record metadata of animations (i.e stride length)
• Build collision meshes for room, door, table, chairs
• Build collision meshes for policeman + robber
• Build pathfinding mesh (probably not need in this case – just go with me)
• Add collision metadata properties like “wood” or “metal” to shaders or objects for use by sound code
• Add collision metadata properties like density, friction, etc. for use by physics code
• Add collision metadata properties like mud, concrete, quicksand, etc for use by game/AI code
• Layout door, table, chairs + characters into the room
• Add locators/triggers/bounds for use by game code
• Export all the above into a format for the game engine

It would be utterly foolish to go into a production without any tools. Stupid, stupid, stupid.

A game engine is only half the battle. Art tools provide you with the rest, but even with the greatest tools getting art into the engine is problematic because of the sheer amount of data and complexity.

Better training and experience improves the end results. Sadly, many artists in the game business have less than 2 years experience and can’t be relied on understand all the complexities of exporter(nor should they). And in the future, this problem will get worse because of increased specialization and the enlargement of dev teams. Artists shouldn’t need to understand their entire exporting process either – why does animator need to know non-planar polygons are bad or that NURBS aren’t supported and that’s why his animations aren’t exporting?

So tools are not the answer to all our game development woes (but they are your friends – look at the friendly tools above. I worked on that show). They are a starting point…

How do we make game development smoother by reducing the bottleneck in getting art into a game?

The answer: Process (often called art pipeline or pipeline)

1. Programmers will hate me.
2. Artists will hate me.
3. Managers will hate me.
4. Producers will like me.

A process is NOT a MS Project schedule. That’s just a schedule. A process defines the workflow between artists, coders, art directors, lead programmers, etc. This is why I think SCRUM is getting popular in the game industry. The game industry doesn’t have well-defined processes in place so it compensates by having regular meetings and ad hoc processes.

The process :

• Divide work into assignable chunks.
• For each chunk find dependencies and create a dependency/workflow graph.
• Insert approval checks between major chunks.
• Design and write tools that export/process data between major chunks.
• Assign chunks to people.

Simple, eh?

Let’s revisit our original example and start with just the room + props

• Modeler #1 – Model room, door, table, chairs
• Modeler #1 – posts models to webpage or common area for approval
• Art director – approves or rejects room, door, table, chairs
• Art director – makes comments on webpage/e-mail
• Modeler #1 makes changes
• Modeler #1 – posts models to webpage or common area for approval
• Art director – approves or rejects room, door, table, chairs
• Art director – makes comments on webpage/e-mail
• Texture artist #1 – Texture room, door, table, chairs
• Texture artist #1 – posts models with textures to webpage or common area for approval
• Art director – approves or rejects room, door, table, chairs
• Art director – makes comments on webpage/e-mail
• Texture artist #1 makes changes
• Texture artist #1 – posts models with textures to webpage or common area for approval
• Art director – approves or rejects room, door, table, chairs
• Art director – makes comments on webpage/e-mail
• Modeler #1 – Build collision meshes for room, door, table, chairs
• Modeler #1 – posts meshes to webpage or common area for approval
• Lead TD or programmer accepts or rejects collision meshes
• Lead TD or programmer – makes comments on webpage/e-mail
• Modeler #1 – Build pathfinding mesh (probably not need in this case – just go with me)
• Lead TD or programmer accepts or rejects pathfinding meshes

Now imagine there are 10 modelers. That’s a lot of communication (and models) flying back and forth. Many models will be in varying approval states…

i.e The door might be fully approved and just textured, but the table might be back at shape revisions. Do you really want a manager/producer/co-ordinator to babysit all of this? Every human in the process that isn’t doing the work is just another bottleneck and a potential for miscommunication.

Tools like exporters and previewers assist the process by reducing the workload of the art director and lead TD/programmer. 10 modelers verifying their work is MUCH BETTER than one art director trying to export the models himself/herself and then having to perform “art direction” duties also.

So tools are core to the game development process. We use them to:

1) Automate exporting art and metadata into a game (i.e exporters)
2) Facilitate communication (between mostly artists).

E-mail is TERRIBLE way to manage and track a production. Sure you could track art progress/progression in an Excel spreadsheet, but it won’t be usable by others (art directors + artists) simultaneously. I’ve tried the common webpage method and the Excel method. I think the Excel method is for small studios only. If a studio thinks they can manage a team of 20 using a single Excel file to track art progression – RUN!

So then the answer must be – “we’ll hire more associate producers and coordinators!” Unfortunately that’s a band-aid solution and a complete waste of resources. They are overhead. They don’t produce any content. They suck up budget. One producer, a couple of leads, and well-defined process is all is required in game development. Micro-managing content is a waste of time for everybody and the seed of miscommunication. The core problem is the shear of amount of data pass around to a small number of people – art directors, lead programmers, producers, etc.

If a process is mature enough, i.e Halo 7, then parts of it can be automated. Automation is the end goal. The fewer the number of people that need to be involved in creation of a single asset (i.e model) the fewer the errors. We all understand how error prone humans are.

What are the downsides of a process as demonstrated in my 3d fighting game?

As we tried to remove management by automating the process and setting up a common communication system, we created a little inflexibility into the system. To get a character changed would require repeating all previous approval steps. No longer can you just assign the work to a modeler and merely mark the entire thing as “done” when it comes back. Textures artists and lighters will probably need to look at the modified character briefly before approving it.

In real life, we have laws and bylaws on how humans should operate, but it’s up to the police and judges to enforce them. In our process we are defining how art progresses from an idea into a finished product in a game. Our enforcement is partially done by computer-based tools and partially by humans. Any time there is “an exception” that breaks our laws, tools need to give the exception a pass. A human can deal with exceptions, but poorly designed tools hate them. Tools should not be so rigid as to reject even the slightest of errors. Sometimes bad assets are usable… (like non-planar polygons) . The cost to fix the bad asset is not worth the reward. Tools should only flag problems, but not halt productions.

So why aren’t studios doing this? They ARE! At least the big ones with experience. Many of the job ads I’ve seen are for tool programmers and the salaries are quite high tool. And a few studios are hiring a small armies of pipeline engineers to assist in developing pipeline/process tools…

Add comment September 27th, 2007

Great Canadian Video Game Competition winner – MindHabits

A brilliant idea backed by research…

Too bad people will lump this game in with Brain Age – which it isn’t. Good marketing will be needed to overcome this ignorance. Actually, being associated with Brain Age wouldn’t be a bad thing, even though the game itself has completely different goals.

Congrats to MindHabits! I hope to see this on the shelf one day!

Add comment September 27th, 2007