I'm not going to get heavily into this discussion since it's basically a dead-end (people are going to do what they want regardless of what anyone else thinks). That said, I will throw in my $0.02 on a couple issues. Note that I'm not talking to the original poster specifically, but rather anyone interested in this subject.
1) Assembly.
Don't use it unless it's absolutely required. You should only even consider using assembly in small speed-critical inner loops (verified by a profiler; do not make guesses about this), where you're absolutely certain that no algorithmic optimizations can be performed instead, and where you're absolutely certain that you can beat the compiler-generated code (verified once again by profiling).
In an entire game this might amount to only a small handful of functions, nothing more, and they're only turned into assembly at the very end of a project when there are no alternatives. 99.9% of the time assembly is not your best option, because the development and maintenance time/cost of assembly code is much higher than that of C/C++ code, and at some point you hit the area of diminishing returns. The vast majority of the time you're better off finding ways to do algorithmic optimizations (the best code is the code that isn't executed) rather than jump into nuts & bolts prematurely.
Do not think of these opinions as coming from someone who doesn't know anything about assembly; I used to do demo coding back in the 386/486 days and I loved assembly back then, but things aren't the same anymore. Compilers are much better, and hand optimization is much harder with modern P3/P4 systems which have complex branch prediction rules and instruction prefetch queues large enough to make cycle counting a nightmare (not to mention that it's difficult to count cycles accurately in multithreaded OS environments anyway).
In short, don't touch assembly unless it's late in the project, it's the the only option, and you're absolutely certain that you know what you're doing.
2) Engines.
You cannot make an engine that'll last forever. What you can do is design your engine within a solid infrastructure that allows easy additions and upgrades (like replacing a renderer, or a scripting language) over the engine's lifetime. This will not keep the engine alive forever, but it should at least increase its lifespan.
Of course, a large factor in knowing how to write an engine like this is experience, so if this is your first major engine project (and by "major" I mean absolutely no less than 50,000 lines of C/C++ code at a bare minimum), then don't expect things to go smoothly. Even experienced engine developers take a nontrivial amount of time in design upfront usually, and if you're new to this you'll probably want to take even more.
BTW, I highly recommend building your infrastructure in a bottom-up component-oriented fashion, favoring composition more than inheritence (i.e. black-box reuse). With as diverse a problem domain as a 3D game, it tends to work out much better in the end. Feel free to white-box individual subsystems in the engine, that's fine, but treat the overall architecture as a layered set of components.
3) New developers, new projects.
"Never be afraid to share your dreams with the world, because there's nothing the world loves more than the taste of really sweet dreams." - despair.com's poster for Bitterness
Game development is rougher than most aspiring developers think, and they often don't realize how rough it is until it's too late. Start small and gain experience. Experience and time are your most valued assets, so take advantage of them or they'll take advantage of you.
--
Chris Hargrove
Senior Programmer, Legend Entertainment
