• Advertisement
Sign in to follow this  

Is C++ dominant in tools development, too?

This topic is 3230 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've always thought that C# would be a better platform for tools development (in general) than C++, because of its ease of use and the incredible leverage of the .Net framework. Yet I still see many Tools Developer positions requiring C++ experience. I have a lot of experience with both languages, so it's not that big of a deal, but if both languages fit, I'd much rather work in C# than C++. So this leads me to consider a few possibilities: 1. Performance matters. The biggest reason I think someone would choose C++ over a higher level language would be performance. When I think of "tools", I generally think of things like level editors, management utilities, code generators, and data converters. Maybe I'm wrong about that. What sorts of tools does game development employ? Perhaps level editors are the big one, and you want a run-time designer that uses the same renderer as the game, so having the two built with the same language makes that possible/easier. 2. Platform matters. This one I don't think is very likely, but again, maybe I'm wrong. I'm under the impression that most studios develop in windows, running Visual Studio. Maybe a good number run linux and Mono doesn't work for whatever reason (I don't know that much about it). 3. Tools developers don't always stay tools developers. Most games are written in C++, and I could definitely see wanting your tools developers to pitch in on the game itself, or even to move them off of tools development entirely. You'd definitely want someone with C++ knowledge in this case, but if that were so I think you'd see "knowledge of C++ and C#", assuming tools development weren't limited to C++, which now thinking it often is. 4. Studios wants to keep things simple. I think this is the most likely candidate. Most games are written in C++, and it's probably just easier to keep most of your code in house the same language. Of course, scripting languages are used pretty heavily as well, but maybe they're just more pronounced and adopted within the industry than C#. Which brings me to my next possibility... 5. C# hasn't yet been widely adopted in the industry. Maybe a lot of developers don't have a lot of experience with C# or .Net in general, and would make more use of it if they knew how nice of a language it is, or how powerful the .Net framework is. Of course, maybe the opposite is true and they think it makes a developer lazy. Working with both, it's easy to see the differences between the two languages, and C# definitely does a lot of work for you. So have I hit on everything here? Does what I've listed contribute, or is at least accurate? I know I'm speculating on a lot. Also, I know I'm just talking about C++ and C# here, but there's no reason why other high-level languages might be more ideal for tools development, as well. I just really enjoy C# development, and while my game server and client are written in C#, as well as all of my tools (3 in all), I know I'd strongly consider it for tools development, even if the game were written primarily in C++. Python is very popular, and I know it can greatly expedite development. I don't know how well suited it is for tools development, but it falls under the scripting, as well, which is a boost for possibilities 4 and 5. F# is on its way, and I hear it has some real promise. And of course, there are still some that elect to write in VB (though why I'll never know). So are higher level languages often utilized for creating tools? And if not, why? EDIT: Amended closing question. [Edited by - CyberSlag5k on April 22, 2009 2:01:27 PM]

Share this post


Link to post
Share on other sites
Advertisement
The main reason that comes to mind is legacy. If the in-house C++ tools have been around for a while, and aren't a major sources of problems, it may be more reasonable to continue with C++ than port it to C# or some other language.

Share this post


Link to post
Share on other sites
Quote:
Original post by CyberSlag5k
So is tools development primarily done in C++? If so, why, and, in general, should it be?


Our tools are all written in C++ where I work. The reason we write tools in native code is that Unreal makes it easy to do so. Their editor is all native, and adding additional functionality to it without using either native code or unrealscript would be a pain in the ass.

We do have a few standalone tools written in C#, and some VB and perl scripts and the like, but day to day everything we do is in C++.

Share this post


Link to post
Share on other sites
What exactly is the point of this thread? Your initial wording implies that you're evaluating languages and tool sets for a specific tool development project, but the rest of your post is focusing on random possible issues that a hypothetical set of studios in the industry might consider important.

Which is it? I can't help but feel that your entire post is simply the start of another language war. That is not a productive use of anyone's time, and ends up being an invitation to any and all to come and spew ignorance all over the place.

If you're searching for a personal choice, then none of the points you've mentioned are debatable or applicable. Simply choose what is easiest and most productive for your own product, and leave out the pointless language debating that we've already had plenty of on GDNet.

Share this post


Link to post
Share on other sites
Quote:
Original post by CyberSlag5k
1. Performance matters.

It can, certainly. Level editors are often working with a more raw, unprocessed form of levels which entail much more data pumping than the game itself. And other low-level tools -- audio compressors, say -- just need raw speed, period. That sort of thing needs to be evaluated on a case-by-case basis.
Quote:
2. Platform matters.

Nah.
Quote:
3. Tools developers don't always stay tools developers.

More fundamentally, game developers (whether tools programmers or engine programmers or whatever) aren't always familiar with C#. I would say it's more the other way around -- you often want your game programmers to be able to screw with the tools.
Quote:
4. Studios wants to keep things simple.

Meh. That's pretty vague. Games aren't simple, period.
Quote:
5. C# hasn't yet been widely adopted in the industry.

In terms of tools, sure it has.
Quote:
So have I hit on everything here?

One factor you left out, or perhaps you assumed it as part of one of your other points, is that often you want to be able to reuse game code in your tools, to make sure that rendering, file formats, etc. are in sync. This entails either code generation from common descriptors, cross-language development, or just using C++ for everything.
Quote:
So is tools development primarily done in C++?
That's way too general a question to ask. There's a significant amount of non-C++ coding going on, period, and the precise amount varies wildly depending on the developer.

Share this post


Link to post
Share on other sites
Quote:
Original post by Mike.Popoloski
What exactly is the point of this thread? Your initial wording implies that you're evaluating languages and tool sets for a specific tool development project, but the rest of your post is focusing on random possible issues that a hypothetical set of studios in the industry might consider important.

Which is it? I can't help but feel that your entire post is simply the start of another language war. That is not a productive use of anyone's time, and ends up being an invitation to any and all to come and spew ignorance all over the place.

If you're searching for a personal choice, then none of the points you've mentioned are debatable or applicable. Simply choose what is easiest and most productive for your own product, and leave out the pointless language debating that we've already had plenty of on GDNet.


I'm just curious. I've often thought about if I'd rather work on tools or an actual game itself, and I've always had the assumption that you'd use the lower-level, higher performance languages for game engines and clients, and higher-level, faster development languages for tools and other "offline" applications. I'd not noticed this in the job listings and was wondering why.

Share this post


Link to post
Share on other sites
Quote:
So is tools development primarily done in C++? If so, why, and, in general, should it be?


I suppose these aren't good questions to ask. I was just looking for a closing to my post, but I think this colors poorly. I tried to acknowledge that the choice of language is based on the project in my post, but this contradicts that, suggesting that maybe C++ isn't the right language for tools development, which was not at all the focus of my post, nor even something I was attempting to suggest.

Share this post


Link to post
Share on other sites
FWIW, we write almost all of our tools in C#. We have a separate tools team that maintains a large suite of in-house tools. We have a few tools that link against our runtime engine libraries (which are written in C++). Our engine has reflection capabilities, and our C# tools can interact via the network and directly manipulate data in the running games.

Share this post


Link to post
Share on other sites
I found that a lot of the code that goes into the editor is shared with the game: loading resources will mostly be the same, rendering them will also be similar. I think it makes a strong case for making the tools in the same language as the game since it'll be easier to share the code.

Currently we're in the process of changing our level editor to allow the editor to sort of play the game while editing so it's easier to see the effects of placing objects and units. Thus we'll be linking our ai and physics code in as well. It'd be a lot more work to ensure proper integration with an editor written in another language.

Share this post


Link to post
Share on other sites
The code sharing issue is surely important, I'm not sure how you get around it if you want to mix languages. I'm trying to put my tools in the same solution as my game, where the Application projects are all front end stuff and the game objects are in a separate library. The relevant game objects will have serialization methods (using boost) and so I can create my objects in the tool, save them and the game can load them using the same method.

Share this post


Link to post
Share on other sites
Quote:
Original post by CyberSlag5k
1. Performance matters.


We deal with literally thousands of animation and model files, they do slow down processing a hell of a lot, so much so that C++/SIMD/Multi-threading optimisations are frequently used. So for some things, yes C++ is used for performance. Most of the code in a tool really won't need that speed though, and in those cases you'll probably use a scripting language.

Quote:
Original post by CyberSlag5k
2. Platform matters.


Cross platform development is hard whichever language you are using. Most inhouse game tools will be locked onto a single platform (since the effort required to port code can't really be justified).

Quote:
Original post by CyberSlag5k
3. Tools developers don't always stay tools developers.


Not so much. Our tools devs are somewhat unrelated to the game devs, although there are a lot of grey areas where you will find people working on common code.

Quote:
Original post by CyberSlag5k
4. Studios wants to keep things simple.


Simple and C++ don't really go hand in hand at all. A scripting language is keeping it simple.

Quote:
Original post by CyberSlag5k
5. C# hasn't yet been widely adopted in the industry.


It has been fairly heavily embraced by tools devs, however Python has been the standard scripting language for tools for quite a number of years now. If the tool is new, chances are it uses C#. If it's slightly older it'll probably have python bindings (and there's going to be little to be gained in adding C# bindings when you already have python working - it's just wasted effort).

Quote:
Original post by CyberSlag5k
Python is very popular, and I know it can greatly expedite development. I don't know how well suited it is for tools development, but it falls under the scripting, as well, which is a boost for possibilities 4 and 5.


Python is found in every single 3D authoring package out there. There are tonnes of other scripting languages used as well (C#, VB, JScript, ruby, mel, lua).

Quote:
Original post by CyberSlag5k
So are higher level languages often utilized for creating tools?


Almost always. We do all GUI code for our tools in scripting languages, with the core components all done in C++ (typically because they'll be interfacing with game code). Our ratio is probably 40% script and 60% C++, however the 40% script code probably gives about 70% of the tools functionality.

Share this post


Link to post
Share on other sites
The problems with C# in tools are:
* Your tools usually need to communicate with or use the C++ engine. The more skilled your C++ coders are, the harder this gets due to the complexity and idiomatic characteristics of well written C++.
* Major tools typically predate C#/.NET being a legitimate/workable approach, leaving lots of legacy code to deal with.
* Game programmers tend to be unfamiliar with anything that isn't C/C++. (I've seen PHP, Perl, and C# code written by long time veteran game programmers. Aurgh.)

Most studios are pushing ahead with moving their tools over in spite of these blockades, which should be a hint as to just how highly valued these new toolsets are.

As for the C++ experience, candidly, everyone on a game project involved with engineering needs to know C++, period. The game is in C++, as are any number of tools/utilities/compilers.

Share this post


Link to post
Share on other sites
I think "C++ experience" is partly just there to make sure to attract coders with attention to detail (lol). But I assume tools programmers will sometimes need to interface with native code, optimize parts of their tools with native modules and/or write loading/saving routines in C++ for the game itself and so on.

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
The problems with C# in tools are:
* Your tools usually need to communicate with or use the C++ engine. The more skilled your C++ coders are, the harder this gets due to the complexity and idiomatic characteristics of well written C++.


Eh? I don't see why the complexity needs to change based on the C++ code base. Let me quickly explain how we do it.

At our company if you want to communicate with our C++ engine or C++ build pipeline you only need to support two classes. The first is a messaging interface. The second is a dynamically marked up data structure. It's basically a dynamically generated data structure that supports reflection. This data structure which we call a property list is implemented in each language.

Example:
Game Tool Mouse move event. Send a mouse move message to the engine. The message contains the dynamically created property list data structure that contains the mouse position. On the engine side it receives a message and it reflects on the data structure and extracts the mouse position.

The build pipeline is all in C++. Any tool can send a message to the build process to tell it to build an asset. This allows our build process to stay heavily optimized but have nice fluffy slow GUI's sitting on top of it.

Additionally, a lot of our data structures that are built into the game are writting in an inhouse scripting language. This scripting language describes the data. Our exporter parses the scripting language data file - fills in the data into our property list and then creates a message and passes it to the build pipeline. By having just property list(data portion) and messaging interface implemented in any language of choice we will be able to interop it easily with our c++ engine.

To the original poster, we use C#/WPF for our tool applications. The renderer that sits in our tool is the actual C++ renderer that ships with the game.

-= Dave

Share this post


Link to post
Share on other sites
Quote:
Original post by RobTheBloke
Cross platform development is hard whichever language you are using. Most inhouse game tools will be locked onto a single platform (since the effort required to port code can't really be justified).


Sometimes it can be justified. For example, we wanted a cheap build farm so our build pipeline needs to compile on linux and windows. Also, most of our studio uses XP/32 bit. We then upgraded some artists computers to vista/64 bit because of art packages. This means that we had to have all our tools support xp/vista 32/64 bit because we can't justify spending the cost of upgrading 50 computers. It was cheaper to spend programmer effort on making our code base more cross platform.

Sincerely,
-= Dave

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
The problems with C# in tools are:
* Your tools usually need to communicate with or use the C++ engine. The more skilled your C++ coders are, the harder this gets due to the complexity and idiomatic characteristics of well written C++.
* Major tools typically predate C#/.NET being a legitimate/workable approach, leaving lots of legacy code to deal with.
* Game programmers tend to be unfamiliar with anything that isn't C/C++. (I've seen PHP, Perl, and C# code written by long time veteran game programmers. Aurgh.)

Most studios are pushing ahead with moving their tools over in spite of these blockades, which should be a hint as to just how highly valued these new toolsets are.

As for the C++ experience, candidly, everyone on a game project involved with engineering needs to know C++, period. The game is in C++, as are any number of tools/utilities/compilers.


There was an interesting post to the Toolsmiths blog about this several months back.

I would add that we use wxPython to develop our tools at CCP Games.

Share this post


Link to post
Share on other sites
Quote:
Original post by David Neubelt
Eh? I don't see why the complexity needs to change based on the C++ code base. Let me quickly explain how we do it.
It doesn't need to change, it just tends to. I'm in danger of overgeneralizing here, but communication with other languages tends to get lost on the requirements list when most people are designing a game/engine, which is why things end up this way. Obviously there will be exceptions.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement