Ok, some time ago I asked here about making a game engine in C#, and with the answers, I realized that I'm not currently able to make one, as it's a very complex project and a beginner doesn't have enough experience to build one.

So, as I started making some other things and little games, like pong, I found a job entry for a tools programmer, and that really caught my eye, and after that I decided to be a tools programmer.

So far i'm (still) getting experience with C# and WPF. But the biggest problem is finding articles and stuff on tools development.

In my vision, C# and WPF seems pretty good for tools, however, in the few articles i've seen, they said that as they needed wrappers to integrate with, let's say, the game engine, things started to get complicated, code duplicated and features limited. My concern now is knowing if C# and WPF is a good choice for tools development, or just C++ with a "framework", like Wx or QT is the way to go.

The articles i've seen are from 2009 mostly, so a lot could have changed since then.

Also, I'm aware that different tools may need C++, others could just be implemented in C# or any other language that best fits. Is anyone here in the field? If yes, can you give me more examples of tools that you have done, so I can get more concrete examples? and also, which languages/frameworks do you use most of the time?

I'm very excited about this and I hope i'm at the right place to ask about this.

Thank you very much

availability of tutorials cannot be used to judge if a tech is good or not for the job.

It is unlikely to find these kind of tutorials because they're very implementation dependent.

Here is what i got from direct experience. Tools are build on the top of an engine. Mostly likely you'll have to deal with a C++ engine.

You have 2 possible approaches to host that engine in your C# application.

1) You build a C++ dll and expose the engine through pure C functions. You should look at things like OpenGL or ODE for examples about wrapping "objects" into pure C calls.
In C# land then, you will create a P/Invoke static class that binds all the function exposed in the DLL.

2) You build a managed C++ wrapper around the engine and then reference that from your C# code.

I'd say approach 1 is nice because you work with "real" C++ and "real" C#... the problem is that you'll have to write every function 3 times.. in the native class, in the C layer, in C# P/Invoke layer.. this can get annoying after a while.
Approach 2 forces you to deal with "managed C++" which isn't nice, plus, MS has the bad habits of changing it from version to version, so you managed C++ VS2005 code might not work with a new version of the compiler, and you'll have a massive rewrite to do. Plus you need to learn a new syntax to do things in the .NET way.
I have tried both and tend to prefer the managed C++ approach.. but when you spend lots of time in C# you'll start to hate every minute of C++ .

Anyhow, you'll need to become really familiar with P/Invoke and marshalling stuff from native to C# and back... if that's what you want to do, get started with learning how to call functions, move data, move strings, structures back and forth... cause you'll be doing lots of it for your tools.

availability of tutorials cannot be used to judge if a tech is good or not for the job.

It is unlikely to find these kind of tutorials because they're very implementation dependent.

Here is what i got from direct experience. Tools are build on the top of an engine. Mostly likely you'll have to deal with a C++ engine.

You have 2 possible approaches to host that engine in your C# application.

1) You build a C++ dll and expose the engine through pure C functions. You should look at things like OpenGL or ODE for examples about wrapping "objects" into pure C calls.
In C# land then, you will create a P/Invoke static class that binds all the function exposed in the DLL.

2) You build a managed C++ wrapper around the engine and then reference that from your C# code.

I'd say approach 1 is nice because you work with "real" C++ and "real" C#... the problem is that you'll have to write every function 3 times.. in the native class, in the C layer, in C# P/Invoke layer.. this can get annoying after a while.
Approach 2 forces you to deal with "managed C++" which isn't nice, plus, MS has the bad habits of changing it from version to version, so you managed C++ VS2005 code might not work with a new version of the compiler, and you'll have a massive rewrite to do. Plus you need to learn a new syntax to do things in the .NET way.
I have tried both and tend to prefer the managed C++ approach.. but when you spend lots of time in C# you'll start to hate every minute of C++ .

Anyhow, you'll need to become really familiar with P/Invoke and marshalling stuff from native to C# and back... if that's what you want to do, get started with learning how to call functions, move data, move strings, structures back and forth... cause you'll be doing lots of it for your tools.

Both ways does the job, but the second one, the managed C++, is very ugly and as you said, MS changes stuff quite often.... so, in this case, using C++ for tools wouldn't be better?
I mean, by using C#, on this kinds of problems, you lose time wrapping functions and in the managed code, as you gain in the rapid UI and the development of the "tool itself".

For an example, i find that QT has a great designer for the UI and provides some great libraries/utilities that can help in the aspect of rapid development, so can I compare it to MS C# with WinForms/WPF?

One of the things that i like about this job is that we don't get any credit of the games, instead I would get my "reward" in making another's job more easy and fluid. Does scripts and level editors count in the responsibilities of a tools programmer to make?

Thank you for the answer so far

QT is not bad, but you can't compare it to the level of productivity you get using C#... The trick is to identify the minimum amount of functionalities that need to be exposed from the native code.. and keep as much logic in the nice and fast C# environment.
I have used QT for a resolution/options panel in my last project and it was ok but I wouldnt use it for a full level editor.

If you want to stay in C++ land you might have a look at what Borland is doing with the C++ Builder line. I have used C++ Builder in the past and it was brilliant although you still have the problem of connecting the engine since the Borland compiler doesn't agree with the MS one on library formats (it used to be the case).. so you'll have to compile your engine in C++ Builder.. and this could lead to more problems.

At the end of the day... I'd stick to a C# / Forms / Managed C++ solution which is what I am currently using.

[color=#1C2837][size=2]Does scripts and level editors count in the responsibilities of a tools programmer to make?[/quote]


Seeing as these are in fact tools, yes designing and implementing these applications would be part of a tool programmer's job.

[color=#1C2837][size=2]For an example, i find that QT has a great designer for the UI and provides some great libraries/utilities that can help in the aspect of rapid development, so can I compare it to MS C# with WinForms/WPF?[/quote]

I doubt that developing a GUI-based application in C++ with QT would be possible in the same time you could develop one with visual studio in C#
Personally I use QT with C++ for my tools which need to access my engine directly, but I find it a serious pain to keep this up, especially with QT generating additional code for custom widgets through a preprocessor (if you could call it that) which can get messy to keep organized imo.

I'm seriously considering writing a .NET wrapper for my engine at the moment so I can use it in C# (or any .NET language for that matter); I love C++ for engine development, but I absolutely hate it when it comes to GUI-based development, so I'd rather go through the process of writing a wrapper instead of having to write and maintain my tools in C++.

Hum.... i see your points. So, no way to compare QT to C#, which is great, because i don't like so much the idea of leaving "the cleaness of code all the way". So i guess the time speind on the wrappers and "glues" is lower than the time spend doing in C++, which is very reasonable...

I'm starting to love this job more and more, though I need to learn more about C++ <-> C# interopability and how to tie them together...


But, C++/CLI is a whole another sintax compared to pure C++, and it would kind of act like a wrapper, but it will be like a "middle class" that interacts between the C++ code and C# code? am i right?

Kunos, i thought C++ builder was dead.... i don't see much "news" about it for a long time....

Also, i don't know if you can answer this but... is it preferable to use windows Forms or WPF for UI development? Because i saw some articles from 2009 that pointed some problems in integrating D3D or engines that use it, with WPF.

But thanks for the answers so far

Borland is still up.. perhaps they've changed into Embarcadero or something like that, I did try the new C++ Builder some years ago and it was sweet but pricey (we have been all spoiled by VS ). I still get offers from them in my email, so I think they're alive.

I don't have experience in WPF... every time I tried to use it, it felt slow, cumbersome and unispiring... I just fail to see the point behind it.
Forms feels faster and more similar to the way RAD software has been for the last 15 years.. so I stick with Forms.... just marshall the Handle property to the engine and it'll work with DX, OpenGL and everything else.. easy and fast.

So i guess by your answer that Windows Forms are kind of a "standard" for game tools, right?

WPF is good, and has some advantages over WinForms, but I think in the field of games, which we need to interop with C++ a lot, WPF is too high level, and using it with a low level game engine, is not a good thing, and you can end up with a buggy tool and a non-functional. Found this by reading, but again, from articles from 2009.... so maybe M$ resolved this.

Nice that C++ builder isn't dead, and Embarcadero has put together some nice tools and i'm seeing now, almost like a "visual studio". And also i agree that we are spoiled by VS....

So i guess by your answer that Windows Forms are kind of a "standard" for game tools, right?

No,
the fact that I am using it doesn't make it a standard