Full stack for a game built in C#?

Hello there,

A bit new here. I've been reading around on all sorts of things these past few days. Anyway I was wondering what folks around here would consider to be the best "full stack" for game development in C# using Mogre. i.e what would you use on top of Mogre for:

1. Input handling (MOIS? Windows Forms Input? SlimDX?).
2. Sound.
3. In-game GUI/windowing system.
4. Physics / collision detection.
5. Networking / multiplayer.
6. Any other components of a full game engine that I've missed?

(Or what are the pros/cons of different options in these categories)

A

Edit: I've compiled here the list of platforms in each category mentioned in this thread, for convenience.


+-----------+----------------------------------+
|Input | MOIS, XNA, SlimDX |
+-----------+----------------------------------+
|Sound | MogreFreeSL, XNA, fmod, irrKlang |
+-----------+----------------------------------+
|In-game GUI| Miyagi, MyGui, MQuickGUI |
+-----------+----------------------------------+
|Physics | MogreNewt, PhysX |
+-----------+----------------------------------+
|Networking | XNA, lidgren |
+-----------+----------------------------------+


A lot depends on what you want for user. Sometimes the user will have to download additional things to allow the game to run, but you could just package that with the installer. Here's my "stack" as you call it

Input: XNA, thinking of migrating to SlimDX, but in either case the user has to install the library.
Sound: XNA
GUI: Miyagi for Mogre, but XNA when I port to Axiom
Physics: MogreNewt (highly recommend this over others for Mogre, it's easy to update to the latest OgreNewt; but there's been a push recently for PhysX)
Networking: XNA

I like sticking with XNA, because it's one package that the user needs to install (and it's only the user redistributable, not the developer tools) and it contains just about all I need.

I was under the impression that MS abandonned XNA for the PC and concentrated on the XBox only? I take it that I either got it wrong or that's no longer the case?

Input: XNA, thinking of migrating to SlimDX, but in either case the user has to install the library.

Are you thinking about the licensing issues.
Right now I'm using Microsoft.Xna.Framework.dll just copied to my application bin directory and dynamically linked to my application.

I was under the impression that MS abandonned XNA for the PC and concentrated on the XBox only? I take it that I either got it wrong or that's no longer the case?

XNA is using .Net Compact Framework on XBOX 360 so it's not that they have to create two separate products for PC and XBOX.

Licensing actually only applies to Windows Live games, but I mentioned that I am using XNA for networking, so I will run into that problem.

XNA is very well supported for both windows and xbox games, however it costs money to make xbox games, which may be where you got that impression from.

Here's what I'm using as of right now:


1. Input - MOIS

2. Sound - MogreFreeSL

3. In-game GUI/windowing system - Making my own from MOIS, SpriteManager, and this for text display.

4. Physics / collision detection - MogreNewt

5. Networking / multiplayer - I'm making a single-player game.

6. Any other components of a full game engine that I've missed? - I don't think so...

Good luck!

The "stack" I used in the past was comprised of these components:

3D rendering: Mogre/Ogre (surprise, surprise )
Sound: MogreFreeSL
GUI: MyGUI
Effects: Particle Universe (with my own wrapper)
Physics and collisions: PhysX (with eyecandy wrapper)
2D rendering and input: SlimDX

I was always happy about how good these libraries could be integrated to form some kind of "game engine" that allows for rapid prototyping and it would also be the most likely combination (for me) if I would ever have to create a commercial game with C# for Windows.

Targeting other platforms is another story and I would most certainly create my own (automated) wrapper with P/Invoke support for all these components. Then, of course, I would use this wrapper for all platforms, including Windows, to make absolutely sure that I get the same bugs everywhere

So you don't consider C#/Mogre a very good candidate for a commercial game?

Input: Mois
Sound: fmod (free for non-commercial usage)
GUI: Miyagi (obviously)
Networking: lidgren

So you don't consider C#/Mogre a very good candidate for a commercial game?
Well, there is at least one commercial game that uses Mogre.

So you don't consider C#/Mogre a very good candidate for a commercial game?
Quite the contrary, I would even recommend the combination of libraries that I outlined in my last post to people that want to create a game with C# for Windows. That's because I was already using Mogre when Ogre was still in version 1.2.x. That was years ago and I was creating some game prototypes for the company I was working for at that time. These games never made it past the prototype stage, but we would have developed them with Mogre and C# for sure.

