At the very least, looking at an existing engines source gives you some idea of the magnitude of the task
You're a programmer, at the very least you can criticize it and find ways to do it better.
Lots of stuff goes into an engne, there's the model rendering, the environment rendering. The collision. The the control scheme, the netplay, client server stuff, all the goodies.
Then there's the datafile format of the missions, any scripting support (unless you do it all in code, which means you need a different overall skillset in developers). If it's an existing engine, there may even be a way for level designers to start doing POC's and model builders to start having polycount guidelines, yada yada yada.
Just look at it, you don't have to use it.
If you're serious, that's my advice. I went from nothing to playable in a commerical engine in very short order. Adding gameplay elements via script is what's killing me and taking time, mostly because I am just doing this for the fun of it, not because I have a design document. And I am just adding things to learn various parts of the engine itself.
Buy versus build
Always faster to buy and customize, starting from scratch can be painful. Especially if you go with something open source, you can change everything, including the rendering engine, without having to redo other parts. Difference between a mod and a standalone game
Give me 2 weeks and I'll be able to make a better comparison between what's free, what costs a little (like Torque) and what costs 10grand (about to start working on a project that uses Lithtech, disks in the mail, project is funded, engine is liscensed, just waiting for the "go").
I guess I should make a point, get ready for a LONG post
______________________________
You/we/whatever need a plan.
Gotta start with a scope: How much do you want to do?
Package evaluation: Use an existing engine? Write one from scratch? Hybrid? What gets us a game that we WANT to play in the shortest amount of time? What kind of user supported dev do we want? IS everything in code? Are the levels done in Max? Do we want to write our own editor? Do we want to go with an existing model format? How fast do we want it? How fast do we think we could do it? You get the picture, half of the work is figuring out what the right questions are.
Then you move into some kind of design phase: Now you know what you want to do, and possibly what tools, possibly the timeframe. Now you do technical design and game design. That encompasses
. Need to figure out what the game is about, what kind of game play. That "functional design" needs to be mirrored in the technical design, you're already favoring OpenGL, does that limit you in any way? If you have a new model format, what are it's specs? What kind of information does another programmer need to know about it to write an exporter? The level editor, what kind of files does it save, etc? The scripting (if any) support, does that engine need to be developed from scratch? What C++ functions do we want to expose to scripting? How much control do we want to allow the script engine? Netplay? TCP? UDP? Session state of the clients tracked at the client, on the server? Both? Do we have coding guidelines, will comments be handled in the same way throughout. Will someone review the code before comitting it ot a build? Source control? HOW will builds get done? Are there Acceptance criteria for modules? Basically, you take any lists you determined in a scoping excercise and you describe in detail those elements, every element you can think of, writing psuedo code to describe the process if needed. Do flow charts. Mockup GUI in photoshop, POC models in 3ds or whatever, probably concept art for future models
Then, and only then, do you start real coding. Sure, during scope and design, you're probably writing test harnesses and POC's, psuedo code, mockup or even partially functional screens. Now you are in the Development phase. You did all the REALLY hard parts in Design, now you implement it. Code the engine (or modify it). Build the models and levels for testing, and placeholder while the artists go out and do real models, build the guis in layered photoshop so the programmer just has to cut and paste elements, follow the flowcharts. Implementing is the easy part if you've done the homework. You'll probably revisit the design several times. Count on it. Count on it changing some too. Somethings that look great on paper just end up taking 5 times as long as they need to and either need yanked, or redesigned.
Then, Testing. Both ongoing unit testing by individual programmers of there individual modules while coding them, and system testing, where you start stringing modules together. Bug reporting, priority. Fixing. SOme of this can be going on while other parts are still being coded. Say you finish the SP experience you can test that, the model importing and the map making while still working on the net stuff. Eventually, you'll have something you can public alpha, then beta, then....
Release, and expect to need to patch as a whole NEW group of people encounter your code.
I have not missed a deadline in 3 years. That methodology up there is how we deliver multi million dollar software engagements.
Never come into a problem without a possible solution
Resume and references available on request.
