T=Machine

So, here’s a question for Agile developers: when you’re using Scrum as your development process, and your game is in pre-production, at what point do you move to Production? And, more importantly, how can you tell (that you’ve moved)? Is Scrum in fact a permanent Pre-Production, right up until the moment you launch? And if that’s the case, how do you explain THAT to your publisher?

Traditional process

There are three stages: Concept, Pre-Production, and Production. Every game goes through those processes in that order. Typically the number of staff working on the project (and hence the amount of money being spent - and the risk being taken on!) goes up by a large factor from stage to stage.

Rather than bore you senseless here if you already know all this, I’ve written up a slightly more detailed explanation of games production stages and how they relate to each other. If you aren’t familiar with those stages, read that instead.

What is Pre-Production, anyway?

Well, as one of my colleagues, Mark, put it: the whole idea of a Pre-Production/Production split is merely an artifact of the developer/publisher split in responsibility, funding, project ownership, etc. It’s there because the developers can’t answer most of the questions until they’ve actually written most of the game, but the publishers are desperate to “reduce risks” by “eliminating unknowns”.

I did a quick google to see what other people have said about pre-prod for games, and one of the first hits included the quote “PreProduction has become the most important phase of the development cycle”. Actually, I think (like Mark) that Pre-Production has always been the most important phase, as far as the developers are concerned, although usually it’s never allowed to last long enough to be that important in the overall project. Despite being usually much shorter than Production, with much smaller resource (many fewer staff, etc), arguably it’s where the true art and craft of making fun games happens. Everything that follows is an attempt to fit the square peg of game development into a round hole, to curtail changes, to control spending arbitrarily, and to fulfil the vision that’s created during pre-production without allowing for the possibility of the team changing their mind on what’s going to make the game fun, or a success.

…which coincidentally brings us full circle, as this is one of the biggest reasons that game developers are trying to adopt Scrum in the first place. Scrum promises a large amount of “changing your mind” whilst keeping budgets and spending very efficient - even, magically, promising even tighter levels of control of the spend whilst granting much much more freedom of creativity. Yeah, you can have your cake and eat it! (unless the cake is a lie)

What about the movie industry?

Well, yeah, because the term “pre-production” comes from there first. I guess - just a wild guess here - that it got imported to the games industry by EA, probably around the time they imported the job title “Producer” to mean, a la movie-parlance, someone who combines organizational and creative responsibilities (a merged lead designer/project manager).

“In digital video, photography, television and film, pre-production refers to the tasks that must be completed or executed before filming or shooting begins. This includes tasks such as hiring actors or models, building sets, budgeting, planning, scheduling, renting equipment and tests, to name a few of the many pre-production tasks.”

Here’s the problem: whereas a movie starts with a FULLY WRITTEN script, the game design for a game is never complete until the day you ship. That means that where a movie has the luxury of looking at the script on day 1, and starting to do things like “building sets”, the game equivalent can only be guessed at for the majority of the project lifetime. Pre-production, in a movie industry sense, is impossible and nonsensical for the majority of computer games development. (leaving aside the exceptions of the few games, such as the infamously sequel-tastic EA Sports titles, where the game design doesn’t change and has very little innovative or new added during the course of the project. For anyone not in the industry, FYI: those are rare in the overall constellation of games developed each year).

Scrum and the effect on game production

With a Scrum project, you are ready to *ship* the product every single month (or fortnight, or even week, depending upon your sprint length). If you start by using Scrum at the concept stage, as we have for some of our projects, then … how do you decide when to transition to pre-production? And, more importantly, when to transition to Production?

