51 replies to this topic

[Maurício André Cinelli]

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

[kunos]

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.

[Maurício André Cinelli]

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

[kunos]

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.

[Radikalizm]

Does scripts and level editors count in the responsibilities of a tools programmer to make?

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

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?

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++.

[phantom]

Important point;

"Managed C++" is dead; C++/CLI is it's much better replacement.

Sure, I wouldn't write a whole app in it, however for interop of C++ <--> C# it's the best tool for the job.

It doens't even have to be that complicated; you don't have to wrap EVERYTHING, just use the C++/CLI dll to expose functionality to let you interact with the game/engine.

For example if you had an enemy class you wouldn't expose that directly but you would expose functionality to let you create and manipulate an enemy instance.

[Maurício André Cinelli]

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

[kunos]

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.

[Maurício André Cinelli]

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....

[kunos]

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

[Maurício André Cinelli]

Forms feels faster and more similar to the way RAD software has been for the last 15 years..

I'm talking about this part, which (in other words) you say that it feels more stable, faster and similar to what people use.... or at least, this sentence seems this to me. That's what i meant when saying about standard.

[phantom]

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?

The syntax is basically the same, they just add a few extra symbols to allow the 'unmanaged' and 'managed' world to be bridged.

For example in C++ you have the pointer syntax Entity * for instances on the unmanaged heap, in C++/CLI this has been extended so that you have Entity ^ which is a pointer/handle to an object on the managed heap. Which you select depends on where the object exists and who needs to use it.

There is a bit of learning involved of course, but it's surprisingly simple and MS have done a good job with the language.

As for WinForms vs WPF that's very much a depends.

Last project I was on, all the GUI tools were WinForm based; this project they are WPF based.

WinForms are fast to throw together, however WPF does allow you to do more (such as skinning) but as to if you need it only you will know.

The only issues I know about regarding D3D and WPF is that WPF can only be used to draw to D3D10 textures, not D3D11. However this is only a problem if you intend to use WPF to render INSIDE your D3D app. I don't know of any issues when it comes to having D3D rendering to a control inside a WPF app, nor would I expect there to be any.

[Maurício André Cinelli]

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?

The syntax is basically the same, they just add a few extra symbols to allow the 'unmanaged' and 'managed' world to be bridged.

For example in C++ you have the pointer syntax Entity * for instances on the unmanaged heap, in C++/CLI this has been extended so that you have Entity ^ which is a pointer/handle to an object on the managed heap. Which you select depends on where the object exists and who needs to use it.

There is a bit of learning involved of course, but it's surprisingly simple and MS have done a good job with the language.

As for WinForms vs WPF that's very much a depends.

Last project I was on, all the GUI tools were WinForm based; this project they are WPF based.

WinForms are fast to throw together, however WPF does allow you to do more (such as skinning) but as to if you need it only you will know.

The only issues I know about regarding D3D and WPF is that WPF can only be used to draw to D3D10 textures, not D3D11. However this is only a problem if you intend to use WPF to render INSIDE your D3D app. I don't know of any issues when it comes to having D3D rendering to a control inside a WPF app, nor would I expect there to be any.

The issues that I saw related to D3D were from a earlier version of WPF and C# itself, i think it was 2 or 3, don't remember. So the problem using WPF with D3D in when i try to render using WPF? IF I have a GUI made in WPF that wraps, let's say, a game engine, I should have no problems? ( as long as the function calls are correct between C++ and C#)

Regarding the C++/CLI, I saw the ^ thing earlier and found it interesting though.

[KenD]

Try XNA for C# gaming.

[Maurício André Cinelli]

Well, XNA is exactly for what you said, to make games. But we're talking about tools development, which is different than game developmen, but essential, specially on big companies.

[A Brain in a Vat]

Tools don't have to run within the game.

At one of my former companies we had tools that were written in C# that ran independently. The artist would typically be running the game, usually on a different machine or on a console dev box. Changes would be made to some art asset, and the artist would choose to send those changes to the game, which would then update itself accordingly.

[Maurício André Cinelli]

Tools don't have to run within the game.

At one of my former companies we had tools that were written in C# that ran independently. The artist would typically be running the game, usually on a different machine or on a console dev box. Changes would be made to some art asset, and the artist would choose to send those changes to the game, which would then update itself accordingly.

Wow, this looks awesome! and yeah, i know tools usually don't run inside the game...

Content pipeline tools are great.

But a question just popped on my head, regarding some earler answers. Ok, I do the UI in C# or whatever language, and the game engine guy makes the engine in C++, who writes the wrapper, in this case in C++/CLI? Me or the game engine guy?

Thank you for your time and answers so far

[Radikalizm]

Tools don't have to run within the game.

At one of my former companies we had tools that were written in C# that ran independently. The artist would typically be running the game, usually on a different machine or on a console dev box. Changes would be made to some art asset, and the artist would choose to send those changes to the game, which would then update itself accordingly.

True, this is ideal for tools like asset editors and such, but when it comes to scene editing I could see it become a real pain to separate the editor from the actual scene view, or am I not considering something?

[ApochPiQ]

But a question just popped on my head, regarding some earler answers. Ok, I do the UI in C# or whatever language, and the game engine guy makes the engine in C++, who writes the wrapper, in this case in C++/CLI? Me or the game engine guy?

You're in a restaurant, and you order a salad. Which chef prepares it?

[Maurício André Cinelli]

But a question just popped on my head, regarding some earler answers. Ok, I do the UI in C# or whatever language, and the game engine guy makes the engine in C++, who writes the wrapper, in this case in C++/CLI? Me or the game engine guy?

You're in a restaurant, and you order a salad. Which chef prepares it?

I hate metaphors.... anyway, so the game engine guy makes the wrapper(hope so) . Sorry if I don't understand you right....