Deciding on MOgre ... about WPF, alternative C# engines, etc

elfric

27-08-2010 17:27:01

Hi, I'm pondering on which engine to use based on my project requirements (which are, admittedly fuzzy at the moment). So far, Mogre is the top choice, but I wanted to see if I could solicit others' opinions and advice on setup, add-ons, etc.

My background is as a programmer. By career, I'm a professional game programmer, but this is a side project of my own. It's ambitious, but that's ok - if I get something good accomplished, great, if not, well, I'll learn some new things and enjoy the time I spend working on it. I'm explaining this so that I don't get a lot of troll-bait about how I shouldn't be embarking on a big project or that I have no clue what it takes to make a game. I do and I'm still undaunted. 'nuff said.

Anyway, the game I'm aiming for is somewhat of a cross between Might & Magic and Oblivion. For those who are interested, I have some of the game design finished and will have a website and wiki up soon so I can post a link with more details soon. I have almost no artistic skills, so whatever the visual look will be beyond the UI, etc will all be up to artists. My desire is to have a good enough base rendering engine that I can set some artists loose and have confidence that they can build something decent without me having to spend any more time than necessary on creating tools for them. My main concern and enjoyment out of this will be in designing the game mechanics, the UI and the AI - not tools/pipeline, rendering, physics, animation, etc. I've done enough of those in my normal job that I know what a time-sink they are and want to avoid that if possible.

