Give me a day to collect my thoughts and notes from the event, but I’m leaning towards using the framework I currently have as just a place to rip source code from and going back to a series of weekly prototypes. Although I am going to look at some of those engines like Unity and see what they’re capable of.

I also forgot to link the talk “Unique Knobs” from the folks at Metanet (http://www.metanetsoftware.com/technique.html) which says a similar thing.

Take my Dream Build Play entry (“Dark”) as an example. There’s nothing (editor aside) there that even needs unit testing – you’d struggle to find even 20 lines of engine-ish code in there. I basically treat my platform (C#, XNA, Farseer Physics) as a glorified scripting language. Because of this the only things complex enough to need unit-wise testing (shadows, player physics) could be tested visually by using line drawing as one might use Debug.WriteLine or printf. Otherwise my “debugging technique” (as if you only use one?) was to liberally apply Edit and Continue (nice in an IDE and language where it works reliably).

Yes, the code is a little inelegant – but most of it can safely stay that way!

Only now that I’m finished the game am I even considering getting more “engine-like” – taking what I have so far as a prototype of sorts and fixing the narrow areas where plain C# and XNA are limiting. You could just about call it refactoring!

I think that, perhaps, you are being too academic about things. And not so much with the unit-testing (which is fine – albeit a “warning sign”). Game development doesn’t need to be treated like one big monolithic, academic assignment that must be all done correctly and in one attempt (with a healthy dose of “not invented here”).

Just pick a platform that lets you get to the actual meat of making a game and stick to it. Treat game development like an artform rather than an engineering exercise. (And I mean the game-as-art sense, obviously – as much as I love it, code-as-art has an extremely small audience.)

(If you must be cross-platform off the bat, Unity and PyGame spring to mind as potential platforms. I don’t recall what SDL provides, but raw OpenGL is much less than ideal.)

(PS: I say all this because I have been in very similar places myself – you might even recall a particular project of mine, how well it went, and how much time it devoured.)

I’m also starting to think the pure C approach might not be that great an idea, and moving to what is a version of C++ that is essentially C with namespaces and STL containers might be wiser. I’ll see. Part of my trouble is that I haven’t touched any application above an academic prototype size for a while, so I’m remembering the best way to approach things (unit tests, debugging techniques, etc.)

Also, I find that it can be a lot of work using a scripting language for large amounts of code. Even though scripting languages can be very concise, the number of runtime errors can be a productivity drain. I was trying to write a system with mostly Lua for the code and a little C++ to wrap graphics, input etc but I found it was almost as much work than writing the majority in C++ and wrapping game play. I think there is a nice middle ground, but its hard to find…