So, I know there's a lot of topic around the power of C# to build game engines and I want to make a game engine using OpenGL.

I read that it's better to make the UI in C# (which i like very much), and the other things in C++. But my question is just this, how is the process? How to tie them together and make the two languages interact? What [s]is meant by "UI" when programming with C#[/s] (read: "what is for C# to build, and what is to C++")?

This part of the process is still confusing to me, and I don't have experience in graphics development, and I wanted to do this to really learn. So i'm open to suggestions and recommendations.

Thank you very much

Mauricio

Do you have a reason to bother with the hassle? Just make the whole thing in C#. What you've read about using C# for the ui is probably using it as a scripting language, rather than the actual language the ui was written in.

Unless your goal is to learn .net inter-op between C# and C++, I would suggest you just pick one or the other language and stick to it.

Generally, when people say "Use C# for the UI" they mean a couple different things. First, they probably mean "WinForms in C# is way better than Win32/GDI in C++" and it is. They also probably mean something like "Making a complex GUI in Win32/GDI is a lot of work" which is also true -- if you require a complex GUI, then C# and WinForms are a good way to go. However, unless you have a compelling need for both a complex UI and native code in C++, you shoud probably read this advice as "If you need a complex UI, use C# for the whole project, if you need C++ for whatever reason but don't need a complex UI, just use C++."


Most games don't have or need very complex UIs -- particularly not the ones that you need in-game. If you have complex settings, you could consider creating a launcher/configuration application in C#, but the game itself in C++.

The primary goal for this project is not a game, just a game engine itself, like Unity3D or UDK.

I think it'll be a fairly complex UI, and doing it with C++ is a pain in the a**. Also,by doing it in C# makes the development of the UI faster and let me focus on the core parts, like lightning, rendering, particles and the level editor.

So, freeworld, u said to make it all in C#. Is it good to make a game engine in C#? wouldn't it be slow for complex scenes and simulations? Also, I want to note that i want to make it in OpenGL, and yes I know of openTK,which is a good library for C#, but I don't plan to use DirectX....

Thank you for the answers so far, but i would like to hear more about, as what you guys said is specific to game programming, and not game engine dev.

So, Unity and UDK are not *just* game engines -- rather they are a whole suite of tools which *includes* a game engine. If we're speaking strictly, a game engine is something like Epic's Unreal Engine 3, Valve's source, or iD's iDTech engines. The engine is the code which runs the game as its being played, and is not necessarily one-in-the-same as the code which was used to build the game. Generally, there might be some shared components, such as a renderer, or their might not.

That being the case, you might build the tools -- things like the world-builder, scene manager, asset pipeline; all of which have complex UIs -- in .Net, and build the game engine proper in C++. You'll probably need a renderer of some kind in your tools. You could package the C++ renderer as a DLL and then use it in your C# applications through the .net inter-op stuff. You'll have to implement the proper hooks in the C++ side but probably very little, if anything, that you wouldn't need for the game engine itself (perhaps additional metrics, debugging stuff, etc). I'm not any kind of authority on how to go about that, but that's the basic idea.

You could implement separate renderers -- particularly if the needs of your tools are very different than the needs of the game engine. Shader-based programming makes a lot of things fairly portable in this way. In this case, you could use XNA, SlimDX or, more likely, any of the popular OpenGL bindings.

The primary goal for this project is not a game, just a game engine itself, like Unity3D or UDK.

I think it'll be a fairly complex UI, and doing it with C++ is a pain in the a**. Also,by doing it in C# makes the development of the UI faster and let me focus on the core parts, like lightning, rendering, particles and the level editor.

How do you know it will be a pain in C++? if you really do know this than you can probably answer this question on your own. Don't make assumptions, just cause you read it was hard for someone else.

So, freeworld, u said to make it all in C#. Is it good to make a game engine in C#? wouldn't it be slow for complex scenes and simulations? Also, I want to note that i want to make it in OpenGL, and yes I know of openTK,which is a good library for C#, but I don't plan to use DirectX....

Thank you for the answers so far, but i would like to hear more about, as what you guys said is specific to game programming, and not game engine dev.

[/quote]

C# isn't slow... JAVA isn't slow... they are just different. The main reason you might here so many people saying C/C++ is better to use and the industry consider-es it a standard. Is because it's been around longer, and there fore there is a huge code base out there already, so you don't have to reinvent the wheel on everything.

