I use C++ as my language as choice. However, I generally use Python to write helper utilities and tools.

My worry is that as my game engine continues to grow it's getting tedious to reimplement some of its features in Python.

There has got to be a better way.

Here are the options as I seem them

  • Keep on keeping on.
    That is often the answer in a cooperate environment. Maybe it has some merit.
  • Build bindings for Python (yuck) and have it use pieces of the engine directly.
  • Start building the tools using C++ instead.
    I already use QT in the Python tools to provide a GUI when needed. It doesn't seem like it'd be that much harder to use QT in C++ instead. However I'm worried my tool productivity will go down. I generally strive to apply much less rigidity in tool code than I would in shipping code.

So what is common practice, use the same language for tools, or use a more RAD friendly one?
What if you use a language that differs from the language of the game which do you use? How do tools interact with the game engine link to it directly or fake it?

  • 4
    \$\begingroup\$ I would suggest making this CW. There is no "best" answer and you're probably just going to get a lot of anecdotes. \$\endgroup\$
    – user744
    Oct 2, 2010 at 20:38

2 Answers 2


What do the tools do? Presumably, you mean tools for generating and editing data files which your engine can load, and not e.g. your profiler and debugger.

You're working on a data-driven engine. You can apply the same philosophy to your tools - write data-driven tools.

For example, let's say you are using protobufs. The protobuf libraries for C++ and Python will let you save structures in one and load in the other, no problem. But why not go a step further, and generate the tool UI from the protobuf schema as well? It won't be a great UI, but UIs for most game data are just string key / typed value pairs, and that's trivial to generate using Python and the UI library of your choice. And if it's a really bad UI, at most you committed yourself to the work you're doing now anyway, by writing a custom one from scratch.

At my last job, we used this style as a first-pass on (almost) every editor. Some of them stayed that way forever; a giant sheet of key/value pairs is a pretty good way to edit inventory item data, for example. For editors that needed more structure, such as the editor that assembled character models from parts, we had a custom top-level layout, with sub-panes generated this way (e.g. we placed the "Tattoos" pane by hand relative to the "Bone Scaling" pane, but their contents was dynamically generated from the structure schema).


I make all my tools using the Qf Framework, that way they're fairly easily cross platform. There's also loads of well maintained bindings for Qt, including Python Qt bindings.

  • 1
    \$\begingroup\$ caspin's not asking how to write cross-platform tools, but how (and if it's possible to) to prevent duplicate work when your tools and your game are necessarily different codebases. \$\endgroup\$
    – user744
    Oct 2, 2010 at 22:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .