Sign in to follow this  
mauriciocinelli

C# Game Engine Development Question

Recommended Posts

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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++.

Share this post


Link to post
Share on other sites
The primary goal for this project is not a game, just a [i]game engine[/i] 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, [b]freeworld, [/b]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.
:D

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
[quote name='Mauricio Cinelli' timestamp='1307145836' post='4819264']
The primary goal for this project is not a game, just a [i]game engine[/i] 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.
[/quote]

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.

[quote]
So, [b]freeworld, [/b]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.
:D
[/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.

Share this post


Link to post
Share on other sites
[quote name='freeworld' timestamp='1307157597' post='4819294']
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.
[/quote]

It [b]is[/b] 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.

[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.
[/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# [b]is[/b] 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][b][u]EDIT 1: Haven't seen Ravyne answer [/u][/b][s]

[/s][quote]
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!

Share this post


Link to post
Share on other sites
@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

Share this post


Link to post
Share on other sites
[quote name='Radikalizm' timestamp='1307188705' post='4819394']
@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
[/quote]

You're right, in almost everything you said. However you discouraged me a lot by what you said and your nickname :mellow:

I know these "engines" are built by hundreds of skilled people and throughout a long time. But I want to force myself to learn, and build something along the way, even if it takes me years. However I don't wanna make a game.... i just want to code. I don't know if i'm clear until here...

After all, I want to learn. So I don't expect to be [b]AS[/b] UDK or Unity, but I want to make something like them. Also, I heard A LOT about QT, can you please tell me if it's easy to pick up? or it's better to stay using C# for the UI thing...

One thing, i don't wanna start a war here, just want some opinions... and if i REALLy can't do an engine right now, it's ok, but convince me, what a engine differs so much of making a game? (in terms of graphics), i will have to make a renderer in both cases, and will have to make some general game programming in both cases....

Thanks

Share this post


Link to post
Share on other sites
A renderer is just one of many components a good game engine needs to have, there's a lot more to an engine besides graphics

A game can be written rather linearly, you can set out your game requirements, you can decide on a graphical style, a genre, etc.
An engine is supposed to be a platform on which various games can be built, it should 'abstract away' (although this isn't really the right word for it) all lower-level APIs into a comprehensive set of re-usable tools which can be used for a good amount of games of varying types, although many engines restrict themselves to a limited amount of genres, since a 'one-solution-fits-all' engine is almost impossible to do

To give a simple and minimal example, an engine should be able to let the user set up a rendering environment with enough flexibility, without the user being forced to go through OpenGL or DirectX (or whatever API you are using) interfaces directly; a good engine would even provide ways to set up its rendering environment with different graphics APIs (and even different versions of varying graphics APIs) in a uniform way while maintaining the same functionality independent of the chosen API.
If you take your time to think about this for a while, you can see that even this basic engine feature can bring up a lot of complex issues (eg. how are you going to manage shaders for all those different core APIs through a single interface, while maintaining the same functionality?), while in the case of you writing a game you could just set up an API of your choice the way you need it for your game and not worry about it anymore later on

I barely scratched the surface here, since an engine's complexity can and will go much deeper than this, but I hope I could clarify things somewhat

You won't learn too much from writing an engine, since you'll probably end up rather frustrated when you can't figure out something essential (not to mention the headaches this frustration will cause)
With writing games however, you will learn a lot since you can start simple and grow into more complex projects afterwards, which in the end will give you a good knowledge about games and their underlying mechanisms, allowing you to build that engine ;)

Share this post


Link to post
Share on other sites
[quote name='Radikalizm' timestamp='1307191091' post='4819399']
A renderer is just one of many components a good game engine needs to have, there's a lot more to an engine besides graphics

A game can be written rather linearly, you can set out your game requirements, you can decide on a graphical style, a genre, etc.
An engine is supposed to be a platform on which various games can be built, it should 'abstract away' (although this isn't really the right word for it) all lower-level APIs into a comprehensive set of re-usable tools which can be used for a good amount of games of varying types, although many engines restrict themselves to a limited amount of genres, since a 'one-solution-fits-all' engine is almost impossible to do

To give a simple and minimal example, an engine should be able to let the user set up a rendering environment with enough flexibility, without the user being forced to go through OpenGL or DirectX (or whatever API you are using) interfaces directly; a good engine would even provide ways to set up its rendering environment with different graphics APIs (and even different versions of varying graphics APIs) in a uniform way while maintaining the same functionality independent of the chosen API.
If you take your time to think about this for a while, you can see that even this basic engine feature can bring up a lot of complex issues (eg. how are you going to manage shaders for all those different core APIs through a single interface, while maintaining the same functionality?), while in the case of you writing a game you could just set up an API of your choice the way you need it for your game and not worry about it anymore later on

I barely scratched the surface here, since an engine's complexity can and will go much deeper than this, but I hope I could clarify things somewhat

You won't learn too much from writing an engine, since you'll probably end up rather frustrated when you can't figure out something essential (not to mention the headaches this frustration will cause)
With writing games however, you will learn a lot since you can start simple and grow into more complex projects afterwards, which in the end will give you a good knowledge about games and their underlying mechanisms, allowing you to build that engine ;)
[/quote]

Hm.... got your point, but i'm sad that i won't be able to do it now....
I didn't want o make a game, because i'm not good in arts and don't know anyone who can model... so I though it would be nicer to make an engine.

:unsure:

Do you guys recommend some books about game programming? I think i'll try to get a group in the internet to make a game.... and get some experience

I'm impressed by the answers, as I was thinking way too "high level", and forgetting about the complexity of the underlaying parts, like support for multiple api and other creepy things.

Thanks for putting my feet on the ground

Share this post


Link to post
Share on other sites
I think most of the people on here have been in the same position you're in right now, I know I was some years ago

I'd recommend you start off on your own (leave the team-based programming for when you have a little bit of experience) and do some really simple projects in your language of choice, some classic beginner recommendations are tetris, space-invaders or even pac-man clones
I know that these games might not sound too exciting at first, but as soon as you start working on them you'll find that the experience of developing these rather simple games will be very enjoyable
To help you out in the process you could always use some existing basic engines for things like rendering and audio, if you don't want to work directly with core APIs
Some good recommendations for rendering engines which I personally have experience with would be the Irrlicht engine or OGRE (although I'd say irrlicht would be easier if you're an absolute beginner, it's a very powerful but user-friendly engine, while OGRE can be rather intimidating at first)

Whatever you choose to do, I wish you the best of luck [img]http://public.gamedev.net/public/style_emoticons/default/wink.gif[/img]

Share this post


Link to post
Share on other sites
Yeah, I was a little confused and lost.

Thank you for the advices, and i'll try to make some simple things. I'll try to make like a roadmap, passing trhough these simple games, then 2d and then 3d, and later a game engine.

I'm thinking in starting making these in xna, as it gives a little abstraction of the apis, as i get the concepts and the mechanisms of gameplay programming and other stuff. Although OGRE is pretty nice and I have already tinkered with it a bit, and I find its capabilities awesome.

Hope this topic help another people with the same situation as I [s]am[/s] was.

Thank you Radikalizm and Ravyne, for understanding what I was trying to say and for the great answers and directions.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this