But the decision which libraries and engines should be used for a certain project always depend on several factors. If you want to target only Windows as platform, you should be fine. If you want to create what I call slow-paced games (adventures, strategy games, etc.) it's in my opinion a good choice. For fast-paced games (shooters, racing games, etc.) it is hard to tell if Ogre itself is optimized enough to provide you with the rendering power your game needs. But then, if Ogre fits your needs, I'm pretty sure that C# and Mogre would also work as well.

Most people I talked to in the past were (and some still are) in the impression that a managed environment like .NET is not suitable for games, because it's too slow. That's just bullshit (sorry to say), it always depends on how you use a language and how well you understand the environment you use. I can easily show some examples of C++ code that will just kill all your performance because of bad coding, the same is also true for C#. But if you know what you can do and what you should not do, then C# is as good (if not better) than anything else.

So, analyze your requirements, code some test applications for the critical parts, do a lot of profiling and you will be fine. Also read articles about the internals of the CLI runtime and ask people for advice that already have experience with managed code in a performance critical project. And most importantly, don't make assumptions about what might be if you have not tried it yourself.

I'm always amazed by comments I heard from people about certain aspects of game development with C# when I later found out that they actually never tried that themselves. Just don't forget that C# is not C++ and not everything will work the same way.

I could write for hours about the differences and similarities between managed and unmanaged game development, but I think that (for today) it should be enough

Most people I talked to in the past were (and some still are) in the impression that a managed environment like .NET is not suitable for games, because it's too slow. That's just bullshit (sorry to say), it always depends on how you use a language and how well you understand the environment you use. I can easily show some examples of C++ code that will just kill all your performance because of bad coding, the same is also true for C#. But if you know what you can do and what you should not do, then C# is as good (if not better) than anything else.

So, analyze your requirements, code some test applications for the critical parts, do a lot of profiling and you will be fine. Also read articles about the internals of the CLI runtime and ask people for advice that already have experience with managed code in a performance critical project. And most importantly, don't make assumptions about what might be if you have not tried it yourself.

I have to agree with mstoyke here...to some degree. I was a developer for the Sims 3 and our engine was a mixture of C++ and C# (mono). In fact, one of my areas of work on the project was overall performance and optimization. There's no doubt in my mind that C++ is still a faster language. However, that gap is steadily shrinking, and it's to the point now where it's quite reasonable to have at least parts of your game done in C# (as we proved quite definitively, I would say). There's no question that C# is a faster language to develop in. You can certainly balance the trade-offs in performance with the speed of development. Leave your rendering and performance-critical code in C++ (for now at least), but I personally think it's fine to do the bulk of your game in C#.

Given a few more years, C# might even get fast enough to do a full engine reasonably well. In fact, I suspect it will be. Remember, at one point no one wanted to use C++ for games because C was so much faster. Now, though you can still eke out SOME performance benefits by using C or assembly in performance-critical code sections, nearly all game engines are fully C++ these days because C++ is easier to develop in than C (or *gasp* pure assembly). In other words, the benefits of rapid results are worth the small performance trade-off you end up paying.

Things change. C++ won't necessarily be the performance king forever.

Anyone else? How do folks here compare between these different components?

I wonder if there isn't anything other than lidgren or XNA in the networking category?

A

There's always System.Net.

There's always System.Net.

Yeah have to agree here but it takes you down to basics so unless you have wrote your own protocols before you might want somthing higher level but heres a link to the bit I recommend you look at.

http://msdn.microsoft.com/en-us/library ... 80%29.aspx

