next »

[Garthy]

I'm writing to get as many additional opinions as I can on a matter that I am weighing up at the moment. I'm not after someone to make a decision for me, but I am really after people's thoughts, opinions, and ideas on this one. Please approach it from the perspective of what you'd do in my shoes.

Here we go:

During the development of a previous game suite I created my own 3D engine. It's nothing special really, and I mostly did it because I wasn't happy with the solutions out there at the time. It works pretty much exactly how I want, but its technical capabilities are very limited compared to other engines. I'm just one person, and to be honest, I developed it as a means to an end, rather than because I like to play with 3D graphics in any serious way. I enjoy developing the gameplay side of things much more.

My game suite didn't do so well commercially, so I've moved on to developing something else. I'm still using the engine I developed and a bunch of other resources in my new project- yay code reuse! However, something that I have come to realise is that short of me spending around 300% of my available time on it, I'm not going to come close to the technical capabilities of any of the better engines out there. I have also realised that only being able to devote a small part of my time toward it means that I'm not really enjoying that part of the work. I'd rather devote 100% (meaning no time left to develop a game) or 0%, meaning I need to use another engine.

After a look around, I decided I'd try out Ogre and Irrlicht. They both seem decent, they are free to use commercially, have a decent number of people (seemingly) using them, and having the source out there means that people do contribute fixes and features to them. Both *seem* to have friendly communities. They are both crossplatform (Linux, Windows, Mac)- important to me, and have D3D and OpenGL renderers for Windows (mine is OpenGL only). They both have feature lists that obliterate the feature list of my engine, which was the point of looking at them, really. The idea was that I'd try them out, and take the better one, and try to modify my existing code to use this engine ahead of mine. This of course wasn't an easy decision- throwing out your own code for someone elses can be hard to do.

Trying them out, though, gave me some surprises. First, I had no luck building up the source (and dependencies) for either on Windows. A shame, I thought, but not a tragedy. I'll just use the binary APIs. A few installs later, and I can run executables for each. I built the examples for Ogre, and used the pre-built ones for Irrlicht.

Now I'm running Windows under VMWare, so I can't count on much more than a software renderer being available. No matter, I thought, as some people playing such games are going to be using a software renderer, so I need to support it anyway.

I ran the samples, and all I can say is... oh my. Not in a good way.

The Ogre samples wouldn't run under Direct3D. There seems to be no fallback if you don't have a 3D-hardware-accelerated card. Selecting OpenGL was also interesting. It causes each sample to crash immediately. A search around the web suggests that for the OpenGL-side of things, that's just the way it is- it's kind-of assumed that Ogre will be crash-happy under OpenGL. What the heck? This is *expected*? So I never saw a single Ogre sample work under Windows. They looked gorgeous under Linux though.

Okay, so off to Irrlicht. The samples ran. For each you get a choice of renderer. Depending on the sample, you got different results for each. When using OpenGL, sometimes you lost textures, sometimes it crashed, sometimes it worked. The D3D samples always exited immediately. The software renderer often wouldn't render any triangles that needed clipping (what the heck? It's 2008). The second software renderer ("Burning") gave mostly good results- I can't remember my issue with that one. Unfortunately all of the apps misbehaved- the mouse pointer would flicker and vanish, and the mouse controls were insane- the slightest touch threw the viewpoint around violently. The quality was not high. Worse, the engine devs don't seem to support (or tend to use) MinGW gcc, which is what I'd like to use.

I know my particular setup is fine, because my own (OpenGL) engine runs on it without difficulties. Just slow, naturally.

As a general rule, my experience with external libraries is that the quality of the library tends to be inversely proportional to the difficulty in setting it up correctly. I feel this is the case as the more you have to fight with a library, the greater the likelihood that the developers don't care about its quality, and the less people using it (because they had to fight with it too).

So here's my dilemma. I know I should move to a better-supported and featured engine than my own, because I can't dedicate the time to keeping mine up-to-scratch. But my experiences with what appear to be two of the superior indie engines (ie. affordable) suggest that, well, whilst feature-laden they are somewhat... err... "lacking" in the quality department. I feel I have crossed the difficulty threshold for both that would cause me to consider the library. But apparently many others are able to get them to work fine?