Because Scrum, as far as I can see, is granting the development team an infinitely-long Concept stage (or, at the very least, an infinite Pre-Produtction stage): at every moment they are free to take any part of the product and throw it away and replace it with something better. One of the great mantras of Production is “thou shalt not throw anything away … unless there’s no way the game can ship with it in current state (and that usually doesn’t apply until you’re really close to shipping”. I’m not saying that’s a mantra anyone chose, I’m observing that de facto it seems to be how publishers and producers end up handling the Production phase. Maybe I’ve just seen a lot of bad examples - but I think not. I think this is an inevitable side-effect of the “avoid risk and avoid extra expense” strategy that the publishers have chosen as the purpose of Production.

So … if you’re permanently in pre-prod, how do you decide when to go to the publisher’s GreenLight committee (or whatever your publisher calls their equivalent)?

It occurred to me that the answer, with any publisher that understands Scrum, is: You don’t. They come to you.

The Power of … Scrum

Every time you finish a sprint, the publisher should have at least one representative turning up to the review meeting to see what’s happening and what’s been changed/completed/added/removed.

They should also be making a judgement every single sprint of: as a publisher, do WE want to “move this ahead” into pre-production, or from pre-production into production.

This is one of the explicit aims of Scrum, to give the person who’s commissioned the project (i.e. the publisher, who’s paying for all this development!) the ability to make extremely well-informed decisions about the project at any point. They are informed and empowered. So, they need to take that power and that information and decide for themselves what to do.

Fundamentally, the decision was never in the hands of the developer, and with Scrum, I think that maybe it doesn’t need to be something the developer is even all that aware of any more. Old-style, you have to explicitly make a special final build for the end of Pre-Production - but with Scrum, you’re doing that all the time anyway.

I could be completely wrong, of course…

I see this as one of the interesting unanswered questions with Scrum for games dev, of which there are many, all in the area of “Ok, sure, we can all see how it fits in with day-to-day development - but how the heck does it affect the traditional developer/publisher relationship, and how does it alter the traditional processes that exist in that area?”. Scrum, in its mainstream incarnation, doesn’t deal with a developer/publisher relationship - no surprise, really, because almost no other software development industry has such an odd dynamic as its centra driving force.

But what the heck. Here’s my stab in the dark at this small part of it. I’d love to know what you think.

What is Pre-Production in games development? What is Production? What’s the difference?

I’ve just written a (draft) post that requires you to know those things well before it makes sense, and I started off by including a grossly over-simplified idiot’s-guide to these things. Then I looked back and saw it had become as long as the main post itself, and I didn’t want to cut it because it explains a lot of my (possibly wrong) assumptions. So, here it is. The other post - the one I really wanted to write, will be along shortly :).

Traditional process

Splits into 3 sections. I’m talking about all games here, not MMOs in particular (MMO’s add some extra stages, like “post-launch” and “beta” which have a LOT more special meaning that many mainstream game developers realise, but those are mostly handled by extra dev-teams, so that the main development process is still almost the same as with normal games)

Concept: Summary

Someone has an idea for a game, often a lead game designer, but also often NOT a designer (incidentally, it’s often an Exec Producer, since they will be the one who has to recruit the entire team, drive the project, and ensure it’s a profitable success). They get together some basic sketch of the game design, maybe only a few pages, plus some artwork to show what it might look like - look-and-feel stuff - and any other materials that help to explain the idea.

Concept: Output

They write a Powerpoint presentation, basically nothing more than that.

Concept: Gate to next stage

You “pitch” this to the publisher; if they give concept approval, and some money (or just free resource for an internal studio), the project goes ahead.

Pre-Production: Summary

A small team of people is assembled. For a simple flash-only casual game this could in fact be literally one person, or two people. For a AAA first person shooter, it’s likely to be around 5-10 people, an equal mix of artists, designers, and programmers.

Time-out for a moment here: a big point of variation exists here. On many projects / with many publishers, the artists produce most of the concept art in the Concept stage. On others, they produce most of it in the Pre-Production stag. Concept art doesn’t require ANY tools, engine, or game design - mostly it just comes out of the artist’s own fertile imagination. It’s usually “inspired by” the basic concept that the vision holder explained to them. Often, the vision holder and/or design team uses the concept art to help them refine their own ideas of what the game is going to be. It’s a highly mutually-supportive process. Doesn’t have to be, of course - depends how clear and how precise the original vision is.

Another time-out: some companies regularly have the programmers produce a working demo at the end of pre-production. IMHO, this is the first running leap along the slippery slope to destroying the developer: any working demo that’s held up as “illustrative” of the final game constitutes the majority chunk of development risk and spending for the entire game project. A publisher who asks for a demo at the end of pre-prod is being very wise - they’re asking for the majority of all the development risk to be removed before they fund the main game. But they’re also being incredibly greedy, and incredibly stupid - the demo either will have very little to do with the final game, or else it will push the developer towards going out of business, because there’s no way they can pay enough staff to get a demo done on the tiny budget that a publisher will unlock for pre-production. Publishers typically justify this with “it’s only pre-production; you don’t need much money”.