Also C# has nothing to do with DirectX... once again probably another assumption because so many people mention XNA and C#... that's just good marketing on microsofts side.

How do you know it will be a pain in C++? if you really do know this than you can probably answer this question on your own. Don't make assumptions, just cause you read it was hard for someone else.

It is a pain, i'm not saying that i read somewhere. I know this. and I said that doing in C# will be faster and that it would help me concentrate on the important parts.

C# isn't slow... JAVA isn't slow... they are just different. The main reason you might here so many people saying C/C++ is better to use and the industry consider-es it a standard. Is because it's been around longer, and there fore there is a huge code base out there already, so you don't have to reinvent the wheel on everything.

Also C# has nothing to do with DirectX... once again probably another assumption because so many people mention XNA and C#... that's just good marketing on microsofts side.
[/quote]

ok, so in C# I can have direct access do OpenGL and GLSL? I thought C# has kinda tied to directx, because of .NET, but if you say it's not....

JAVA is slow for this kind of project. And I'm not taking into account what i read other places, but in fact C# is slower than C++(though not sooo much), and i'm just worried if it will handle scene constructions.

[s]Also, if I choose to use C# for UI and C++ for the core parts, to tie them together I use the assembly code generated?[/s]

I'm liking the answers... thank you so far[s]

[/s]EDIT 1: Haven't seen Ravyne answer [s]

[/s]

So, Unity and UDK are not *just* game engines -- rather they are a whole suite of tools which *includes* a game engine. If we're speaking strictly, a game engine is something like Epic's Unreal Engine 3, Valve's source, or iD's iDTech engines. The engine is the code which runs the game as its being played, and is not necessarily one-in-the-same as the code which was used to build the game. Generally, there might be some shared components, such as a renderer, or their might not.

That being the case, you might build the tools -- things like the world-builder, scene manager, asset pipeline; all of which have complex UIs -- in .Net, and build the game engine proper in C++. You'll probably need a renderer of some kind in your tools. You could package the C++ renderer as a DLL and then use it in your C# applications through the .net inter-op stuff. You'll have to implement the proper hooks in the C++ side but probably very little, if anything, that you wouldn't need for the game engine itself (perhaps additional metrics, debugging stuff, etc). I'm not any kind of authority on how to go about that, but that's the basic idea.

You could implement separate renderers -- particularly if the needs of your tools are very different than the needs of the game engine. Shader-based programming makes a lot of things fairly portable in this way. In this case, you could use XNA, SlimDX or, more likely, any of the popular OpenGL bindings.
[/quote]

Hey, that's WHAT i wanted to hear. You got my point I wanna build a toolset, like UDK or Unity. And so, just tie them together in the form of DLLs. that sounds pretty good. Hm.... way easier than i thought. Also, there's not a problem if I make like, a level editor , using C#, or there is?

Thank you!

@OP:

Not to sound harsh or anything, it's certainly not my intention to flame, but I think you are going over this way too lightly
Toolsets as provided in the UDK or with the Unity engine are of a massive complexity, built by larger groups of experienced (and paid) developers

I heavily advise against just jumping into engine development out of the blue, an engine and related toolset should be something that evolves throughout your game development career, something that is made out of re-usable parts of previous projects with some possible refinements and additions; when you're at a point where you decide to build an engine, you should already know exactly what to expect from this engine and how to write it, I think many will agree with me if I say that if you have to ask how to write a game engine, or if you have to ask in which language it should be written, you are just not ready at all to write one

And about your UI issue, it's true that C# is easy when it comes to UI development since you can use winforms with visual studio to whip up something nice in a minimal amount of time (C# is a great language for GUI-oriented RAD after all), but for an actual game engine I wouldn't recommend a RAD-strategy for development nor would I recommend C# in general, not because of its so-called slowness, but rather (as mentioned before in this thread) for the huge code-base established for C++ when it comes to game-related programming (and maybe for the higher flexibility C++ provides when it comes to memory management). Also, since I don't like the idea of wrapping up my C++-based engine for use in .NET languages I use QT for all GUI applications which have to integrate or interact with the engine directly in some way, and I must say that I found it rather easy to work with, so maybe that's something to consider