So what do I do? Am I too picky? Should I sink more time into these engines? Or was my initial assessment incorrect, are there better engines? Do I just say "stuff anyone who needs software rendering"? Do I sink some funds into getting Visual C++? If I do, am I going to lose the use of other cross-platform libraries that I use that build find using MinGW? Do accomplished game developers even try to use MinGW gcc under Windows, or are they splashing out for Visual C++? Do I sink more time into my own engine instead- time that will eventually be wasted when other engines mature? Give up on the whole library thing, and go for a prebuilt engine, and just script games? Or get out of indie dev for a while, build up some funds, and jump back in when the situation is better?

Brain dumps welcome- any questions, don't hesitate.

[moi]

If you want to develop for windows, then you should have a machine that canrun windows for real. That would solve your problems probably.
Also: keep your previous engine's logic and try to interface it with the new engine's graphical output.Best of both worlds.

[Garthy]

If you want to develop for windows, then you should have a machine that canrun windows for real. That would solve your problems probably.

Thanks for the fast reply.

The VM solution tends to work reasonably well for me. Basically I develop under Linux and port to Windows periodically. It's much better for testing, as I can switch and clean the Windows environment via snapshots quickly. I can install a dozen pieces of software, change my mind, and restore the old config in seconds. If I lose the ability to develop and test under a VM, it's not good news for me.

One of the test environments I had hoped to use is where there is no hardware acceleration- VMware is nice for this. One would hope that modern engines could at least fall back to software gracefully. Heck, surely software-only should be one of the test configurations of any serious engine? I am left wondering if that's old thinking though. Am I stuck in the past where there wasn't ubiquitous 3D support? Perhaps I should forget about that, and say "3D required"?

Oh, and I should probably add- when making the game suite I actually moved from physical hardware back to using VMs simply for their flexibility. So it works well as a development model, just not so well with these engines apparently. :}

Having said that, I've got a PC with an ATI 3D card set aside for a Windows testing, and occasional access to a couple of others. So yes, I agree that you definitely need a physical Windows PC- with Hardware 3D. I'd just like to use VMware too, and first.

Perhaps I should set it up today and see how well the samples behave on real hardware? Maybe I need to deliberately buy a crap video card without decent 3D support and test software-only that way. That'll be hard to explain to a salesperson.

When you say it would probably solve my problems- um.. which ones and how?

Also: keep your previous engine's logic and try to interface it with the new engine's graphical output.Best of both worlds.

Yes, excellent idea. My engine is set up to have multiple back-ends, so I was going to work the engine of choice in that way, and blend in the non-3D stuff from an existing back-end. Very close to what you describe.

[Saint]

A common misconception about using established engines - in fact, a common misconception about using many kinds of 3rd party software - is that you actually can spend 0% of your time maintaining it. My point is that you'll never find a framework that is completely the way you like it so you have to sometimes expand and change the framework, and sometimes change the way you yourself work so it better fits how the framework functions. You save some time using a pre-made engine (most of the time, a lot), but you don't save all of the time so when assessing new frameworks you should take that into consideration instead of just assuming you'll be stuck with what the community shells out. So I would say go with Ogre or Irrlicht if you don't enjoy writing engines for the sake of it.

As for software 3D, I wouldn't say that is considered a requirement anymore. Seeing as the gaps between what you can do with low-end CPUs and average 3D accelerator cards is so incredibly large, any software fallback wouldn't resemble the hardware renderer to any meaningful degree if you were to use the engine to it's fullest. Again, I would suggest you do your own testing for hardware support or plug in your own software renderer (or check the community if someone else has written one already).

Finally, I don't know of anyone in commercial games using MinGW, and .net is actually very nice, but if Windows is not your main development platform I don't think it would be worth getting it. All depends on what your goals are with your projects, really.

[muku]

So what do I do? Am I too picky? Should I sink more time into these engines? Or was my initial assessment incorrect, are there better engines? Do I just say "stuff anyone who needs software rendering"?