SlimDX, but in either case the user has to install the library.
You just need to copy the file SlimDX.dll to your project and link it. Not further installation is needed. (A up-to-date DirectX is a depency, but this is still needed for Ogre/Mogre. So it's no additionally depency.)

So you don't consider C#/Mogre a very good candidate for a commercial game?
I think it is a good candidate. (My own opinion - but I'm no professional developer.)
(Aside from a possibly slower initialization/loading process) the rendering is as fast as C++ Ogre.
Not all add-ons of C++ Ogre are available (by wrapper or ports), but Mogre still has powerfull, stable add-ons for different cases.

I know a free, non commercial game created by Mogre: Wings of Fury 2

Networking: lidgren
I just did a quick look to its website, but I still have question:
Is is possible to connect to applications which are written in C++? (Means: is there a client library for C++)



My application is no game, it's scientific (underwater visualization and sonar simulation).
For this I use these components:

Graphic: ..... Mogre
GUI: ..... Windows.Forms for the main application and WPF for a helper tool
Collision detection: ..... Newton (by MogreNewt)
Networking: ..... my own data protocol, using TCP and UDP by .NET classes TcpListener, TcpClient and UdpClient (namespace System.Net.Sockets)
Input for keys: ..... (e.g. moving) the KeyEventHandler of Windows.Forms example: this.renderPanel.KeyDown += new KeyEventHandler(renderPanel_KeyDownHandler);
Input for Buttons, TextBoxes, etc.: ..... the common event handlers
Input for Gamepad: ..... it's planned; in an other project I used SlimDX
Logging: ..... [b]Log4net[/b]
Sound: ..... [no sound]

I just did a quick look to its website, but I still have question:
Is is possible to connect to applications which are written in C++? (Means: is there a client library for C++)

I'm not aware of any existing C++ library for lidgren, but the client would only have to be able to send/receive UDP packets in their layout.

Is there any info about lidgren network library performance?
Like is there a possibility that it will handle 2000+ connections - i know its a matter of packet size but CPU usage as well and how library handle everything.
If someone can enlight me about it I'd be thankful.

Back to topic:

Input - trying SlimDX - mouse sucks so far =D
Graphic - guess
Sound - havent tried any yet
Network - System.Net or ?... looking for any
Interface - MyGUI (but XML part is pain for me)

Cheers

Hello everyone

What we are developing is not actually a game it is more likely be in the category of serious game / simulation. We develop our software with a team of four which 2 of them is occasionally login to the forums with names acnirak and kdr35. Of course myself too is included.

Our electronic department produces lasers which triggered by the fall of the hammer on a gun which then emits a laser beam to a projected screen where we pick up the hit point with a camera using image processing. so you can hit the targets with a modified gun. The correct position of the bullet in 3d Scene is than calculated by a complex trajectory external ballistics calculation which includes air density, wind, drag function of the aerodynamics of the bullet and so on.

Anyway
Input: We dont use a ınput capture as our software supposed to run on desktop we get the mouse click events and laser hits from the projected screen thats all, rest is normal desktop application usage.
Sound: Microsoft.AudioVideoPlayback or something like that it sucks big time we will change it soon. probably to MogreFreeSL.
GUI: We tried MyGUI but I failed to get it show different GUI is on different renderwindow it only works on the single window as far as I know so we have still a problem in this area. If anybody has detailed info it would be really good. We use System.Windows.Forms TopMost property for now until permanent solution found(I know it is so amateur we will change it).
Physics: Minimal ogre collision for now, We need rag dolls so I think we will go Physx but we havent investigated the issue if mogrenewt has that support we will decide between them. Sorry for Captain obvious behavior.
Networking: For future we will include combat between two system. I have quite a toolbox and experience in network programming so most probably System.Net will be our choice.
Extra: We have RS232 support in our engine. Now! that is not something you see everyday in a game engine

Edit: Corrected some silly typos.
Edit 2: After one year of development or GUI is now miyagi which we are fairly happy with.

Tanks for your detailed report

Physics: Minimal ogre collision for now
Interesting to know. Two years ago I couldn't find any information about intregrating MOC to Mogre. Also later I never heard about this.
Do you use MOC in a .NET application?
If so - is there any further information in the internet?


About your GUI problem - Maybe the add-on Miyagi can fit to your multiple screen application.
http://www.ogre3d.org/tikiwiki/Miyagi
By the way - do you use one single renderwindow which shows 3 viewports or do you have 3 seperate render windows?


Related to PhysX - On yesterday I found a demo application for Mogre on a private website. I contacted the author (user hedphelym) and he said, he want to provide more demo applications and maybe he add some information to the wiki.
Look to this post and follow the topic. You also can ask the author. Maybe he can give you more detailed information about your ragdoll questions ... or optionally ask him to be a freelancer supporter, who write PhysX code for you

The thing I used for physics is from the mogre wiki actually http://www.ogre3d.org/tikiwiki/Raycasting+to+the+polygon+level+-+Mogre we changed to get some UV coordinates as all we need is a collection with a bullets trajectory line(inverse logarithmic curve like structure) and as far as I know MOC is based on that simple algorithm. I may be wrong but I checked around.

About the GUI yesterday I ressurected my old post about it and got an answer this time from the MyGUI team http://www.ogre3d.org/addonforums/viewtopic.php?f=17&t=13255 the post is at this link. It seems there is a work around forcing MyGUI to draw on texture(RTT) then putting it on our RenderWindows. By the way we use 3 renderwindows for 120 degree view and more for a wider view but haven't tried more than 120 degrees yet. Plus there is usually one more renderwindow in the control form for visualization of the targets in front of the trainer.

Just Checked the site you gave Beauty I did found it 2 days ago too thank you anyway and I think it may really help me.

I noticed nobody mentioned irrKlang for sound: http://www.ambiera.com/irrklang/

It's free for non-commercial use and fairly cheap for commercial use. I'm not saying it's the best one, because I've only used it a little bit but it's worth mentioning.

There is no even one single page on ogre3d.org, which contains the words Mogre and Irrklang.
If you know if it's possible to embedd Irrklang to Mogre, it would be nice when you open a new thread and write some details about.
On the website I saw the menu point API.NET. So there could be a good chance to use it.
Did you embed Irrklang into your Glue Editor?

(It's off topic, but it would be nice when you add these links to your project site on code.google: wiki page and forum topic. Additionally it's nice to see that you still develop this editor. I will look to it again in the future.)


Also I want to give a note to this quote:
Also, I know Irrklang is easy to work with, but its fairly featureless. I would suggest switching to FMODex if possible. They have a Geometry occlusion library integrated! I may be able to help with this.
FMOD seems to be usable for sound in Mogre.
Look to the forum topic FModNet Sound Library Manager code v0.1 and the wiki page FMOD SoundManager.

There is no even one single page on ogre3d.org, which contains the words Mogre and Irrklang.

There are a couple of references around on the forums and on the wiki that mention it can be used in C# which is basically the same thing as saying it can be used with Mogre.
For example: http://www.ogre3d.org/tikiwiki/List+Of+Libraries#Audio

If you know if it's possible to embedd Irrklang to Mogre, it would be nice when you open a new thread and write some details about.

I actually don't know a lot of the details because I've only done a few tests to make sure it would work when the time comes that I need sound. What I do know is that it's not very difficult to get it working. The following code demonstrates basic use with Mogre.


// initialise
ISoundEngine soundEngine = new ISoundEngine();
soundEngine.SoundVolume = 1.0f;

// set listener position (usually at the camera)
Vector3 position = camera.Position;
Vector3 direction = camera.Direction;
soundEngine.SetListenerPosition(position.x, position.y, position.z, direction.x, direction.y, direction.z);

// play a sound somewhere in the scene
ISound sound = soundEngine.Play3D("test.wav", position.x, position.y, position.z);
sound.MinDistance = 5; // distance that the sound plays at full volume


And that's pretty much all there is to it. There are tutorials on the irrKlang website that explain how to use all the features.

Did you embed Irrklang into your Glue Editor?

Yes, although only very minimally. I just wanted to make sure that I could get sound working so that my project didn't come to a grinding halt when I get around to implementing the rest.

(It's off topic, but it would be nice when you add these links to your project site on code.google: wiki page and forum topic. Additionally it's nice to see that you still develop this editor. I will look to it again in the future.)

There is already a link to irrKlang on the google code page here: http://code.google.com/p/glueengine/wik ... FromSource
The Glue Editor is not really ready for public use which is why I haven't documented it on the Ogre wiki. I'm still developing it but it's not my current priority. Most of my time and energy goes into developing a game but I'll certainly be updating the Glue Editor as I go. There doesn't seem to be enough interest in it to keep working on it endlessly until I've got a game project that uses it.

FMOD seems to be usable for sound in Mogre. Look to the forum topic FModNet Sound Library Manager code v0.1 and the wiki page FMOD SoundManager.

Yes, FMOD is certainly an alternative. However, it's very expensive to use commercially (around $3000) compared to irrKlang (around $85). So I can't really justify the cost for the extra features that I probably won't use. Also, irrKlang has a stable .NET wrapper provided by the original developers.

MOIS seems to be an awesome input abstraction layer. It's been easy imho to buffer and/or event drive your input handlers with MOIS. I think it's cross plaform compatible, and seems lightweight.

off topic
-----------------------------

Thanks, now I created the wiki page IrrKlang for MOGRE and added basic content.
Feel free to add more content.

There is already a link to irrKlang on the google code page here: http://code.google.com/p/glueengine/wik ... FromSource
No, I mean the link to the Glue Editor wiki page in the Ogre wiki. And to it's forum thread in Ogre forum.

Sorry for hijacking this topic.