OTOH, many publishers have been operating massive pre-productions, which means that they can get that risk-stuff taken care of without being greedy/stupid. Pre-production periods lasting *multiple years* are happening a lot in the MMO industry these days. I did a double-take when I first saw that, but no-one else seems to be batting an eyelid at it. So, I’m not bashing all publishers here, just pointing out that it’s quite widespread to be naive about what’s reasonable, and that there’s a lot of bad contracts out there.

Pre-Production: Output

Enough of a game-design, enough of an art-direction, enough of a technical specification, enough of a project schedule / GANTT chart … that the leads (design, art, and code) and the Producer feel confident to state “yes, we can make this, for that much money, and it’s going to be a GOOD game”.

Pre-Production: Gate to next stage

Publisher listens to the arguments from the leads + publisher, either written or oral (usually a mixture of the two), then examines the evidence (should be plenty by this point, either as artwork, or as a series of small demos of different technologies, or demos of small aspects of gameplay, or as formal game-design documents detailing how the game will work), and a bunch of highly experienced and highly-paid senior people make a judgement call on whether this game is really going to work, whether it will be worth it, how much money it will make, how it fits into their ongoing sales plans as a publisher, and whether this development team can actually deliver on their promises. If they like it, they release the majority of the development budget and the game is “green lit” to go ahead in “full production”.

Production: Summary

Well, now the leads and the Producer go ahead and make the game they said they were going to.

Do you see a problem?

Has anyone yet written a predictive measure of “fun”, or worked out how you can “plan” for a game to be fun before you’ve actually written it and *played* it? Not really (though there are many good attempts out there…).

So, who is Pre Production for, and who is Production for anyway? I reckon the former is for the Developers, and the latter is for the Publishers. Certainly, it’s always the Publisher who makes the final call on whether a game moves into Production or not - although obviously the developer has to make a judgement call on when they think they are ready to submit themselves to that judgement. In practice, external dev teams often run out of pre-production budget and so the decision is forced upon them to a certain extent, whereas internal teams can - if they’re politically skilled enough - carry on coasting for quite a while longer.

If you do much work administering linux servers - or, especially, if you DON’T do much, but occasionally need to - then it’s a massive time saver to be fluent in one of the text-based file editors that are found on all versions of Unix. As a developer working with game servers, I’ve found the effort invested in learning VI has paid off enormously over the years - I don’t use it as my editor of choice (I use a full fat GUI, either Visual Studio if doing C/C++ work, or Eclipse for Java/most other things), but when I’m stuck on an SSH connection needing to do some quick editing of local config files, or to fix a script on a remote server etc, it’s very very useful to be confident and effective with a text editor.
(more…)

We were talking about backups recently, and I remembered one of the things we did at MindCandy to great success that I now consider essential to any online game which has a live database: use your live backup as the input for all your development machines.

NB: this is all about backing up LIVE SERVERS, not backing up your development machines - if you can’t make your development backups work perfectly then you have serious problems and need to get some better IT personnel. I’m not covering that issue at all: that’s just standard to any technology company!
(more…)

Slides from my second ION talk are here (this was the last session on the last day, so very few people made it along - slides for the first talk (which are probably what you’re looking for) are here). I don’t think anyone blogged this talk - sorry!

I’m helping out with a student game-programming competition at the moment - Dare 2 Be Digital - and we’ve just had a day of judging pitches from teams, trying to decide which ones to allow into the full competition. During the pitch process, a few pieces of recurring advice came to mind. We were allowed to advise, but since the day was mostly about deciding who to let through to the next round, there was very little time left over to give each team any specific comments (we had to focus instead on asking searching questions :)). For those that get through to the next round, they’ll get properly and intensively mentored, so it should be fine but I thought I’d throw my thoughts up here (and maybe some readers will want to add to them?)
(more…)

Robert Mitchell, Sony Online Entertainment

Summary