I'd say yes. Hardware accelerated 3D has been standard in new PCs for, what?, 10 years at least? I honestly don't think that the percentage of your potential customers which don't have hardware acceleration amounts to any meaningful number. Then again, I don't know what audience you're targeting.

Do I sink some funds into getting Visual C++?

There's Visual C++ Express Edition which is free and should serve your game development needs just fine.

If I do, am I going to lose the use of other cross-platform libraries that I use that build find using MinGW?

Generally, no. If it's a cross-platform library, it should work with VC++. Depends on the library in question of course.

[Garthy]

Thanks for the input. This is something that's going to have a significant impact on what I'm working on, so the more perspectives I can get, the better.

A common misconception about using established engines - in fact, a common misconception about using many kinds of 3rd party software - is that you actually can spend 0% of your time maintaining it. My point is that you'll never find a framework that is completely the way you like it so you have to sometimes expand and change the framework, and sometimes change the way you yourself work so it better fits how the framework functions. You save some time using a pre-made engine (most of the time, a lot), but you don't save all of the time so when assessing new frameworks you should take that into consideration instead of just assuming you'll be stuck with what the community shells out.

Dead right. There's the startup time of learning a new framework, time spend tricking the framework into doing what you actually want, working around bugs in the framework, wrapping aspects of a poorly-designed API, waiting and hoping on other developers, API breakage across versions, so forth. Of course, writing the whole darn thing from scratch instead often takes a lot of time.

I've integrated a whole bunch of libraries into my existing code. Some have been absolute god-sends (SDL, freetype2), some are fine, others solved a short-term problem and were then discarded, some are agonising to use but it would take too long to develop my own, and some turned out to be so bad that I ended up throwing them out or moving to another framework.

If I tried to do everything myself, I'd probably still be stuck trying to get a window open.

So I would say go with Ogre or Irrlicht if you don't enjoy writing engines for the sake of it.

This is the logic that led me to try out other engines- despite it being *really* hard to let go of your own work. I probably let my expectations get a bit high though, meaning I was underwhelmed by what I saw. Which led to my confusion, which led me to my original post.

As for software 3D, I wouldn't say that is considered a requirement anymore. Seeing as the gaps between what you can do with low-end CPUs and average 3D accelerator cards is so incredibly large, any software fallback wouldn't resemble the hardware renderer to any meaningful degree if you were to use the engine to it's fullest. Again, I would suggest you do your own testing for hardware support or plug in your own software renderer (or check the community if someone else has written one already).

I find myself swinging between agreeing and disagreeing with you even ten minutes or so. The stuff I'm working on isn't really 3D-heavy, so the game could (likely) still be played through software rendering by turning off a lot of options. Of course, graphically it wouldn't resemble the game on a half-decent card. :} I'm thinking portable devices aren't going to have much hardware 3D for a while yet either. But then, I'm not sure what I'm working on would suit a portable. But then again, my existing games would. But then, how many PCs would have the guts to run what I'm working on and not have a cheap 3D card in them? Then again, what if a chunk of my audience generally had no need for a 3D card?

Finally, I don't know of anyone in commercial games using MinGW, and .net is actually very nice, but if Windows is not your main development platform I don't think it would be worth getting it. All depends on what your goals are with your projects, really.

I have to rule out .Net for portability reasons. But the comment about not knowing anyone in commercial games using MinGW is concerning. I'm wondering of all the people who have developed a cross-platform game using C/C++, do many (any?) use MinGW for the Windows side? Or am I wasting my time? The only person I know for sure that does this is me. I'm wondering if it is a bad idea.

[Garthy]

Thanks for the comments muku.

I'd say yes. Hardware accelerated 3D has been standard in new PCs for, what?, 10 years at least? I honestly don't think that the percentage of your potential customers which don't have hardware acceleration amounts to any meaningful number. Then again, I don't know what audience you're targeting.

(Re audience) True. Bit of a tradeoff in my already-too-long original post. If I give too much detail, nobody will want to read it- too little, and I haven't given enough information. Sorry about that. Anyway, if you imagine a line with a casual gamer on one side, and a hardcore gamer on the other. Now chop about 10-20% off each side. The remaining line is a rough guide as to my target.

