The right decision during development, whether we’re talking about gameplay tuning, art styles, or the amount of time to dedicate to coding a particular feature, often hinges on the way that countless other decisions come together. In these kinds of cases there is no objectively correct answer. It just comes down to context and some assumptions made on experience (or, lacking that, intuition).
While slogging through these challenges, especially during early phases of a project, work on elements until they are “good enough for now.” There is a specific, practical meaning to checking whether work is at this state: is it far enough along to tell whether it’s working out, or ought to be scrapped for a different approach, and complete enough to use as a point of reference in making other decisions.
This is a form of building to think, to bring assumptions to the surface, and to see how multiple parts hold together in their initial form.
It’s a bit like a placeholder asset, which is just rushed temporary art or audio that’s already integrated but needs to be replaced. Except that in this case, the idea extends to also include placeholder code, placeholder level design, or a placeholder decision about scheduling.
Developers refer to this as something being at “first-pass.”
Another difference from placeholder assets is that whereas non-artists are the ones that make placeholder art, it’s the actual programmer that programs features to first-pass, or the designer that gets a level to first-pass. It’s about bringing something along far enough to show the complete idea, without getting bogged down yet in details, tuning, and polish.
Until the enemy movement code behaves roughly as intended, decisions about weapon tuning are somewhat arbitrary, since their effectiveness in practice will largely depend on how easily the targets are hit. Until there’s a crudely representative level, at least from the standpoint of navigation and encounter, and working code for player movement, there’s little basis for deciding how long power-ups should last.
Although those two are numerical examples for simplicity, this is an idea that applies to nearly all areas of development. It relates to finding an appropriate art style, which may feel much different in playing through a structured level than it does in carefully composed concept art. It also relates to figuring out whether getting multiplayer working warrants a sizable schedule extension; can you first hack to get it working inefficiently, under less robust conditions, to test it as a way of making a more informed decision about whether it’s worth setting aside time to do it for real? The controlled test might even turn lead to discovering an opportunity to do something better or more efficiently on the second pass, beginning with the first real plans and lines of code.
Programmers are warned, rightly, to avoid premature optimization. Until enough of the program exists to get empirical data on which parts of the code are responsible for overall performance issues, inventing clever data structures and novel algorithms to deal with every part of the program risks wasting a bunch of project time for an undetectable difference in performance.
Aiming for first-pass on initial implementation is about avoiding premature iteration. Until enough of the gameplay exists to figure out which details matter most – in the context of other details – just focus on getting the pieces working and hooked together. Too much time spent tuning early on generally becomes lost effort as other systems come together.
You’ll occasionally discover a good reason to blow away prior work now rendered obsolete. When that does happen: the less polished the garbage is, the better.
Once enough of the work is done at first-pass, you or your team is in position to focus on which decisions are most important. Should some feature be cut entirely, because it just isn’t working out? Do the whole team’s initial assumptions about scale feel off, so that movement or level forms need attention? Continue to prioritize and address the worst of the issues, and you’ll sometimes find that just like with code optimization, where addressing only the most important issues takes less time and makes an even bigger difference, a surprising amount of the first-pass decisions may hold up well enough as-is.
For those pieces that do wind up changed or rethought, this approach leads to them being addressed in a sensible order, so that the least important details wind up accommodating the most important decisions. For example if it’s critical for aesthetic reasons that a certain enemy or vehicle moves very fast, tune that first until it feels right, then adjust weapons, level dimensions, and so forth around that as a pivot. If it’s a game primarily about jumping between platforms, or building a base, or shooting arrows, zero in on that focal point, then experiment, tune, and cut other elements to highlight or avoid hindering those features.
Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.
Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!