Opinion: What Is An 'Engineer Architect'?

[In this reprinted #altdevblogaday-opinion piece, Bungie's Andy Firth explains the role of engineer architects at a game developer, including their day-to-day tasks and work on often behind-the-scenes systems.] A question that i get asked rather a lot is "What is an engineer architect?"

en·gi·neer noun /ˌenjəˈni(ə)r/  A person who designs, builds, or maintains engines, machines, or public works ar·chi·tect noun /ˈarkiˌtekt/  ((computer science) the structure and organization of a computer's hardware or system software) "the architecture of a computer's system software"

This basically translates to the same thing all engineers do:

• Analyze the problem
• Formulate a possible set of solutions
• Analyze the solutions
• Decide what to implement
• Implement
• Test/bug fix
• Profile/sanitize
• Repeat until satisfied

However, there's one important difference. My role involves the entire program, how its parts interact and how they are designed, what their dependencies are and how they affect the final output and the performance of that output. Combine this with data parallel infrastructure, task parallel objects, multiple platforms, myriad hardware limitations and a large programming team ... under many circumstances one might imagine something akin to this: And you often wouldn't be too far from the truth on a daily basis. Long term, however, we (the team) have a plan and a set of goals. Over time, we re-assess based on those we hit and those we don't, new requirements and ultimately how the game is progressing and where it needs to go. The role I play in this is simply to ensure that under the stress and strain of day-to-day development, we're still aiming in the right direction as a whole. Those decisions take into account as much of the big picture as possible and weigh that against the immediate requirements of the current goal. There are several people in similar roles at Bungie, and our interactions provide a simple but effective method of applying "Checks & Balances" to the progress we make; we each bring our own flavor to the table. Day to day, this involves tasks such as the following:

• Advising/Teaching on how to handle concurrency
• Long term interface design
• Short term prototyping/bug fix hacks
• Discussing/Advising on future platforms
• Optimizing programmer iteration, debugging & general workflow
• Managing external teams
• Auditioning Middleware
• designing/writing/debugging infrastructure systems

Technically, I'm a member of Bungies "Infrastructure" team. This means that if it's something "unexciting", "behind the scenes", or seemingly doesn't affect the final game at all... we handle it. That involves systems like these:

• Memory Allocation
• File System
• Network Transport
• Crash Handling, Minidumps
• Debugger Plugins
• Multi-threading Infrastructure & Architecture
• Asset import/baking
• Math Library
• Schematization/Reflection
• Audio Engine
• Container Classes
• Profiler Infrastructure
• Compiler Configuration
• Low & High Level Optimization
• Build Systems
• Flux Capacitor Maintenance
• – you still reading?

As I said, the stuff most most programmers find tiresome and boring. Our team love this stuff and we're good at it. So there you have it, a much better idea of what i do at Bungie and hopefully a guide to those in school who might want to progress towards a similar role (or avoid it). [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]