Thinking about it in those terms, the number of people without dedicated or integrated 3D cards in that range has got to be quite small now. I suspect that I'm prone to thinking about things as they were x years ago. Darn. This is why I need the additional perspective. :/

Of course, some to-and-fro-ing on the issue can be found in my post immediately above.

There's Visual C++ Express Edition which is free and should serve your game development needs just fine.

Yes, and thankyou for pointing it out. I am aware of it, but have not had much of a play with it yet. Cursed download quota. I don't mind paying for one of the enhanced editions if need be (standard seems okay price wise, not so keen on pro). I'm not sure how they sit on features though. I'd heard some editions don't have optimisation, or limited debugging? I'm really only after a good compiler, a half-decent optimiser, and debugging basics. Most of the other features I'm not that interested in. But the latter two are essential.

Generally, no. If it's a cross-platform library, it should work with VC++. Depends on the library in question of course.

For a few of them I'm just using the Unix-style configure/make/make install, which works fine in MSYS/MinGW (or does once I've tweaked it). I'd have to manually translate that into project files. Some are a bit Unix-y, and are propped up by MinGW. My fear is that I won't be able to get something critical working, and then I'm really in trouble.

Thanks again for the comments.

[muku]

There's Visual C++ Express Edition which is free and should serve your game development needs just fine.

Yes, and thankyou for pointing it out. I am aware of it, but have not had much of a play with it yet. Cursed download quota. I don't mind paying for one of the enhanced editions if need be (standard seems okay price wise, not so keen on pro). I'm not sure how they sit on features though. I'd heard some editions don't have optimisation, or limited debugging? I'm really only after a good compiler, a half-decent optimiser, and debugging basics. Most of the other features I'm not that interested in. But the latter two are essential.

I can't speak about the 2008 edition, I haven't used that. But I have used the 2005 edition (I hope it's still available?) for numerical algorithms, so certainly performance was a large issue there, and the optimizer seemed to do a decent job on that. Also, the debugger is excellent, having all those fancy features like conditional breakpoints, stack traces, watch and locals windows, everything you could wish for basically. I have also heard that 2008 is limited with respect to debugging, but I don't know if and how much they crippled it.

For a few of them I'm just using the Unix-style configure/make/make install, which works fine in MSYS/MinGW (or does once I've tweaked it). I'd have to manually translate that into project files. Some are a bit Unix-y, and are propped up by MinGW. My fear is that I won't be able to get something critical working, and then I'm really in trouble.

Yeah, compiling libraries which are tailored to use the Unix build tools can be a bit of a pain. But mostly, the high-profile cross-platform libraries that might be gamebreakers for you (you mentioned SDL and freetype), well, those usually provide binaries for Windows, or at least VC++ project files. For less well supported libraries, you might have to fiddle around with project files yourself, but usually it's doable.

[Garthy]

Thanks again muku.

I can't speak about the 2008 edition, I haven't used that. But I have used the 2005 edition (I hope it's still available?) for numerical algorithms, so certainly performance was a large issue there, and the optimizer seemed to do a decent job on that. Also, the debugger is excellent, having all those fancy features like conditional breakpoints, stack traces, watch and locals windows, everything you could wish for basically. I have also heard that 2008 is limited with respect to debugging, but I don't know if and how much they crippled it.

This is very good news then. Assuming the 2005 express version can optimise and debug as I need, this version is also be one that is typically used in both Ogre and Irrlicht. Sounds like I have my first candidate.

It'll be a day or so before I can get my hands on it (download quota). But I'll be checking this out.

Thanks for sharing your experiences with this one.

Any nasty gotchas you know about with the 2005 express edition?

Yeah, compiling libraries which are tailored to use the Unix build tools can be a bit of a pain. But mostly, the high-profile cross-platform libraries that might be gamebreakers for you (you mentioned SDL and freetype), well, those usually provide binaries for Windows, or at least VC++ project files. For less well supported libraries, you might have to fiddle around with project files yourself, but usually it's doable.

It's sometimes a fight to get things compiled on MSYS/MinGW, I imagine if I have troubles with VC++8, it'll just be a different type of fight. I can hope at least. :} Maybe this will give me some answers on the compiler front. It would certainly be interesting if things became easier rather than harder.

