Well I hate to take the ratings hit, but I think people who give you the opinion to work on your game as an engine don't ship many products.

I won't rate you down, as I think it is productive to discuss counter opinions - so I would also suggest that others don't rate you down either. To be perfectly honest, I don't work in the games industry, so I haven't shipped any games. I have however build and delivered many diverse applications that use 3D rendering functionality. So you are right, I can't speak to game development, but I most certainly can speak to software development that utilizes reusable rendering routines and algorithms (i.e. an engine).

So are you implying that you don't have an engine? You just work on one project, and when its time for another project you just take the existing project and modify it? What if you find a bug in your rendering routines - do you have to go back and make the same changes to a bunch of different projects?

It seems a bit silly to me to make the leap that anyone that tries to properly design a reusable library somehow isn't successful at delivering the end product. In fact, I would say the opposite - having discipline and considering a design aspect of a library has always driven higher productivity in my experience. You mileage may vary, but when you have to support many simultaneous and different projects with some common functionality, then I think it only makes sense to consider that common functionality as an engine...

I also don't work in the games industry, so I personally haven't shipped any games either. My understanding of the engine space is limited to Microsoft platforms, specifically directX. I develop a game in my spare time. I hope to one day make money from the game I develop, but of course I haven't, mainly because I work alone and I don't move quickly enough to capitalize on any markets. :(

I've been working on my hobby game for about 5 years, in that time Microsoft (which is where my full-time job is ironically), has changed the directX APIs significantly. I haven't had time to adapt, simply because I'm trying to get my original game finished. I would imagine that a slightly larger team (< 100 people) might actually be able to crank out a shipping game product in less than a years time with a certain degree of quality and make some money from it.

My opinion is that if they spent any extra time doing "engine" work they would both lose that slim chance to make money and still not create the re-usability they are after as the industry would have passed them by.

My opinion is that larger teams (> 100 people?) could make a living out of developing engines, either as middleware or for a platform with reasonable (3-5 year) longevity. In that case, the investment of time and energy in perfecting a usable engine *might* actually pay off for those larger teams.

However, for the hobbyist, I would not recommend wasting any time in crafting an engine or designing for reusability or future use. The hobbyist in my opinion should be obsessively focused on just producing a result and getting it to market (even if its alpha), so they can MAKE MONEY from it :)

The dilemma seems clear to me and is something I run into often.
I solve it very pragmatically:

- I work on my engine, keeping and expanding it in a structured way (keeping reusage in the back of my head)
- since it doesn't deliver direct results, when I have a difficult challenge, I make a fairly simple game to get some results and experience in gameplay (not even using the engine :))

The 2nd even helps me indirectly with challenges I face in my engine.
For example, I was stuck with my flexible point light management for weeks, so I made 'Asteroidz' and actually finished it. This gives me new experience on gameplay functions, audio etc.. And luckily yesterday I found the solution for my point light 'challenge', so now I can get into that and improve my engine. Between all this I try to read books and articles which can give me knowledge on both fields.

All from a hobby perspective for now. But from my daily job (not programming) I have quite some project and product management experience, which drives me to doing preparations and in this case makes me want to make a good design of the engine. Combine that with an upcoming 2 week holiday with just an iPad, some ibooks, a paper and pen... Makes me think, lets rethink the design of the engine, highover. What should it be able to do? How to split this in usefull namespaces? Including which classes and inheritances? Etc.

I could actually copy my timer (FPS management/ time delta) class including all functions, 1 to 1 directly to my Asteroidz game, saving me time. This also motivates me to have my engine include independent classes and parts, so I can reuse them anywhere (as far as possible of course). The same goes for my audio namespace/ classes (FMOD wrapper) and (dx)input wrapper.

Is it a requirement for your engine to be cross-platform? If so, make sure to spend some time on creating platform independent abstractions for rendering and audio (including shaders .... HLSL is platform/render API specific).

For directx will do, I'm trying to make my scenegraph, object, lights, scene etc. Classes API independent and have inherited classes to be able to use them for d3d. I think FMOD should be fairly simple if I move to another platform (a few other parameters).
Basically for now all d3d (keeping in mind upgrading to dx11) and where possible having data structures D3D independent

@Steve: I think you are mixing two arguments, and that we are agreeing more than disagreeing. Your experience is that you started out with one API (I guess D3D9) and now there is D3D11.1 - so your efforts are socked into the D3D9 level of effects. If you were using a well designed engine, the pain of upgrading to a new API would be significantly decreased. That is the whole point of an engine, to decouple the game itself from the reusable parts. On a side note, I don't think there is any need to update in this case, as there are still quite a few D3D9 based games being released...

One other point that I wanted to make was regarding hobbyist vs. indie vs. professional (Juliean touched on this too). If you are working on something as a hobbyist, then by definition you are doing it because you like the topic and want to do it. If you are trying to create a product and sell it, then you are more like an indie, where you are making more of an investment and want to get monetary returns on it. And of course, the professional makes their full-time paycheck from working in the area.

I have personally been a hobbyist for a very long time, and moved into doing professional work more recently - skipping the indie stage. It sounds to me like you are more focused on being an indie developer, which takes a totally different perspective than a hobbyist. The OP is looking for perspectives on hobbyist development, so I still think he should lean towards developing an engine as a learning exercise. He clearly seems motivated enough to knock out a few games here and there, so it is also clear he is learning from doing. I say, keep it going and enjoy the ride.

If you are having trouble finishing your game, is it because you don't have enough time to put on the project, or something more like feature creep? Identify what the problem is, and take steps to handle it! I want to see your game on the (digital perhaps) store shelves!