This semester I’m working on tool development for games. It’s an ill-defined area of game design, but an endlessly fascinating one - at least to someone as systems oriented as I am. And since I’m fortunate enough to be a part of the NYU Game Center community, I have access to an almost limitless number of developers mid-project.
What is “tool development”?
To me, tool development lives in that sweet spot between fixing a one-time problem with a clever piece of software, and making a game engine from the ground-up. But what is a tool? What makes a tool different from an engine, or a piece of one-off code, or a game itself? If we go to the not-quite-reliable Wikipedia, we find this answer:
“A programming tool or software development tool is a computer program that software developers use to create, debug, maintain, or otherwise support other programs and applications. The term usually refers to relatively simple programs, that can be combined together to accomplish a task, much as one might use multiple hand tools to fix a physical object.” (Wikipedia)
I think what sets tool development for games apart from tool development in other software development contexts is a product of game development’s constantly shifting end goals. Often, game developers find they need something to branch their past design goals to their current design goals. Most of the time it’s not useful to completely recreate the game software from scratch, especially if the game might change again, so tools allow you to map previous decisions to the current architecture.
I’m also working on a series of lectures on Games Architecture, and from the first lecture slides I have this list of ideals for game software design:
Code should be easy to understand over the lifetime of the project.
The game should run fast.
We need iterate and make huge changes quickly.
The issue in game architecture is that these three things are in conflict with each other - but from a tool development perspective, these three things give us a good idea of what kinds of problems we’ll need to solve. “Code should be easy to understand over the lifetime of the project” means we’ll need to create tools to organize code, or make the code easier to understand for non-programmer designers. “The game should run fast” means we’ll need to create tools to identify issues with the code’s computational complexity. “We need to iterate and make huge changes quickly” means we’ll be making tools to lessen the cognitive load of iterating, and find an abstraction that will allow huge changes to be made easily, or at least show some of the consequences of making those huge changes.
What is my goal?
The original goal of the independent study was to make a sort of super-tool, a way of defining any type of non-digital game, describing their rules and components, then provide designers with combinatorial toolsets - a neat, games-oriented user interface into the world of markov chains, systems of linear equations, complexity theory, and so on. It took me about two days to realize this was an impossibly large scope, and in all likelihood completely impossible. Instead, I’ll be focusing on a series of small, real-world problems, finding game designers with discrete problems they need solved, and giving them tools tailored to their design process. It’s possible some of these tools will be useful enough, and general enough that they can be abstracted to a more general audience, but if that doesn’t happen, that’s all right too.
What do I get out of it?
Well, I get a chance to wrestle with other developers’ game code and design processes, and find ways to make their development process easier. Along the way, I’m hoping to learn more about how to program and design games - by seeing as much code as possible, talking with as many designers and possible, and learning about their design process by seeing the work in progress. Plus, I’m hoping to become more facile with elements of non-game programming that will allow me to create easy to use, easy to understand tools
Tool Development for Digital Games
This area seems more familiar, more common, and something designers desperately want. Games are generally programmed alongside the design process, and often you begin making a game long before you actually know what the final mechanics will be. As a result, designers are often dealing with decisions made before they knew what the project would be, and sometimes by other designers.
Goal Projects:
Create a new editor (level, sound, etc.) for digital designer to use on their game.
Source Control Integration - digital game specific pre-commit hooks, etc.
Modifying open source tools to fit a designer’s pipeline.
Content verification
Write new Unity Engine feature to extend / support in Unity
Tool Development for Non-Digital Games:
From conversations I've already had with many non-digital designers, they fall into two camps - the first made up of designers who are making large scale projects, usually intricate board games or tabletop RPG's, who want help on economic terms, often economic issues that are specific to their game. The other group is made up of designers making smaller-scale games, either simpler board games or card games, whose process is more iterative, and their goals are more general - they want that super tool I initially set out to create. However, I started to realize the one thing every non-digital designer in that second camp had in common - they used a spreadsheet app to design their games, or balance them, or even just to document them. But there are context-specific things from game design that aren't built in to any spreadsheet app - so goal will to take Google Sheets and bake in some of that functionality they're looking for.
Goal Projects:
Create “Google Sheets Plus” for game designers, a spreadsheet app that understands game-specific contexts, like “dice”, “players”, “decks”, “turns”, etc.
Create a python plugin that provides some combinatorics
Create a tool / tools for developers' specific economic or balancing needs.
Well then, what's next?
Right now, well - I'm working on finding designers, interviewing them, and finding what their needs might be. As I move forward, I'll be writing blog posts either generally about things I've discovered, or specific step-by-step breakdowns of the tools I've created, depending on the preferences of the designers I'll be working with. Stay tuned for more!
Comments