[muku]

Any nasty gotchas you know about with the 2005 express edition?

Hm, nothing I can think of right now. For the field I was working in, the missing OpenMP support was a bit annoying, but I'm sure you won't care about that. Also, that whole IntelliSense thing sometimes stalls the IDE for a few seconds on my quite old (~5 or 6 years) machine, but nothing that's too annoying on the whole. All in all, apart from being a terrible resource hog, it's quite a usable IDE. (It feels odd for me to say that, considering I once was a rabid Microsoft hater and still don't care much for a lot of their products and business practices... but hey, you gotta give credit where credit is due. For a free product, it's hard to beat.)

EDIT: Of course you'll have to install the .Net framework 2.0, they don't let you off the hook without that...

[Alex May]

I've been evaluating Irrlicht and Irrlicht.NET CP (official .NET support in Irrlicht was abandoned in 1.3.1 I believe, even though the web site has not been updated to reflect this - most confusing when discovering that irrlicht.net examples are nowhere to be found) over the last few days and have has similar mouse craziness and variable results. The .NET CP example in particular is completely bonkers on my home machine - moving the FPS camera completely destroys the view, everything runs really jerkily and the FPS display often reads "1" instead of 60 or whatever. The example runs fine on my work machine except the animations are completely fucked there. So I don't know what's going on and it's a shame because Irrlicht was looking nice up until this point, in terms of features and structure.

Compiling from C++ required extra downloading of Freetype source and libs, as well as the Irrklang stuff which apparently isn't distributed with Irrlicht. Once these were set up in the directories in visual studio express, everything seemed to work fine, although the ugliness of the examples is a real turn-off for the library, if I'm honest. It seems like a framework for those who want to make an FPS clone or something.

I don't know how OGRE is, as my main reason for evaluating Irrlicht was its .NET friendliness.

[dmoonfire]

I didn't have much problems with Irrlicht.NET CP (which works on Linux, a good point for me). As for .NET being portable, Mono is pretty good for Mac and Linux. I'm also working toward stabilizing my own engine to work across them, but I keep getting distracted.

[raigan]

I just wanted to offer a very left-field suggestion: do you really need 3D?

This might seem like a totally stupid question, but opting for 2D-only is a very pragmatic decision that makes not only the technology much faster to develop, but (probably more importantly) makes the content much easier/faster to develop.

Of course if your game _needs_ to be in 3D, or your real interest is in developing 3D tech, this doesn't help. I just feel like finishing ANY game is hard enough, and especially if your team is a single person, you might as well try to make it as easy as possible.

[Garthy]

Hm, nothing I can think of right now. For the field I was working in, the missing OpenMP support was a bit annoying, but I'm sure you won't care about that. Also, that whole IntelliSense thing sometimes stalls the IDE for a few seconds on my quite old (~5 or 6 years) machine, but nothing that's too annoying on the whole. All in all, apart from being a terrible resource hog, it's quite a usable IDE. (It feels odd for me to say that, considering I once was a rabid Microsoft hater and still don't care much for a lot of their products and business practices... but hey, you gotta give credit where credit is due. For a free product, it's hard to beat.)

Free certainly helps. "Nothing I can think of" is music to my ears. Re IntelliSense, I'm guessing that can be turned off? If not, shouldn't be too bad. Not being that familiar with their compiler I wasn't sure if their business model was to release a crippled compiler for free and charge for the fixes, or release a functional compiler for free and charge for extra features. Sounds like it might be the latter, which would work for me, as I don't need many of the features. I'd pay for a good compiler, of course, but I'd be willing to settle for "free".

Checked out OpenMP- interesting, but I think I'll be safe. General usability shouldn't be as much of a problem for myself as for others, since the serious dev is done on the Linux side, the Windows side is just porting work.

EDIT: Of course you'll have to install the .Net framework 2.0, they don't let you off the hook without that...

Heh heh, of course not. Shouldn't be a problem though. The way I see it, either they force you to link to it, or they don't. If they do, everyone else will have to as well, meaning the framework is likely up-to-date on most Windows PCs. If they don't, I don't have to use it unless there's some neat Windows-only feature I want to implement.

