As I was having a discussion with some other designers and engineers on my team, it occurred to me that there are often turns of phrase we use that outsiders might find odd. Here are a few I could think of:
Where does X live?
When we ask where something lives, we’re usually asking where we can find a particular file, asset, or function within the entirety of the assets, scripts, code, etc. in the project. Depending on the context, the answer could be a single file, a folder within the project tree, a line in code or script, or something else.
“X land” (e.g. “That function lives in C++ land”)
The general part of the project that handles a particular thing. Related to where things “live”, a “land” is a more generalized location. If a particular bit of logic lives in “script”, it may send messages to C++ land - that is, a particular bit of script may call C++ functions. Telling someone that something “lives in X land” means they won’t find the definition where they’re looking, and provides some context as to where to look.
This actually has nothing to do with game balance most of the time. Nine times out of ten, “broken” means that the most recent version of the game (that a particular person pulled) does not work for some reason, usually because some combination of the checked-in files and assets cause either a crash or hard lock somewhere. Usually this is because of somebody forgot to check a common case, or forgot to check in a file along with the others. Being broken is the worst state for somebody to be in, since they cannot work. If many people on the team are broken, it is a fire that needs fighting.
Working on unexpected high priority tasks that aren’t part of the normally assigned workload, often to help other devs who are broken get un-broken.
Not quite the same as Broken, blocked just means that a task has a dependency that hasn’t been completed yet. If all of someone’s tasks are blocked, they are effectively broken.
Much of the time, we have to work in different branches of a particular depot - especially if we’re working on content that will go live in different content updates. When changes from one branch are integrated to another branch, the target branch is “downstream” from the source branch, which is “upstream” from the target branch. Usually in these situations, the majority of the integrations are one-directional since the upstream branch needs to maintain stability so it doesn’t take the riskier and less stable check-ins from downstream.
Talk about/Take it Offline
This actually means “let’s discuss this later”. Usually used to table a discussion on a topic brought up at a meeting so we don’t waste the time of other people at the meeting who aren’t involved.
This means the project has reached the state where the leadership will no longer accept new Xs - features, assets, content, code, etc. We can still fix issues with, tune, and iterate on the existing Xs we’ve started, but we cannot add new Xs anymore. Usually goes in the order of feature, then asset, and finally code.
A more advanced version of X Complete, a feature/asset/code Lock means that no checkins of that type are allowed without express authorization. The project has reached the stage where stability is paramount. This means that only specific check-ins that have been vetted by the senior engineers are allowed in. Follows the same order as X complete. Once code freeze is declared, we’re in the final stretch - the only goal from then on is to get a submission candidate.
Got a burning question you want answered?