Read on Twitter
OK! Secret production hack reveal time! You *can* break dependencies and it *does* lead to less stressful projects. The problem is it doesn’t work on typical game projects or goes against typical workflows. But I’ve personally done this and it was great. /1
In 2009 we finished 13 games in 12 months. These were very simple, very cheap games! Text and images. But one clever thing we did was build a tool chain that took a Word document where a writer had put “quiz 23: picture of a sleeping lion” and that generated /2
an Excel file with “quiz23.png” and “Picture of a sleeping lion”. The build process would look for quiz23.png and if it couldn’t find it would use a placeholder (and report this).
Meanwhile the artists worked off of the Excel file. /3
Meanwhile the artists worked off of the Excel file. /3
This meant we had a working game from day 1 (with all placeholders) and writing and art were completely decoupled. Also we could tell art was done when the build process said it hadn’t used placeholders. It was *great*. We still talk about how nice it was years later. /4
You may immediately go “your low budget technique won’t work for me” but think about *why that is* and whether you can change it. *Analyze your dependencies*. Rethink your game, if you’re an indie. /5
BioWare used to auto-generate cut-scenes from scripts, so they could have a completely playable story without being dependent on cinematic production. (Maybe they still do this.) /6
Greyboxing cuts the dependency between level design and level art.
Prototyping and iterative development are really ways of cutting dependencies and enabling schedule compression. /7
Prototyping and iterative development are really ways of cutting dependencies and enabling schedule compression. /7
One key method is to think about declarative tools. You don’t create in detail what you need, you specify (declare) it at a higher level and let the computer (procgen) or other people (my example above) do the work, off of your critical path. /8
(You MUST understand the concept of the critical path to do scheduling right. If I could only teach one thing it’s that.)
/9
/9
In 1999 I designed an engine where the level designer would just say there’s grass in a given map square and at first we’d just render two green triangles and the proper rendering of that (art, code) was decoupled. /10
It also allowed us to better manage the risk of making assets for moving and unknown platforms.
It put a big constraint on the look and the design changed so it was no longer viable.
It’s not amazing now but seemed fresh back then. /11
It put a big constraint on the look and the design changed so it was no longer viable.
It’s not amazing now but seemed fresh back then. /11
Anyway. Food for thought perhaps. Try to break your dependencies for less stress and better games (because more iteration on what matters). /end