With any luck I should have VC++8 in my hands this evening. I just then have to download anything I've missed, and try it out.

Thanks again for your thoughts on this one.

[Garthy]

I've been evaluating Irrlicht and Irrlicht.NET CP (official .NET support in Irrlicht was abandoned in 1.3.1 I believe, even though the web site has not been updated to reflect this - most confusing when discovering that irrlicht.net examples are nowhere to be found) over the last few days and have has similar mouse craziness and variable results. The .NET CP example in particular is completely bonkers on my home machine - moving the FPS camera completely destroys the view, everything runs really jerkily and the FPS display often reads "1" instead of 60 or whatever. The example runs fine on my work machine except the animations are completely fucked there. So I don't know what's going on and it's a shame because Irrlicht was looking nice up until this point, in terms of features and structure.

Ah, I was hoping that someone who had played around with Irrlicht would post and share. Thankyou.

Not a good sign if they drop support for something significant and don't update their site- a bit concerning.

I also had some interesting animation results on my (virtual) PC too. The animations ran through extremely fast and didn't really match the motion. I wasn't sure what to make of that.

Compiling from C++ required extra downloading of Freetype source and libs, as well as the Irrklang stuff which apparently isn't distributed with Irrlicht. Once these were set up in the directories in visual studio express, everything seemed to work fine, although the ugliness of the examples is a real turn-off for the library, if I'm honest.

Heh, sounds easy compared to Ogre. Good to hear it wasn't too tricky to get going in VSE. It seems like I'll be having a bit more of a play with VSE when I get my hands on it.

A quick search suggests Irrklang is an audio library of sorts. It also has different license terms for Irrlicht (ie. costs $$$), which I'm guessing is why it is distributed separately.

It seems like a framework for those who want to make an FPS clone or something.

Oh dear God, quickly, kill it!

I don't know how OGRE is, as my main reason for evaluating Irrlicht was its .NET friendliness.

Did you end up evaluating any other engines (I'm guessing with .NET friendliness) apart from Irrlicht?

Thanks for sharing your experiences- much appreciated.

[Garthy]

I didn't have much problems with Irrlicht.NET CP (which works on Linux, a good point for me). As for .NET being portable, Mono is pretty good for Mac and Linux. I'm also working toward stabilizing my own engine to work across them, but I keep getting distracted.

Bit of a gamble aiming at a MS-driven tech, they aren't known for playing nice. There would no doubt be benefits to taking advantage of the framework though. I'm guessing with what you're working on, the tradeoff is worth it. For me, I'm not quite sure I'm at that point yet. Perhaps in the future.

Good to hear that Irrlicht is behaving in Linux. Linux compatability is important for me.

Thanks for the input.

[Garthy]

i'm a bit in similar situation at the moment like you. for a long time i was completely convinced that doing all myself is way to go... coding a graphics/audio engine can be interesting (and fun), but doing the whole job, i mean to really complete it, doing research in various fields and learning all the theory behind, doing scene management, file parsers, collision detection, networking, menu subsys etc. all alone is a fulltime job.

 it's not foreseeable how much time/energy it will really take, so many problems will (surely) arise. it's highly demanding unless you are a real hardcore coder (what i am not). even if you are one, it will take a lot time, cause every engine needs to be tested on various machines esp. when it should be cross platform, to be sure all works like on the dev machine

It certainly is interesting, and very educational. But yeah, it's a huge job. And to do it properly, I think it needs more than just one dedicated fulltime person. It's not very clear at the outset that the main challenge is not to just master the math and interface to a powerful low-level API. The big fight is that different cards and drivers have their own quirks and limitations, you have a lot of resource management to do, and the tech alone on some of the more modern cards is not only quirky but complex to learn. And small mistakes don't lead to small changes. Code that works beautifully on one PC will be missing textures on one card and will crash instantly on another. Then you find out the APIs are not quite as organised as you thought, and the documentation is a bit more lacking than it initially appeared.

And I'm only talking about the 3D graphics side of things. :O

How far did you get with your own graphics/audio work before moving to another engine?

... it's good to go through all this probably to gain some experience, but at some point it makes sense in my opionion to go a step higher (or to decide to stay DIY but make only small games wich don't need no separated engine): short and simple: a couple of days ago i discovered

