Jump to content
  • Advertisement
Sign in to follow this  
CyberSlag5k

Is C++ dominant in tools development, too?

This topic is 3407 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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!