MOgre is attractive mainly because I'm sick to death of C++ and want to do more with C#, even though this may end up complicating things in the setup and possibly down the road for debugging, etc. I'm also very interested in using WPF with MOgre (as done at http://www.codeproject.com/KB/WPF/OgreInTheWpf.aspx) since all the GUI systems I've seen are much harder to use and very limited in functionality compared to WPF. Unfortunately, the author of that project seems to have dropped off the face of the earth so I suspect I'll have to do some work to update Mogre 1.72 to work with WPF, much as he did with MOgre 1.4.

I'm planning on this being a windows-only project - I don't even mind if it's only for Vista+ or DX10+ if that's necessary. MOgre (and Ogre in general seems to only support up to DX9 (if I'm reading things correctly)), so DX version shouldn't be a big issue and shader model 3.0 cards are common enough these days. I'm using Visual Studio 2008 (mainly because I already own a pro license and don't see enough benefit in paying for the upgrade to VS 2010).

Requirements
  1. Pre-built rendering engine, tools, physics, animation systems or add-ons that can be set up to allow artists to use their standard tools and create artwork for the game with little or no attention on my part.[/*]
  2. Allow coding of AI and most game-loop code in C#. I don't really care if renderer, etc are in C++ since I don't plan on working with them more than necessary :) However, I haven't really found a good way to tightly integrate a C++ engine with C# game-loop code without a lot of custom programming, so I figure it's easier just to use a "fully" C# engine[/*]
  3. Able to page terrain blocks in the background, much as Oblivion (i.e. no loading screens unless you teleport to completely different place in the world)[/*]
  4. Able to integrate renderer viewport into a WPF form and use WPF as the in-game HUD/UI, etc.[/*]
    [/list:u]

    In doing my research, however, the choices that I have are limited because of my desire to work in C#. My other choices seem to be:
    1. Unity
      1. Unity costs $1200 if you want the un-gimped engine, which is a pretty big expense for a hobby project and a large deterrent to recruiting others to help on the project, so I suspect Unity is not a viable choice despite the fact that it has a good pipeline.[/*]
      2. Unity also has a somewhat strange dev environment where you attach "scripts" to visual objects. While this works, it also makes me shudder to think what a large-scale project will look like over time and how disorganized it would become.[/*]
        [/list:u][/*:m]
      3. Visual 3d.Net.
        1. Visual 3d.Net, while less costly than Unity, is still not free, thus again is a barrier to recruitment[/*]
        2. I was initially excited about using this, despite the cost, however, as I kept waiting and waiting for their promised next version, I began to realize that the engine seems to be in trouble and I cannot rely on them to come out with features that I need in any kind of reasonable time frame. Disappointingly, I've mostly given up on this engine - which is too bad considering how much potential it has.[/*]
          [/list:u][/*:m]
        3. Torque X
          1. cost is not free, but low enough that I think it's reasonable for a hobby project[/*]
          2. Theoretically has everything I need/want... however, based on reading it seems the current version is virtually unsupported and buggy as hell. It's also a nightmare to work with based on my trial with it. The devs are supposedly re-vamping Torque X, but with the plans I've read, I don't expect real results for another 1-2 years at least.[/*]
            [/list:u][/*:m][/list:u]

            Therefore, based on my requirements and my other choices, I'm reasonably sure that MOgre is my best choice for all this. I'm not sure about how difficult it will be to set up, however. I've downloaded the MOgre 1.72 beta and mstoyke's terrain-paging work, but haven't set it up or tried to sink my teeth into a sample project yet. I'm currently planning on starting that today and this weekend. We'll see how good I feel about MOgre after that :)

            Anyway, I'd appreciate any thoughts from more experienced MOgre users and/or suggestions of what I'll need to get or set up, or even ideas on other engines that fit my requirements better.

            Thanks!

AndroidAdam

27-08-2010 22:20:33

Something to note is that Mogre/Ogre is just a rendering engine. What this means is you need to add your own GUI, physics, input, etc... This (IMO) is more a feature, because it allows you to customize things to your needs, essentially you get to build your own game engine. However, OGRE does have a particle engine which should be up your ally for a magic based game,.

OpenGL is just as well supported as DirectX, but because of the nature of Mogre, it can only be ran Windows, so you might as well use DX.

I was also very excited for Visual3d.net, but began to have the same doubts as you had. Looking at the devs history (They were supporters of the Axiom project, abandoned that and began to work on an engine called RealmForge, abandoned that and began work on V3D.net), I wouldn't hold my breath.

Axiom is a C# port of OGRE, but the only real benefit is it's cross-platform. (Actually another benefit is that it's pure managed code, making for easier debugging)

I'm curious if you've heard of XNA, and just decided against it? While I'd prefer Mogre over XNA, I'd check it out if I were you

My two cents? Mogre's a solid engine, and I'm sure you'd be able to customize it to your needs.

mstoyke

27-08-2010 23:11:10

Hi elfric, welcome to our forums.

MOgre is attractive mainly because I'm sick to death of C++ and want to do more with C#, even though this may end up complicating things in the setup and possibly down the road for debugging, etc. I'm also very interested in using WPF with MOgre (as done at http://www.codeproject.com/KB/WPF/OgreInTheWpf.aspx) since all the GUI systems I've seen are much harder to use and very limited in functionality compared to WPF. Unfortunately, the author of that project seems to have dropped off the face of the earth so I suspect I'll have to do some work to update Mogre 1.72 to work with WPF, much as he did with MOgre 1.4.
I use WPF a lot for applications and some of the concepts in the framework are really nice. But, at least for me, it is not a good solution for a Mogre based game. I created some tools with Mogre that help me to quickly get a scene set up, but I use Winforms because for tools usability is more important than looks. And WPF is (again my opinion) primarily for looks, because it has all these nice features to quickly add some cool effects to a GUI.

For an in-game GUI system I can recommend MYGUI, which I used a lot without any problems, and I heard that miyagi is also a very good solution for Mogre based games. WPF might be a good solution when you look at it, but I think that it can easily cause you some trouble when you do not completely understand the concepts behind it. And everybody who ever used WPF on a professional level can confirm that it's not something to pick up in just a few days.

I, being a professional game developer myself, understand very well the requirements that a full blown game project has. And let's be frank about it, there is no such thing like a small game. Even for small scale projects I always easily filled multiple pages of bullet points when I outlined what needs to be done before the project can be called finished. So a developer needs a lot of control about the modules and libraries he uses in the project. WPF just has a lot of concepts that are great for application development, but whenever I tried to think about a WPF based framework for games, I just ended up with the conclusion it's not worth the effort.

I'm not saying you should not try to use it, but I will not be surprised to hear from you in the future that you decided to replace it with something else. If, on the other hand, you can successfully integrate it in your game and it works well, I'm sure that everybody here (including me) would really like to hear from you how you did it and what your experiences were.

I'm planning on this being a windows-only project - I don't even mind if it's only for Vista+ or DX10+ if that's necessary. MOgre (and Ogre in general seems to only support up to DX9 (if I'm reading things correctly)), so DX version shouldn't be a big issue and shader model 3.0 cards are common enough these days. I'm using Visual Studio 2008 (mainly because I already own a pro license and don't see enough benefit in paying for the upgrade to VS 2010).
There are actually renderers for Ogre that make use of DX10/DX11, but I never used them because DX9 got all I need and is more compatible with older Windows versions. I also never saw a really good example of features in a game or demo that were absolutely necessary for the game and could only be achieved by using DX10 or higher.

VS2008 is still a very common development platform and I will support both, VS2008 and VS2010, for quite some time in the future for Mogre. After using both IDE's for some time now I came to the conclusion that VS2010 is great (and the only option) for .NET4. But for everything that does not require .NET4 I still prefer to use VS2008, at least until a service pack for VS2010 deals with the most annoying issues that I ran into.

Therefore, based on my requirements and my other choices, I'm reasonably sure that MOgre is my best choice for all this. I'm not sure about how difficult it will be to set up, however. I've downloaded the MOgre 1.72 beta and mstoyke's terrain-paging work, but haven't set it up or tried to sink my teeth into a sample project yet. I'm currently planning on starting that today and this weekend. We'll see how good I feel about MOgre after that :)
It is actually not difficult to get something up and running in a short time. Knowing Ogre before using Mogre will sure help to set it up properly quicker, but you're also fine just starting with Mogre directly. If you look around in the forums I released a lot of information and projects in the past that can help you to get started quickly (look at the sticky topics), and I will soon add more modules to the quick start project that will integrate external modules like GUI, sound, physics, etc.

Just keep in mind that I usually do new development on Mogre for VS2010/.NET4 first and will then provide solutions for VS2008 later, after the module reaches beta status. So if you want to use new modules, like the terrain and paging components, you will have to create your own solution & project files for VS2008 and compile these modules yourself until I provide these files in the future.

Anyway, I'd appreciate any thoughts from more experienced MOgre users and/or suggestions of what I'll need to get or set up, or even ideas on other engines that fit my requirements better.

All I can say is that I would use a Mogre based technology, even for a commercial project, if it fits my needs and prefer that to any of the other engines you mentioned, simply because I got a lot more experience with Mogre than with the other engines. It's a very rewarding experience (most of the time) if you prefer to have a lot of control and don't need all these great tools that e.g. Unity provides.

There are a lot of tools out there for Ogre and I never had any problems to use them with a Mogre based engine, simply because Mogre is just a wrapper and the underlying technology is still Ogre. But if you prefer to have less work coding all the necessary code to combine all modules into one engine, one of the other engines might be a better choice.

It's kind of hard to give good advice here, because I don't know your goals well enough. If you want to finish a game quickly without much hassle, then expect Mogre to give you a lot of headaches sometimes. But if you want to learn something new and have control about every internal aspect of the game, like most game developers prefer, then this might be exactly what you're looking for.

mstoyke

27-08-2010 23:15:23

I'm curious if you've heard of XNA, and just decided against it? While I'd prefer Mogre over XNA, I'd check it out if I were you
XNA is just an API, like DirectX, it's not an engine like Ogre. So, while it's still great technology, it's not suited for people that do not write their own engine on top of it.

elfric

28-08-2010 01:51:05

I'm curious if you've heard of XNA, and just decided against it? While I'd prefer Mogre over XNA, I'd check it out if I were you
XNA is just an API, like DirectX, it's not an engine like Ogre. So, while it's still great technology, it's not suited for people that do not write their own engine on top of it.


What he said :) Yes, I've heard of XNA, of course, and I strongly considered using it. However, it's really just an API and there's not a huge amount of benefit to using it since I'd still have to write the engine code to use the XNA API. Knowing that, it just seems like an easier path to use an existing engine. Theoretically, I can still use XNA in addition to the engine code (though I also remember reading that MOgre is not compatible with XNA, so maybe that's not true in all cases), but given that the engine should be able to do (in an ideal world) everything I'd get from XNA anyway, it just seems redundant.

mstoyke

28-08-2010 02:26:50

though I also remember reading that MOgre is not compatible with XNA, so maybe that's not true in all cases
Mogre will work fine with XNA. You can't use the XNA graphics library for rendering, because XNA is a managed API and the renderer for Ogre is a native C++ module, but using XNA for input or sound is not a problem at all.

In fact I used XNA input for quite some time, so that my application could make use of a XBox controller. I have only abandoned XNA for my Mogre based project, because it's an additional dependency and with SlimDX you can also access XBox controllers. DirectX is already a dependency for Ogre, so SlimDX will work without adding more dependencies to the installer.

As far as I know (and I might be wrong about XNA here), you need to install the XNA runtime to make use of it, but for SlimDX it will also work if you only have a copy of the DLL in your application directory. You can install SlimDX to the GAC, but it will also work if you just put it in the game directory directly.

elfric

28-08-2010 03:14:53

Hi elfric, welcome to our forums.

Thanks!


I use WPF a lot for applications and some of the concepts in the framework are really nice. But, at least for me, it is not a good solution for a Mogre based game. I created some tools with Mogre that help me to quickly get a scene set up, but I use Winforms because for tools usability is more important than looks. And WPF is (again my opinion) primarily for looks, because it has all these nice features to quickly add some cool effects to a GUI.

For an in-game GUI system I can recommend MYGUI, which I used a lot without any problems, and I heard that miyagi is also a very good solution for Mogre based games. WPF might be a good solution when you look at it, but I think that it can easily cause you some trouble when you do not completely understand the concepts behind it. And everybody who ever used WPF on a professional level can confirm that it's not something to pick up in just a few days.

I, being a professional game developer myself, understand very well the requirements that a full blown game project has. And let's be frank about it, there is no such thing like a small game. Even for small scale projects I always easily filled multiple pages of bullet points when I outlined what needs to be done before the project can be called finished. So a developer needs a lot of control about the modules and libraries he uses in the project. WPF just has a lot of concepts that are great for application development, but whenever I tried to think about a WPF based framework for games, I just ended up with the conclusion it's not worth the effort.

I'm not saying you should not try to use it, but I will not be surprised to hear from you in the future that you decided to replace it with something else. If, on the other hand, you can successfully integrate it in your game and it works well, I'm sure that everybody here (including me) would really like to hear from you how you did it and what your experiences were.


Well...yes and no. WPF is an interesting system which I'm also familiar with (though I will admit, the learning curve was not easy and it took me several solid weeks of effort to get in-depth proficiency with WPF). It's basically the next evolution of winforms combined with DHTML and, though skeptical at first, I am now a total convert. For ease of use, power, and pure deep functionality, I've never seen anything as good as WPF. The looks are nice, but honestly, the main reason I like WPF is the functionality. Since my RPG will have lots of charts, tree controls, tabbed panels, and in general a fairly complex UI, I feel like WPF is the path of least resistance. I don't know (and don't feel like learning) Flash and I haven't seen any GUI for Ogre/Mogre that has all the widgets or flexibility in combining them that I need.

As an example, one of the character tabs has a skills chart that is basically a tree-grid with each row having a bunch of widgets (labels, dropdowns, buttons, image-flags, etc). In addition, each row is automatically associated with a different object (skill) and thus needs to update different info, calculate changes (to itself, the skill's dependencies, etc). It's basically a fairly complicated spreadsheet with lots of linked cells, formulas, widgets, etc. as well as collapsible rows so that sets of skills can be ignored or not shown.

Yes, I could do all this with most GUI systems, but I strongly suspect I'd have to do a lot of customized programming and shoehorning of basic widgets into a complex tree-grid class, add my own trigger system for cascaded calculations, etc. In fact, I know I would have to since I've done it before! With WPF it was actually pretty easy and took very little coding. Most of the setup is just in the xaml files, which are easy and (to me, anyway, having worked for many years with HTML/DHTML) intuitive to edit. I didn't even really have to do much with getting the dependency calculations to cascade properly - WPF gave me some easy ways to just make it work without much hassle. I don't know of any other GUI that would allow me to get as much done as easily or in anywhere near as little time as WPF. As an added bonus, WPF looks nice, and doing an actual in-game HUD, compared to the complexity of the above UI, is a breeze.

It is actually not difficult to get something up and running in a short time. Knowing Ogre before using Mogre will sure help to set it up properly quicker, but you're also fine just starting with Mogre directly. If you look around in the forums I released a lot of information and projects in the past that can help you to get started quickly (look at the sticky topics), and I will soon add more modules to the quick start project that will integrate external modules like GUI, sound, physics, etc.

Just keep in mind that I usually do new development on Mogre for VS2010/.NET4 first and will then provide solutions for VS2008 later, after the module reaches beta status. So if you want to use new modules, like the terrain and paging components, you will have to create your own solution & project files for VS2008 and compile these modules yourself until I provide these files in the future.


Yes, I've found your forum posts to be quite valuable and I greatly appreciate (and applaud) your efforts. Unfortunately, my first attempt at even getting the base Mogre SDK to run is a failure (keeps failing right at startup saying that Mogre 1.7.1 dll cannot be found (or some-such - I didn't save the error (which you'd think I'd KNOW better by now...*sigh*)). Anyway, I'm sure I'll figure it out soon enough - but yes, I can already see the benefits of getting a mercurial client, grabbing stuff directly from the source repository and compiling it all myself :)

Honestly, I'd rather not have to pay for the 2010 upgrade, so I will likely have to deal with re-creating the projects in 2008. Not ideal, but not the first time by a long-shot that I've had to do similar things.

All I can say is that I would use a Mogre based technology, even for a commercial project, if it fits my needs and prefer that to any of the other engines you mentioned, simply because I got a lot more experience with Mogre than with the other engines. It's a very rewarding experience (most of the time) if you prefer to have a lot of control and don't need all these great tools that e.g. Unity provides.

There are a lot of tools out there for Ogre and I never had any problems to use them with a Mogre based engine, simply because Mogre is just a wrapper and the underlying technology is still Ogre. But if you prefer to have less work coding all the necessary code to combine all modules into one engine, one of the other engines might be a better choice.


Well, the thing is, I DO want all those great tools that Unity provides...I think. What I want is an engine that is mostly complete and will allow me to concentrate on the parts of the game code that are "interesting" (to me, anyway - i.e. AI, UI, gameplay) rather than the basics like rendering, animation, pipeline tools, build tools, physics, etc. To be honest, that's the area where I see Mogre being the weakest choice. I know Ogre is "just" a renderer, but it also has all kinds of add-ons that I can use to fill in most of the gaps. What I see it lacking is in the meat and potatoes of game development - i.e. tools. Doing pretty graphics are nice, but if your artists have to spend 2 days to get a simple mesh into your game, you're doomed from the get-go. Even more than programmers, artists need tools to allow rapid iteration and easy integration of assets into the game. Unity shines here. Torque X could shine here, but currently doesn't because of some bad design decisions (imho). Ogre/Mogre, I think, is probably weak here. I also freely admit, though, that I haven't done enough research on this to know that for sure, so I'm definitely interested in hearing more from anyone who has tried to do a "real" game project with Mogre and what they did for tools support.


It's kind of hard to give good advice here, because I don't know your goals well enough. If you want to finish a game quickly without much hassle, then expect Mogre to give you a lot of headaches sometimes. But if you want to learn something new and have control about every internal aspect of the game, like most game developers prefer, then this might be exactly what you're looking for.


As a game programmer, I of course want full control over every part of the engine. I've been burned too many times by NOT having that. However, I also realize that it's just me (so far) on this project and hobby projects are different than the AAA titles I'm used to shipping (with dozens of people on the development teams), so I need to do some adjustment of my mind-set. In the end, what I really want for THIS project is an engine that can be a vehicle for rapid prototyping of an RPG game. The game itself will play somewhat like Oblivion, but will have more complex mechanics and allow a multiple-person party ala Might & Magic. (that last requirement is, by the way, the main reason why I don't just make an Oblivion mod using the Oblivion tools). Ultimately, if the project ever gets "serious", I'll want something that can do a game that looks much like Oblivion in presentation quality. In the meantime, I'll be quite happy with something that looks like a early 2000's FPS that I can grab free art assets and throw them in a cauldron while I concentrate on the actual guts of the game itself.

In other words, while this is still a hobby project, I'm content with today's equivalent of "programmer art". I just want an engine that won't bite me in the ass and force me to revamp EVERYTHING just in case the project does ever become "serious". It's the classic programmer problem where you know you can do something simple in a short time, but have to balance that against possible future needs as well so the quick "hack" isn't likely the best solution. On the other hand, paying $1200+ up front for an over-powered engine that may or may not be useful in the long run or creating an engine from the ground up seems rather overkill and just as inefficient in the long run (if not more so!)

My goals are therefore....murky. :) Mainly I want to have fun and work on a prototype for a game that might actually become something decent...someday...assuming that moon aligns with the third star to the left and I can convince high muckymucks at my company that it's worth investing in the idea based on the prototype. However, the chances of the latter are slim, so mainly, I just want to have fun and experiment with some ideas without spending all my time on the parts of the game that I know for a fact are reasonably well-known and "solved" problems (i.e. rendering, animation, physics, etc). The bulk of my time I'd like to spend working on the things that would make this game unique and different, not the things that are requirements just to keep up with the rest of the games on the market.

GantZ

28-08-2010 11:36:44

welcome elfric, interesting plan you have there, good to see i'm not the only one working on a rpg game :).

as myself, i use mogre along with shipped-in library, like mogrenewt for physics / collision detection, MOIS for input, etc. I use this for 3 year now and have been able to get some decent result without too much trouble. granted, what i do is not as complex as what you plan to do ;)

For tools, i advice you to check out existing game editor built around Mogre/ogre, like these ones :

  1. glue game editor : http://www.ogre3d.org/forums/viewtopic. ... 8&start=75 Made using csharp, it's still in early stage, but it grow quite quickly[/*:m]
  2. Ogitor : http://www.ogitor.org/tiki-index.php , in development for quite some time now. I haven't check out the last version, but last time i try it, i was able to write a scene exporter for my game quite easily, you can add your own plugin without too much difficulties. again, it's open source, and it got a fairly active community. the downside is you have to write your exporter in c++[/*:m][/list:u]

    anyway, good luck with your project.

Meharin

03-09-2010 20:49:48

Hi elfric!

I'm glad there's someone else here who is sold on WPF! I have been dabbling in hobby game development for a while (10 years or so) and am actually at the point of quitting my job in a few weeks to try to launch something. I don't know if the stars will align for me, but I've decided to take a dedicated shot at following my passion :). I am planning to start with a space team action game, with a growth path into adding strategic (RTS) elements. So it needs to be responsive, although I may have much less artistic / artist requirements than you. I also plan to have non-action planning/designing/modding phases, where I could probably use WPF more heavily.

I want to be free to add sophisticated GUIs without having it hanging over my head there is a huge barrier to doing anything non-trivial. Ogre's in-game GUI libraries (and Unity, etc) seem to be getting better and I respect them, but my imagination is for more complex GUIs and I do not have time or inclination to create/augment GUI libraries. I've never tried in-game Flash, but I want to avoid it like the plague after hearing others comments on it. My day job has never been game development, but it has involved a decent amount of WPF. I'm by no means an expert, but I'm fluent in the bits I know and it is definitely my GUI lib of choice. It is a breath of fresh air, despite its sometimes steep learning curve. I used to hate MS 10 years ago, and still have issues with them, but I think C#/.NET and WPF are two of the most brilliant inventions for programmers (and Visual Studio too I guess).

If you've followed all the threads in OgreInTheWpf, I'm guessing you found my benchmarks (my nick in Ogre forums is Mawen), and what I had to do to get it working fast on Vista/Win7 (upgrade Ogre to Direct3D 9Ex, which turned out to be minor changes to a few lines of code, easy for me who has never done D3D programming.) http://www.ogre3d.org/forums/viewtopic.php?f=11&t=44263. I still think it may be possible to get it just as fast on WinXP, and I may need to look into that and try to get it working if a lot of gamers are still using WinXP by my expected release date. Looking over my post, it looks like there's some fairly significant changes to how Ogre works with D3D textures, and I'm not entirely sure it wouldn't break other things, so I'm a little bit scared to take a shot at it.


I still have to re-research the latest of all the engines, though here are some of my outstanding thoughts / concerns:

Control vs Game Engine

I keep vascillating between having everything put together for me vs having full control. Now that I'm planning to do this full time and have some time, I am leaning towards having full control (although now that my income is on the line, I know I need to ship and make money ASAP.) I was tempted by Visual3D for a while, but never tried developing with it, and I think they delayed XBox support. (My enthusiasm for Xbox Live has gone down a little once I saw an article of one of the best selling developers was underwhelmed by the money they were making.) I was using NeoAxis for a while, which was great for getting me up and running (the author is amazing in cranking out a nice practical package with good demos IMO, one of my code heros), but I wanted more control over game entities, and wanted to be free to port all my logic without ripping out a bunch of game engine classes or being tied to their license/IP.

I don't know details about Unity, but if it is some strange way of programming like attaching scripts to objects and would make it hard to port to another engine, that scares me (although Unity looks very well done, so I imagine the tradeoffs would be worth it for most people). Also, Unity can support several platforms, and that's something to keep in mind even though my game probably doesn't make sense on other platforms at the moment. I could probably spend $1200 if it helped, but from my impressions (and I hope a non-irrational desire for control), I wonder if I might pay $1200 (if I had to) to use MOgre (especially if WPF turned out to be a big plus for me). I have used Infragistics NetAdvantage WinForms/WPF at work, and if I need a lot of WPF that happens to be already done by a WPF component library (IG, Telerik, etc.) I may consider forking over $$$ for it. A good datagrid and a charting library for game stats may be nice, but WPF has a bunch of free stuff for this kind of thing which is even better. Unity also supports C#, so I may look at porting my game to Unity later if my needs fundamentally change.

Tools
I am not really sure about tools. At this point, I'm also happy with my own programmer art, I may be the only "artist" for v1, and an abstract techno-space looking game, and may be able to get by with whatever tools Ogre/MOgre has to offer. My space game may involve planetary action at some point, and I may take advantage of the community's innovative free/cheap Ogre plugins for huge landscapes, for planets, clouds, trees, water, etc., and as far as I can tell, some of those may be strengths of Ogre (I have my eye on seamlessly flying into a planet http://www.ogre3d.org/forums/viewtopic.php?f=11&t=49849). If I can't afford much from an artist, it may be a cheap way to give a bit of graphical credibility to the game, although it looks like Unity has tools for landscapes as well, and maybe there are good plugins you can get (buy) for it if you buy the pro version.

WPF and performance - an unknown?
I did some benchmarks of WPF with Ogre, and as a sanity check, it passed (in D3D 9Ex, no expensive software blitting, at least!), but there are still unknowns until someone proves what the limitations and practical uses in a game are . With WPF, I'm a little concerned that once you add too many elements to a screen, it may slow things down, as I'm not sure how efficient WPF is with its deep visual/logic trees. If this happens, I may have to 1) learn how to profile & simplify my WPF (thankfully there are lots of great tools and docs for this), and 2) port certain GUI aspects to MYGUI or one of the others. My other concern is that mixing WPF with a 3D engine hurts performance significantly due to context switching in the GPU (I know almost nothing about GPU/ low-level 3D programming), requiring that 3D graphics intensity be less than what it could be without WPF (which I may be willing to live with, as I'm not aiming for a AAA graphically intense game.) Hopefully, these aren't showstopper issues though! (As an aside, one thing I have run into at work is some people have thought WPF is more computationally intensive than WinForms, but my gut impression is that unless you're doing lots of effects, it seems the opposite is true due to the graphical acceleration of WPF and the inefficiencies of GDI+.)


My status:

I have MOgre working with WPF in .NET 4, with a little framework to switch between full screen WPF windows, or windowed. Let me know if you or anyone wants my code.

You said the OgreInWpf author dropped off the earth? It looks like he posted as recently as Aug 27 on his codeproject article: http://www.codeproject.com/KB/WPF/OgreInTheWpf.aspx

I have VS2008 Pro, but I'm using .NET 4 and VS 2010 Express (crippleware pain points for me: no AnkhSvn (or possibility of other plugins), no solution folders, no attach to process debugging, have to switch between C# Express and WebDev Express to use silverlight - so far I can work around these ok, though I am in a forgiving mood due to it being free and having better multimonitor support -- I know this would drive others up the wall), although I plan to try to take advantage of the rather amazing BizSpark program which gives you a real version of VS2010 among other things (Expression) for $100 that you don't pay for 3 years, if you are trying to launch a startup: http://www.microsoftstartupzone.com/BizSpark/Pages/Do_I_Qualify.aspx

mstoyke

04-09-2010 02:12:13

Hello Meharin,

welcome to Mogre, it's always nice to see more people joining us here :)

It's a bold move to quit your job and start something yourself. I've been through this some years ago and it's very satisfying if you actually manage to ship and sell a finished product.

The reason why I would not use WPF for a game myself it that, in most cases, you don't need the complexity that WPF provides for a game GUI. But if it works for you (or for elfric), I think it's OK to use it. I'm very interested in your experiences when you actually try to implement a GUI with WPF for your game, maybe I'm completely wrong in not trusting WPF to be a good solution for Mogre based games...

To explain this in a little more detail, let me tell you how I would decide if I wanted to use it or not.

First I would design (on paper!) my GUI and all layout to get a feeling for my requirements. If the GUI mostly consist of buttons, labels and some few fields to enter text, I would go for something that it lightweight. In most games I developed there were only a few widget types that I really needed, so for a list like "buttons, labels, windows, listboxes, textboxes and images" a library like MyGUI would be a good candidate.

But let's assume that I need much more and WPF would be my preferred choice, the next step would be a small prototype that would render a simple 3D scene in the background and uses WPF to draw a GUI on top of that. My next goal would be to determine the performance impact of WPF, because I really like to be able to maintain a constant framerate in the game. It will just "feel" better because it will make it easier to have smooth animations in the game (I discussed this in detail in another thread in this forum).

OK, now let's say this also went well, the performance is satisfying and there were no major technical problems implementing a WPF GUI that works well with Mogre. Now the next important thing is event handling in the game. In my experience you always need to be able to route events like keypresses and mouse input to many different modules in your game. And you absolute need to make sure that events are only consumed by the right objects.

What I mean by this is, nothing is worse than clicking through the GUI and and affecting other objects that are hidden under a window. I had this ugly bug some time ago in a project where I was not able to detect this easily, so it was a pain in the a** to add all this event handling stuff that I needed to a GUI system that did not provide this feature and was written by somebody else who was not available anymore.

Once this is settled, there would be one last thing that I would test before making my final decision. Resource management. There needs to be an easy way to use game assets with the GUI system without too much pain. In many cases you use assets in different places and don't want to duplicate them for different systems. For example, let's assume you have some icons that are used by game objects and the GUI. You usually want this to "just work", so if you load a resource, like an icon, with the resource manager and can't just assign it to a GUI widget, like let's say a static image, without either converting it to another format on the fly or loading a second instance of the icon with the GUI system, it's also a drawback that can make thing more complicated than they need to be.

I just remember a good example in another project, a prototype that I was working on, where we were using Mogre and I also hooked some of my own code into the render loop that enables me to do some custom rendering on the D3D device. The idea was to do 2D rendering with our own graphics library and use Mogre for the 3D stuff. This worked pretty well, but when we needed to use the same assets that my 2D library uses with the Mogre 3D objects the trouble started. Suddenly I had to write a lot of code to manage all these assets in a way that both libraries could use them at the same time, I would have had much less trouble by just using the billboard system or the overlay system in the first place and stay away from using my own 2D library.

I hope I could help you with this information. And please keep us updated on your experiences, if WPF is really a valid option for Mogre projects I will certainly add support for it to the project in a way that enables easy and integration, either with a module for my quick start project or a distinct library.

Meharin

05-09-2010 04:21:41

Hi mstoyke! Thanks for your thoughts!

  1. Is WPF complexity needed? - At this point I have enough ideas for complex UI that I'd like to try it if it is within reach. [/*:m]
  2. Simple prototype - I haven't integrated my game engine yet, although I created a benchmark with lots of 3D objects and lots of WPF objects. Both WPF transparency and Ogre transparency seem to work, and I can put WPF under and over the Ogre. It seemed WPF was capping my framerate at 97fps, preventing me from getting an idea exactly how much the impact was. More tests would be good, and I should see if I can get rid of WPF's fps limit for testing. (It's too bad it looks like my screenshots are no longer working: http://www.ogre3d.org/forums/viewtopic.php?f=11&t=44263)[/*:m]
  3. Input - Yeah, this is a very important thing to solve. I haven't started on this yet. WPF has a lot of infrastructure for routing input events, but I won't rest easy until I have a prototypical example working.[/*:m]
  4. Resources - Good point on the duplication issue. I hadn't thought about that. I don't think I will use many resources in both, but I guess time will tell.[/*:m][/list:u]

    Thanks again for your input. I will keep this forum updated with any progress.

Beauty

05-09-2010 15:03:47

Welcome to our Mogre community :D
Sorry for my late answer - I was on holiday.

My background is as a programmer. By career, I'm a professional game programmer ...
Interesting to know - if you like, you could add this information to your wiki profile. So it doesn't get lost in an aging forum thread :lol:

I'm also very interested in using WPF with MOgre
This is interesting. A team mate had problems with an application GUI because Windows.Forms has a bad transparancy support. So he switched to WPF and the result was looking fine.
Also I was on a Microsoft presentation, which was about Silverlight and WPF. The graphical things were awesome, especially the rendering speed.
I never used WPF until today, but I'm interested to read about your experiences with WPF and Mogre. So feel free to publish useful information, e.g. here in the forum or in the wiki. (to log-in to the wiki, use the username/password of the forum)

Just as a notice - our current Mogre version is Mogre 1.7.2, not Mogre 1.72 :wink:


Ogre in general seems to only support up to DX9 (if I'm reading things correctly)
An update to DirectX 10 (or even DX 11) is in process since many months. It needs some time, but I'm shure in the future it will be supported. (I don't know the state of development in detail.) Just to let you know.

Pre-built rendering engine, tools, physics, animation systems or add-ons that can be set up to allow artists to use their standard tools and create artwork for the game with little or no attention on my part.
Most tools and some add-ons are usable with Mogre, some other tools unfortunately not. The main reason is, that for each add-on or C++ library we need a wrapper or port.
Although you can't use all add-ons of C++ Ogre, you have a good base for creating your game(s).
For model creation you can use common modelation tools. By the Ogre exporters you can convert them to the Ogre file format. As I know the exporters of Blender and 3D Max works very well and support the export of many features. For other exporters I don't know. So this shouldn't be a problem.
For whole scenes it's more complicated (as far as I know). There is no common scene format for Ogre, maybe because of different user needs. Most common is the DotScene format, although there are little format/loader differences. Some exporters also can create DotScene files (for 3D Max and I think Blender, too). But I think the most users use their own proprietary scene file format.

Currently there are comming up some new interesting tools for content creation.
Here are some of them:
* wxOgreMeshViewer - display models
* OgreModelConfigurator - display models and allow some modifications
* Ogitor - editor for scenes with terrain (I suppose to use it with Mogre this needs support of the new terrain scene system. A Mogre update for this is in development. Maybe Ogitor also support the export of an alternative terrain format.)
* Glue Editor - for indoor scenes (developed in C# - if you like to take part in development :wink: )
* EGO game editor - for outdoor scenes, with support of some add-ons (e.g. Hydrax for water, Caelum for sky)

I linked to the wiki pages. Some of them currently has no content (I will fill it up later), but at least each page has a link to the related forum thread.


Allow coding of AI and most game-loop code in C#. I don't really care if renderer, etc are in C++ since I don't plan on working with them more than necessary :) However, I haven't really found a good way to tightly integrate a C++ engine with C# game-loop code without a lot of custom programming, so I figure it's easier just to use a "fully" C# engine
What do you think about Lua for AI scripts? I think this is very common. But I have no idea if or how to use it with Mogre. If somebody knows, be welcome to talk about.
Related to the render loop - here is a discussion thread: Gameloop etc questions

Able to page terrain blocks in the background, much as Oblivion (i.e. no loading screens unless you teleport to completely different place in the world)
Paging is supported by the new terrain system. But as I know there are also other terrain managers, which support paging and works with Mogre. For example Myrddin Landscape Plugin, Paging Scene Manager / PSM2 (I don't know if it's usable with Mogre), ...
Here in the wiki is a list of scene managers. I suppose there are more, but most people are too lazy to update or add content to the wiki. At least the list is a good starting point for search. Also search in the Showcase section of the main forum.
http://www.ogre3d.org/tikiwiki/tiki-ind ... anagersFAQ

use WPF as the in-game HUD/UI
Sounds interesting.
Here are some wiki pages related to HUDs for Mogre:
http://www.ogre3d.org/tikiwiki/tiki-ind ... Billboards
http://www.ogre3d.org/tikiwiki/tiki-ind ... ovableText
http://www.ogre3d.org/tikiwiki/tiki-ind ... t+in+MOGRE

I'm not sure about how difficult it will be to set up, however.
This shouldn't be hard. You only need some depencies, which will be installed by the Mogre SDK installer.
Then for your project you just need to copy some files to your project, link to Mogre.dll and write your code 8)

Thanks for the overview of engine alternatives and its pros/cons.
What's about XNA?
It's also C# and should have a good content pipeline.
I hope you don't leave us for XNA, but I wanted to tell you also this alternative.

An other alternative:
Our Mogre user boyamer develop a whole game engine, called Alimer Game Engine. He has a good knowledge and did much work (for Mogre and his engine). His game engine is looking very professional. It's not a tiny hobby project. Apart from programming, he has some other people for writing documentation, tutorials, etc. He has 2 variants of his game engine. One similar to Mogre (a p/invoke wrapper). The other variant is a combination of Axiom (an older Ogre port) with an other C# engine to support also the Xbox. Additionally (for the second variant only?) you can use the whole XNA content pipeline. Have a look to it - maybe it fit to your needs. If you have questions, just ask in the discussion thread.
http://www.ogre3d.org/forums/viewtopic.php?f=11&t=57833

Something to note is that Mogre/Ogre is just a rendering engine. What this means is you need to add your own GUI, physics, input, etc.
Yes, more work, but more degrees of freedom. Don't be afraid of doing everything by hand - for GUI, physic etc. you can use add-ons.

OGRE does have a particle engine which should be up your ally for a magic based game
Ogre (Mogre) has a particle system. (What's the difference to a particle engine?)
I read that the add-on Particle Universe should be very nice. It's not for free, but 10 Euro is a good price.
Also look to this particle tools:
* ParticleFX plugin
* OGRE Particle Editor
* Particle Accelerator

I hope this helps you for your start into the Mogre world. :D

... I must stop to read/write now. Will continue later.

Beauty

05-09-2010 19:50:24

I don't know (and don't feel like learning) Flash and I haven't seen any GUI for Ogre/Mogre that has all the widgets or flexibility in combining them that I need.
I just want to tell you - there is an add-on called Hikari with which you can add Adobe Flash content to Ogre (e.g. for a GUI system, videos or for 2D animations). It's also usable in Mogre by the Hikari wrapper.

There is also an add-on for integrating a GUI by HTML/CSS. But I don't remember the name and don't know if it's available for Mogre.

Mogre will work fine with XNA. You can't use the XNA graphics library for rendering, because XNA is a managed API and the renderer for Ogre is a native C++ module
I have a crazy idea for HUDs.
There is a way to display a webcam or video stream inside of Mogre. (A demo is in the SVN of the Mogre SDK, although it's still not included to the current SDK installer. Look [url="http://code.google.com/p/mogresdk/source/browse/#svn/trunk/sdk_fs/Samples/WebcamDemo";]here).
Maybe you can render graphics (e.g. a HUD) by XNA and send it to Mogre as video stream.
This isn't usable for input interaction (clicking, writing), but could be well for display.
Yes, just an idea.

Honestly, I'd rather not have to pay for the 2010 upgrade, so I will likely have to deal with re-creating the projects in 2008. Not ideal, but not the first time by a long-shot that I've had to do similar things.
If you do so, it would be nice to publish the VS 2008 version. Maybe in a private Mercurial repository and mstoyke can grabb it from there. This would support his (awesome) maintainer work.


Doing pretty graphics are nice, but if your artists have to spend 2 days to get a simple mesh into your game, you're doomed from the get-go. Even more than programmers, artists need tools to allow rapid iteration and easy integration of assets into the game.
Right, the content pipeline is not the best. But I'm happy to see that there are growing some interesting projects.
For model and scene creation your artists can use common tools (3D Max, Blender, Cinema 4D, etc.).
The export to the Ogre .mesh format is easy. Also the display by a model viewer. One of those have a reload button. Also (at least) 2 of them can process the recources.cfg file, which defines the paths of materials, textures, etc. for Ogre/Mogre applications.
In the most easy way an artist just have to click export in the modelling tool, click reload in the viewer and he can see the result.
OK, for a whole scene the model viewers doesn't work. But for this case you could write your own viewer. A simplified clone of your project which loads and display the scene. Without GUI, AI, etc., but with your Mogre configuration, including your used add-ons. Additionally you could add some debug buttons for your artists, e.g. to use different light settings, button for scene reload, free camera movement, etc.


Welcome I say also to user Meharin.
Thanks for your information.

I have MOgre working with WPF in .NET 4, with a little framework to switch between full screen WPF windows, or windowed. Let me know if you or anyone wants my code.
It could be useful to add your code to a public repository like code.google.com or bitbucket.org or sourceforge.org, ...
So it's easy for people to get it; it will not get lost after months or years (as happened to several useful stuff which were downloadable on private websites or file hosters); and if someone do code improvements (e.g. bugfixes), it's easy to publish them on a common place (means: commit to repository)

Beauty

06-09-2010 13:46:46

First I would design (on paper!) my GUI and all layout to get a feeling for my requirements. [...]

[...]

I just remember a good example in another project, a prototype that I was working on [...]


I think this is an interesting part of information.
So I created a new HowTo page in the wiki (Prototype steps of GUI development) and copied the content to there.
Maybe this helps other people.