But as a suggestion to the OP for increasing productivity without giving up quality, could I suggest you find someone that'd be willing to peer-review your code and give you feedback about when the base code is "good enough", when you're over-featuring, and where you should move on rather than polish and goldplate?
I'd love to do this, but primarily because if I was able to find another programmer who I felt was competent enough in C++ to offer advice and discussion, and was willing to spend the time doing so, I'd like to think that I could get that programmer to help out with actually writing code as well. Theoretically then, we could get everything done for a game in half the time (or at least significantly faster). Unfortunately I've not been able to find said person - there's a guy on the team who offered to program when we started (he writes code for his dayjob, like me), but a lack of time and interest on his part means that he's contributed maybe a dozen lines of code in 2 years, which isn't great. Still, I'm always on the lookout for another potential coder - I'm not super-precious about writing every single thing myself, in fact I'd rather not have to.
You NEED to have an environment that lets you not worry a single bit about the technical details.
That is all.
Whether it's your own engine or someone else's engine or some obscure language, it doesn't matter. You need to have this. If you need to get an image on the screen you need to be able to do it in one line of code or a drag of a mouse or whatever. The same thing should apply to any other technical part of the game.
If you like writing your own engines, that's fine, but be realistic and understand that until you have a complete and stable engine (something that takes months if not years of work), your actual game making will be hindered by the many technical features that you'll need to implement along the way.
That's definitely what I'm aiming towards in my engine. Currently I've got a new texture down to 3 lines of code: One to load it, and bind the resulting OpenGL texture ID to an enum value so the rest of the game can just use the enum, one line to specify a new entry in the enum, and one line which is just a string version of the enum value, so that the XML parser can turn a string into the actual enum. With stuff like level data (stored as an XML file), I don't need to add any new lines of code: A routine scans a specific directory and lists all of the level files it finds in there, which I can then load from a drop-down menu.
In terms of technical features in my engine, it's relatively complete now, I think. Got a renderer (custom OpenGL job); proper entity & sprite manager including an animation system; state machines for basic AI; windowing and input (SDL); physics (Box2D); XML parser (tinyXML); audio library (Audiere); user interface for menus and editors (Guichan); texture loading (PicoPNG); a solid library of utilities (vector classes, string manipulation, timers, all that kind of stuff - no memory manager to speak of, but that's not so important for PC games), an event system to get subsystems "talking" to each other without introducing too many dependency problems... I suppose what I'm hoping now is that the engine work is going to slow down to allow me to shift focus more onto gameplay, but it's taken a long time to get to this point.
Developer
