Hello all,

I've been working in the games industry for about 10 years now, primarily as a Gameplay Engineer. And while it has been very exciting and fun at times, I have reached a point in life where the sort of hours you work in this role aren't meshing with my family life.

So I was hoping to just throw a question out to the winds, and see if anybody here has been/is currently a Tools Engineer in the Games Industry? What is the day-to-day like? What are the projects like? What are the hours like? I have worked with Tools Engineers in the past, and I am curious about the role. I know that their schedules are often different than the rest of the team, since they are in a support position.

Thank you for any insight!

I was a tools engineer for years. You often have a greater up front set of hours, because folks are relying on you getting the pipeline up and running so that the game can be made. It's usually not as insane as game play engineering crunch though. The hours after the main toolset are already up and running are usually fairly steady without crunch. You still get to collaborate with artists and designers, though not quite in the same way. The projects vary, depending on what it is, and the way the company works. It could be writing plugins for various toolsets (Maya, Unity, 3dsMax), or it could be writing custom tools like Dialog Editors, global map editors, etc. Managed languages and C++ interop are common. You might even still run into MFC -- I can't confirm but I recall Diablo III's tools were MFC), but XAML and WinForms and Qt are more likely.

Why am I no longer a tools engineer? Well, you're already not working on games, might as well go one step further and work non-games, and get better pay, benefits, and stability.

I have reached a point in life where the sort of hours you work in this role aren't meshing with my family life.

Stop working those hours. It depends on the company, but from those I've worked at they are not required by management, but instead worked quite voluntarily by those on the team. I've been on teams where a few people run themselves ragged with extra hours and stay late into the night, and others on the team work exactly a full day and leave at 5:00 on the dot. In such environments there are engineers who (mistakenly) believe that the entire company success hinges on their putting in unreasonable number of hours. If management truly is demanding you work more hours than are standard for your nation, change companies.

The last company I worked with the entire office of several hundred people was typically vacant around 4:45, those who remained were finishing up their daily tasks. It is entirely cultural, and sadly many studios operate in startup mode, taking on the behavior of the company founders who are fully invested in the company rather than a worker at the company.

1) see if anybody here has been/is currently a Tools Engineer in the Games Industry?

2) What is the day-to-day like?

3) What are the projects like?

4) What are the hours like?

5) I have worked with Tools Engineers in the past, and I am curious about the role.

1) I've worked on tools teams at two companies. Many others here on the site have worked and are working in the role.

2) Day to day it is a programming job. Instead of gameplay tasks like "write a script for weapons spawners" it is tools tasks like "write an importer for Collada files". The exact needs depend on the team's needs. They may need stuff for the engine, stuff for content pipeline, stuff for build systems, stuff to make various people's lives easier.

3) Every project is different. I've built image compositing tools, tools for processing resources for Nintendo DS, art tools to help the artists view their assets faster, engine tools for screen layout, engine tools for data parsing, pipeline tools to help the build system, tools to help designers modify data more easily, tools to extract game statistics that are run automatically and appended to a file to generate trend lines. Lots of tools out there.

4) Hours are whatever you let them be, as above. A small number of companies are abusive, don't work there. Most companies have sane core hours, many in this industry are more than willing to let foolish young workers abuse themselves with late hours if the workers wish. Pay attention to detail of what management says, if the core hours are 9:00 AM -4:30 PM, you shouldn't routinely be at the office at 6 PM or even at 5:30 PM. Yet I've been at companies with those core hours and a few people still put in 9-hour, 10-hour, even 12-hour days. Mostly those were young, single adults with no real life to speak of.

5) If you've worked with them you should basically know the role. It isn't too radically different from gameplay engineers, it is still writing code to solve problems, just uses different topical areas of code and different software libraries to accomplish it.

I know that their schedules are often different than the rest of the team, since they are in a support position.

That depends entirely on the company and teams. Nearly every company I've worked at everyone has had the same core hours, except for QA who often arrives a few hours later in the day and works the same number of hours later in the evening.

Those rare teams that had different hours usually worked with other remote groups in different time zones. When you've got teams on US Eastern Time and British Time, the US people arrive early and the UK people may work later. When you've got US east coast and US west coast teams the west coast people may need to arrive at 8 AM, the east coast may not arrive to the office until 10 AM.

I do gameplay, systems and tools work. Personally I like tools the best, but projects typically don't need enough tools to have someone dedicated to them full time.


In my experience, tools work vs gameplay work has tradeoffs:

Standalone tools have relaxed constraints compared to game code:
- Your program only needs to run on developer machines (less need for testing on particular hardware configurations).
- You have more leeway to pick your libraries without worrying about code bloat or runtime memory consumption.
- You can use coding styles that are frowned upon in real-time game code (for example, in a Unity project you would tend to avoid LINQ-heavy code during runtime, but there's no reason to avoid it in tools).
- Standalone tools are usually much easier to debug than the game.
- Unit tests are usually much simpler to write since there are fewer interfaces that you need to mock. Sometimes you don't need to mock anything.

However...if you accidentally break a tool, or if you take a long time to deliver something that the rest of the team needs, you may have the ENTIRE team breathing down your neck - a very stressful situation.