Interesting to see what they’re doing, we’ve been looking at a lot of similar stuff recently. If I were in their position I’d want to try hacking the IDE to make it integrate with their build system directly - the speaker said that highly integrated build systems are a must for this stuff, but that doing everything inside the IDE with no external clicks or actions (like a “check in to perforce” action) was also essential. You can’t do both 100% without modifying the IDE; I’ve done that before for stuff we did for PXC, and it works like a dream, ONCE you’ve got it working ;).
(more…)

(I’m quoting a very handy short extract from Clinton Keith’s December 2007 Gamasutra article, so that I can find it again easily later. Clinton is/was the CTO of High Moon Studios, and is probably the most well-known proponent of Scrum in the games industry. Rather than wade through the whole article when I want to pass on some of his advice, I wanted to be able to copy/paste the relevant sub-bits)
(more…)

(I’m quoting a very handy short extract from Clinton Keith’s December 2007 Gamasutra article, so that I can find it again easily later. Clinton is/was the CTO of High Moon Studios, and is probably the most well-known proponent of Scrum in the games industry. Rather than wade through the whole article when I want to pass on some of his advice, I wanted to be able to copy/paste the relevant sub-bits)
(more…)

First, check whether I can actually render Korean characters. I know that Unicode supports nearly all of the glyphs (or, more correctly it seems, “ideographs”) needed for Chinese, Japanese, Korean (typically abbreviated as “CJK”) - but I also know that MS Windows fonts are infamous for missing some/most/all of the unicode characters (there are tens of thousands of them, so this is not all that surprising - except that Microsoft has been shipping OS’s localized to those countries for many years now, so I’d hoped maybe they would include at least ONE “CJK + Latin” font on all machines by now, no? No; they don’t).

Quick test program using Java (NB: java one of the easier languages for this because it was invented late enough that Unicode had settled down, and so it has extremely good Unicode support built-in to the core libraries, unlike C++ et al. By default, Java uses unicode almost everywhere, so I don’t need to debug unicode support, yay!):

NB: …but then when I tried it I quickly discovered a problem. I quickly gave up on the obvious route, so might have missed a workaround, but… I could have done this using Java’s built-in GUI toolkit (Swing), which supports using any font as a text label. However, it seems there’s a design flaw in Swing that’s been around since 1997 (yes, folks, 11 years and counting): the only component that can have the font changed - JLabel - which is a “general-purpose” label for any GUI component (good idea!) … is incompatible with the only component capable of being a button - JButton - which is a “general-purpose” button. Crap. If I’m not missing something here, with one small piece of poor API design, Sun have made their *almost* international-friendly GUI system almost completely useless for multi-language GUIs. Just to be clear: it’s not specifically internationalization they’ve broken here: its a general issue - any forms of customized rendering cannot use the JButton / JLabel combo. Why? Why, why, why would you do such a stupid thing, after going to the effort of making these generic widgets? Oh, well. Custom rendering it is…

/**
 * Simple test program that renders Unicode characters from a particular font of
 * your choice, a couple of thousand at a time, automatically wrapping them based on
 * render width on screen.
 *
 * You need to manually change the font name and the start/end co-ordinates of where
 * in the unicode constellation to render.
 */

import java.awt.*;
import javax.swing.*;

public class PaintSomeUnicodeChars extends JFrame
{
	void setup()
	{
		getContentPane().add( new charPane() );
	}

	public static void main( String[] args )
	{
		PaintSomeUnicodeChars window = new PaintSomeUnicodeChars();
		window.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
		window.setup();
		window.pack();
		window.setSize( 600, 500 );

		window.setVisible( true );
	}
}

class charPane extends JPanel
{
	public void paint( Graphics g )
	{
		int si = 44032;
		int ei = 46000;
		g.setColor( Color.red );
		g.setFont( new Font( “Verdana”, 10, 40 ) );
		g.drawString( “Chars from ” + si + ” to ” + ei, 30, 30 );

		g.setColor( Color.black );
		g.setFont( new Font( “Lucida Sans Unicode”, 10, 20 ) );

		int accumulator = 0;
		int height = 20;
		int xwidth = getWidth();
		for( int i = si; i < ei; i++ )
		{
			char[] chars = Character.toChars( i );
			String drawString = String.copyValueOf( chars );
			int advance = g.getFontMetrics().charsWidth( chars, 0, chars.length );

			if( accumulator + advance > xwidth )
			{
				accumulator = 0;
				height += g.getFontMetrics().getHeight();
			}

			g.drawString( drawString, accumulator, height );

			accumulator += advance;
		}
	}
}

