Stand It Up End-to-End

Dec 5, 2012

In First Pass and Order of Decisions I warn of the dangers of premature iteration – the importance of context in being able to meaningfully do low-level design work in such a way that any decision can even make more sense than another.

Standing it up end-to-end is a phrase I’ve been using for many years now, and though I’m quite sure that I didn’t make up, to my surprise I can’t find other references to it on the internet. It’s about getting virtually everything in the software to first-pass, and connecting all of that first-pass content/functionality together.

Think of it as the first-pass connection between all of the programs parts.

It might involve a lot of placeholders – not just placeholder images, but perhaps placeholder text, placeholder menus, even (at first!) placeholder weapons and placeholder levels. But the point is to get everything stitched together… even if everything that’s stitched together still has a great deal of work that needs to be done.

It’s a little like a barn raising. Big sections of the barn get built laying flat, then when they’re all ready, they get stood up and securely connected together, after which there’s a skeleton of the barn standing. It’s by no means complete at that point, but this step marks the transition from a pile of parts to a recognizable whole. More importantly, it marks the transition to suddenly being ready to have others begin boarding up the sides, working on roofing, and after all of that is completed, painting.

Why do this? Why bother tying it all together so far from when it will be done?

First: it’s a good way to check overall program flow. Will there be a cutscene before the main menu, or after the main menu? Does it feel harsh going from one level to the next, but there’s currently no plan for how to smooth that transition? How many times will the user need to click in order to double check which keys are assigned to changing gears?

What looks like a prohibitive amount of complexity on a high level diagram is sometimes not nearly so bad when experienced properly on-screen, given how much information gets hidden. On the other hand, what looks perfectly sensible from a birds-eye view giving context in a menu diagram may totally break down or feel disoriented when experienced on-screen. So while it’s definitely not a waste of time to plan things out on paper, get it on on-screen as soon as possible. Your player isn’t downloading or running the paper! Aim to be iterating on-platform, doing what the player will be doing, how they’ll be doing it. Standing it up end-to-end makes that possible.

It’s also a good way to figure out what’s missing. Trying to fit levels together, rather than just changing a filename in the code before recompiling, will immediately highlight issues like – oh dear – we never programmed or made art and audio for level exits! Or it’s a good way to discover that, depending on the platform, some lazy programming habits have led to avoiding deallocations altogether, which didn’t really become a problem until a given play session could go through multiple level loads. This brings to the surface an important reminder that this kind of “invisible” programming clean up work is still on the have-to-do list, too, and can no longer be ignored. It absolutely has to be done, so better to deal with it sooner rather than later, rather than risking running out of time on a known issue with such importance to the overall program’s integrity.

The other upside is that this approach makes it much easier to do development work in tandem. Rather than documenting hypothetical interfaces between non-existent parts of code based on how people imagine the engine will progress, standing up the program end-to-end means that the particle effects spawn functions are being called, and that audio samples are hooked to different filenames, even if they’re currently doing only the most basic things with the particles, or playing duplicated placeholder sounds. This allows another programmer to leap in and focus on making the particle effects more intricate without any fear of merge collisions (we used this approach for Saturn Storm to simplify internal documentation and communication overhead), and allows the audio person to freely go in and fiddle with replacing placeholder sounds. In both cases this can happen without needing to slow down the main engine programmer to integrate said changes, since the calls coming from the main code are already connected, and so will need little/no alteration to accommodate the changes made in other files.

Of course, it’s not necessary stand it up end-to-end early on. Doing this too early can even be a bad idea, because decisions made based on how gameplay works or how the aesthetics are working out may steamroll previous assumptions anyhow about what functionality will be presented how in the menu system, or with regard to what happens between levels.

Standing it up end to end too soon during development can also become an annoyance for the team, because even with debug mode flags available to skip most intro sequences, inevitably some slight inconvenience still arises to manually skip past elements needed in the final game, or to reach certain spots in the game that were more trivially accessed in more crude builds. That adds time to each of the thousands of test iterations left for the project, and especially multiplied across multiple people, that lost time can really add up.

But standing it up end-to-end somewhere between 40% or 60% of the way through the schedule is a good way to take stock of how you’re progressing as a team, to develop a more concrete list of what’s still unaccounted for, and gaining another, simpler way to split off additional asset or programming work for other team members to be able to tackle in parallel.

Know when to stand it up end-to-end. Don’t do it too early, and don’t wait until the last minute to do it. Hopefully, having the phrase in your team’s vocabulary can help you communicate better about the timing and significance of this milestone in the process.



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!



Leave a comment

Comments Form
  • Your email will not be used for any purpose other than to update you in replies to your comments. Your website address will be shown as a link from your name with your comment. Your profile photo is auto-magically provided by Gravatar.

All contents Copyright ©2017 Chris DeLeon.

Site production by Ryan Burrell.