Panda3D

and i started to see a light at the end of the tunnel . after some testing, i have to say, honestly, that's a piece of gold! give it a try if you're already looking around. i can really recommend it so far, especially if you plan to make all the content yourself too. i'm absolutly glad about this change, finally i can concentrate completely on the real game, and don't have to waste energy all the time with nasty hidden tech, which nobody cares about anyway. the strangest thing about all this is still that a completely forgot where i found this golden link

I hadn't run into Panda3D this time around, though the engine is familiar so I think I ran into it a while ago when I was first deciding what to use. One concern is that they don't seem to talk about Mac OS X compatability. A bit of a search around suggests that it might be possible anyway though.

Thanks for that 0rel. I'll be checking Panda3D out.

[muku]

EDIT: Of course you'll have to install the .Net framework 2.0, they don't let you off the hook without that...

Heh heh, of course not. Shouldn't be a problem though. The way I see it, either they force you to link to it, or they don't. If they do, everyone else will have to as well, meaning the framework is likely up-to-date on most Windows PCs. If they don't, I don't have to use it unless there's some neat Windows-only feature I want to implement.

Just a quick note on this one, since I'm not sure if I was fully clear: you do have to install .Net in order to get Visual Studio running, but you can in fact produce exe files which don't depend on the .Net runtime. Only if you use what they call "Managed C++" (and you most certainly don't want to do that) will also your end user have to have the .Net runtime installed.

[Garthy]

I just wanted to offer a very left-field suggestion: do you really need 3D?

This might seem like a totally stupid question, but opting for 2D-only is a very pragmatic decision that makes not only the technology much faster to develop, but (probably more importantly) makes the content much easier/faster to develop.

Of course if your game _needs_ to be in 3D, or your real interest is in developing 3D tech, this doesn't help. I just feel like finishing ANY game is hard enough, and especially if your team is a single person, you might as well try to make it as easy as possible.

No, it's not a stupid question at all, I think it is a very worthwhile thing to consider.

Do I really need 3D? I guess that strictly speaking, the answer is no. The game I am working on at present, like others that I've worked on, is sort-of-2.5D if anything. That is, it's in 3D, but most of the action is on a 2D plane of sorts, and for the most part, the 3D graphics are there to make it look pretty. Is it a strict 2D game? No. But it could always be 3D under the scenes, and I could just draw it in 2D, making it a top-down game of sorts. Quake could have been a top-down shooter too, had that been what they wanted to create. Or it could have been rendered like Doom.

The question though, is what I hope to achieve. And in this sense, I do want to translate the partial 3D into 3D viewing. So in that sense, the answer is yes. I've got my own engine at least to use, and it works acceptably. My goal is to make it a litte prettier though, and properly take advantage of modern hardware, and support more hardware properly. If someone splashes $500 for a 3D card, they're going to hate my game running at 20fps on it. If they have a basic card that I don't have, and my engine crahses on it, they aren't going to debug it for me. They'll just fire up the next game. For a non-technical person, they'll ask "why does this game run so badly, when all the others run so well?", and "this game is rubbish, it doesn't even run!".

And yes, game completion is difficult. I can use up my fingers and toes on completed games, but only fingers for commercialised/commercialisable ones. You always need to be on the lookout for things to make your task easier.

Having said all of that, I've got a big list of 2D projects that I'd like to try out one day. But for now, one person, one project.

Thanks for the unconventional suggestion. I hate the phrase outside-the-box, so let's just say abstract thinking is essential to creativity.

[Garthy]

Just a quick note on this one, since I'm not sure if I was fully clear: you do have to install .Net in order to get Visual Studio running, but you can in fact produce exe files which don't depend on the .Net runtime. Only if you use what they call "Managed C++" (and you most certainly don't want to do that) will also your end user have to have the .Net runtime installed.

Cheers muku, thanks for the clarification.

That's good news. I'm not too fussed about having to install .NET on a Windows dev machine, and if I have to make an explicit step to include the .Net stuff, all the better.