Why choose Lucida Sans Unicode?

Apart from the fact that it’s present on all modern Windows machines automatically, I cheated a bit and used Character Map (Start > Programs > Accessories > System Tools > Character Map) to quickly inspect each of the fonts already installed and find out which ones had lots of unicode in them. Character Map has a neat feature where it completely ignores missing characters, automatically skipping over them, so you can very quickly see if a font has lots of unicode, some, or very little.

Stepping through in the java app, I fairly quickly found lots of Unicode characters. success - I can correctly render arbitrary Unicode characters in java.

NB: important because it took a lot more lines of source than I expected; java’s built-in “char” datatype is incapable of being used to render Unicode, because it’s too small a range of values. That also means you can’t use ANY methods that take a char as argument (this is documented in the Java API docs for Character). I’d never really used the methods that take int’s as argument before…

Fonts…

Not really happy with the font, though, and it’s clearly missing a whole bunch of characters. Some googling for free CJK fonts found me that allegedly Arial Unicode MS would work - which comes free with Microsoft Office (which I have on one of my machines).

NB: the way font licensing works, it’s probably illegal to copy a font you have on one machine to another machine you own. Unless you can obtain the font from the original source (e.g. in this case by buying a second copy of MS Office).

Arial Unicode MS has lots of characters, but … they’re wrong. At least, one third of the ranges of Korean characters are completely useless, as far as I can tell, because whoever made this font (whoever Microsoft licensed it from?) didn’t read the spec carefully and stuck the wrong characters in from U+1100-U+11FF. More on this later…

Giving up on that font, I went looking for others. The first four or five I tried that didn’t look ugly were all from download sites in Japan or Korea and kept crashing on the download. I found a couple of places hosting UnBatang (”UnBatangOdal.ttf”) and claiming it was free, but the first I found where the download didn’t crash was on http://www.i18nl10n.com/fonts

UnBatang (the name you have to use in Windows / Java from inside an application in order to load it) seems to work very well. It has nicely painted ideographs for the main range of Hangul characters/syllables, and it has *correct* glyphs for the other two ranges (although they’re a bit ugly).

Unicode Hangul

Specifications for official standards tend to be big. Really big.

Specifications for anything to do with internationalization tend to be huge.

Add in localization and data-transfer between different cultures, and you can expect something gargantuan.

So, I was really really happy to find a downloadable copy of only the CJK Chapter of the Unicode 5.0 specification (it’s still a big document!). This contains a full explanation of what Hangul is in Unicode, where to find it (yay!), and why there are not one but three separate sets of Hangul glyphs.

Here’s the preface to the Chapter 12 PDF I downloaded, in case you want to find the spec / electronic version yourself:

Electronic Edition

This file is part of the electronic edition of The Unicode Standard, Version 5.0, provided for online
access, content searching, and accessibility. It may not be printed. Bookmarks linking to specific
chapters or sections of the whole Unicode Standard are available at

http://www.unicode.org/versions/Unicode5.0.0/bookmarks.html

Purchasing the Book

For convenient access to the full text of the standard as a useful reference book, we recommend purchasing
the printed version. The book is available from the Unicode Consortium, the publisher, and
booksellers. Purchase of the standard in book format contributes to the ongoing work of the Unicode
Consortium. Details about the book publication and ordering information may be found at

http://www.unicode.org/book/aboutbook.html

Unicode 5, Hangul, and Arial Unicode MS

So, armed with the offical spec, I read up on Hangul. What did I find?

The Unicode Standard contains both the complete set of precomposed modern Hangul syllable
blocks and the set of conjoining Hangul jamo. This set of conjoining Hangul jamo can
be used to encode all modern and ancient syllable blocks.

(this is the glyphs at U+1100–U+11FF)

“conjoining Hangul jamo” means “these glyphs have been positioned inside their spaces in the font so that if you need to make one ideograph out of, say, four Korean letters, you just pick the top-left version of the first letter, the top-right version of the second, etc, and OVERLAY all the glyphs, and what comes out will autamatically be correctly spaced out etc”.

