I agree but that looks a lot like what I said:
I understand your point and I partly agree but to say "if you want to be an engine programmer don't make an engine" sounds a lot like a zen monk saying "you'll be ready when you'll be ready".
Not exactly. The word "engine" is very very abused in game programming. An "engine" is a set of tools and API that allow an "integrator" to put together a game. In order to become good at making engines you need to understand what things make an engine good or bad, and, contrary to naive belief, that hasn't much to do with performances (up to a point).
To become good at designing a clear software interface means being able to avoid things such as making variable XY a public field of class Z when a bogus value of XY could crash the entire game.. this isn't some kind of "magic wisdom" that comes as a gift from above to some lucky developers, it's just sign of experience made by making that same mistake over and over again.. so now you know better and design software in a more robust way.
Every game is an engine.. that's what people mean when they go "make games not engines"... but the difference between a game and an engine is that a game has "computable values": is it finished? does it work? does it crash? is it fun? An "engine" is a never ending tale with no real tangible elements to judge it.
A game becomes and engine when some of its part can be reused.. but what's the point in reusing something that isn't even working in one single game?
I see this mistake over and over on the internet... I will do a game engine that does this this and that and people will use it to make games.. no they won't, unless you prove it's actually able to deliver.
sorry to go a bit OT from your original question but the line I quoted deserved a dedicated answer.
focusing on a game is great because:
- you understand how to do something.
- you have code working in practice, not in theory
- you learn what to do and (more important) what NOT to do to build a flexible component
The only difference is I think "a game isn't an engine". First of all different games require different features and to focus on a game won't automaGically deliver reusable components. Example: a few years ago I wrote an ENGINE for mobile games in java and at that time Nokia Serie40 1.0 dominated the market. Because of size limitations ( 180kb memory on VM and 64kb jar size) I had to strip down the code by taking ugly shortcuts. I had exactly 8 sprites on screen so I created an array with fixed size 8 in the main class then removed the sprite factory and manually loaded them at startup. As of AD 2011 (but also 2005) if you are creating a set of sprites with a new inside a for loop and then you have to take care of them all you have is a sprite class, not an engine. Yes the class can be awesome but still that isn't an engine: it's a sprite class.
To stretch this to the extreme, 100k of spaghetti code can turn out to be an entertaining game, but no way this is even remotely an engine.