What did the author of Arial Unicode MS do?

Made all those glyphs take up the full available space, and centre them horizontally and vertically.

Why? Seriously, why? Because any application that tries to render those characters is going to render them on top of each other (according to the specification, this is the ONLY point of having those characters), and you won’t be able to read at all what the letters say.

If you want to render just individual letters from the Korean alphabet, there’s a different range of Unicode where you can find them all centred etc (which Arial Unicode MS also has … so it seems to be just copy/pasting internally).

I guess the font author just didn’t read the spec. Or I’m completely misunderstanding the spec. But the fact that UnBatang spaces the conjoining jamos out in such a way that this works as I expected it to suggests to me that it’s the Arial Unicode that’s broken…

The joy of Conjoining

I couldn’t get hold of the Unicode spec section on how to conjoin, because of some mimetype problems between their server and my PDA’s web browser. I figured I could probably work it out by trial and error fairly quickly.

I can’t remember how to spell my name in Korean yet - I know the letters, I’m just a bit flaky on what the placement of them is. So, a quick experiment, to see how easy it is to position characters using the Conjoining Jamo from UnBatang:

	... constants used later - the Unicode values for the letters of my name: ...

	int a = 0x1161; // jungseong vowel
	int d = 0x1103; // choseong consonant
	int d2 = 0x11ae; // jongseong consonant
	int m = 0x1106; // choseong consonant
	int m2 = 0x11b7; // jongseong consonant
	int blank = 0x110b; // silent char you place at front if first letter is a vowel

	... the body of the paint method: ...

	g.setColor( Color.black );
	g.setFont( new Font( "UnBatang", 10, 30 ) );

	int w = 0;
	int lead = 0;
	w += renderIdeograph( g, blank, lead, 40  );
	w += renderIdeograph( g, a, lead+w, 40  );
	w += renderIdeograph( g, d2, lead+w, 40  );

	lead+=30; w = 0;
	w += renderIdeograph( g, blank, lead+w, 40  );
	w += renderIdeograph( g, a, lead+w, 40  );
	w += renderIdeograph( g, m2, lead+w, 40  );

	lead=0; w = 0;
	w += renderIdeograph( g, blank, lead+w, 80  );
	w += renderIdeograph( g, a, lead+w, 80  );

	lead+=30; w = 0;
	w += renderIdeograph( g, d, lead+w, 80  );
	w += renderIdeograph( g, a, lead+w, 80  );
	w += renderIdeograph( g, m2, lead+w, 80  );

	... and then this method to do the paint of each part of an ideograph: ...

	/** Doesn't really render an ideograph, renders a single glyph from the Font */
	public int renderIdeograph( Graphics g, int i, int x, int y )
	{
		char[] chars = Character.toChars( i );
		String drawString = String.copyValueOf( chars );
		int advance = g.getFontMetrics().charsWidth( chars, 0, chars.length );

		g.drawString( drawString, x, y );

		return advance;
	}

Which renders exactly like this:

Which makes me want to point out the nice thing about properly specified fonts: in the source code, I simply did “the natural thing”, as if I were outputting characters in an arbitrary conjoined language:

1. Render the first part of the first ideograph at (x,y)
2. Ask the font to tell you how many pixels wide (w) it just rendered that part
3. Render the next part of the first ideograph at (x+w,y)
4. …repeat until first ideograph is complete, increasing w more and more each time…
5. Choose a value for how much you want the ideographs separated from start to start (ideograph_width)
6. Render the first part of the second ideograph at (x + ideograph_width, y)
7. …repeat as for first ideograph

And it worked. First time. I didn’t expect it to - I expected to have to do something strange like manually “reset” the (w) value each time I went from the first line of the ideograph to the second (Korean orders letters top-left, top-right, bottom-left, bottom-right, (repeat) … as opposed to Latin which is just left, right, more right, even more right, etc).

For this to have worked, it means the font is deliberately rendering the lower letters (e.g. d2 and m2 in my constants) a long way to the left of the origin that you tell it to render them at. This would be very, very confusing if you just tried to render these letters individually (well, duh).

Of course, if you try to run that code using Microsoft’s Arial Unicode MS font, you get a complete mess instead, because that font is FUBAR, as mentioned before. You get this:

…which is completely incomprehensible.