A long journey starting with a simple step...
 

Hello all,

I'll just jump right into it: I would like to create a high end FLOSS FPS graphics engine for the Linux OS. I have a few questions about it and I don't know where to possibly start so I'll just throw them here:
1) What program language to consider? C or C++? And why? Should I also learn other programming language(s)?
2) What and where do I have to start learning about everything but the programming languages?
3) Is OpenGL up to the task of new rasterising technologies? In other words; is OpenGL future-proof? Is it 'realisable'?
4) What other stuff is necessary? SDL?

I got too much free time on my hands. I know how crazy this idea sounds but I don't care. If John Carmack can do it than so do I. I consider myself intelligent enough for it. My motivation is creating momentum for Linux gaming in general.

Between C and C++ you want C++ - this will let you take advantage of object-oriented design, amongst other things. Opinion is usually divided over what to learn first, all the courses start the same but there is some merit to the idea of starting with C++ so you don't have to discard some of the paradigms you'll learn with regular C.

You start learning programming by getting a book and doing tutorials. But, as soon as you can, find a project in active development and play with it. You'll learn faster the sooner you start butting your head against a big chunk of code.

Remember - you may be doomed if you fail, but disappointed if you never try.

@Simon Bridge: Will C++ not be an considerable performance hit or is that just a myth? I already have the second edition of Bjarne Stroustrup's C++ book, but I am wondering if it is not better to learn C because of performce before I start learning this 1040 pages long book :/

Lua or Python, because they are prime candidates to be integrated into engine for scripting. Lua is easier to integrate, but offers less features.

You should learn about 3D math and graphics. www.opengl.org has a list of recommended reading ("red booK", "orange book", etc), which should cover everything. Also Francis Hill's "Copmuter Graphics Using OpenGL" should be a good book to read.
You should also learn what free engines are available right now. Most free fps games use Quake3 derivatives (for example, ioquake), but there is also saurbraten (which is really worth looking at), and probably few more engines. Sauerbraten is closest to what you can develop alone.

AFAIK there is no alternative to OpenGL on Linux. All 3D linux games use OpenGL. As for "future-proof", OpenGL standard is evolving, and in future there will be new versions.

Yes. Again - there will be little choice if you want your engine to be portable.

AFAIK John Carmack didn't do it alone.

It's a myth. You can get good performance when you know what you doing and without trying to do OOP in C. Also there are many FPS engines written in C++. Performance hits are programmer's fault, not language's.

I shall second everything ErV said here.
Particularly that last bit.

Remember, once you get a feel for how things are set out, start looking for a project - get the source and study that. See what needs to be done, and have a go submitting small patches. Brace yourself for critique - learn from it. Bear in mind that people submitting code instead of, or alongside, bug reports are very valuable.

I already started to learn everything on http://en.wikipedia.org/wiki/Portal:Computer_graphics. Are these good references for starters? Or would it be wise to start learning some place else?

I was think about something along the lines of making a basic, clean and fast, but also easily expendable engine and play catch up with the latest id tech engines later on. id tech engines are obsolete by the time they are released as GPL software Or should I start with learning the Quake 3 source code and expand on that? According Wikipedia id had almost completely rewritten the id tech 3 engine (porting it from C to C++) in order to create the tech 4 engine (Doom 3). Isn't the Sauerbraten engine just a cube engine? That's a joke compared to todays commercial engines.

I know that there is no alternative to OpenGL and because of that I wanted to know if I wouldn't be hitting a massive brick wall along the road. In other words; I wanted to know if it was even worth it to start making an engine for Linux. The reason I am asking this is because the Linux port of Doom 3 isn't applying some more advanced rendering techniques when I set it to ultra high. I was thinking that maybe there is no such functionality when using OpenGL.

Why not just save yourself a whole lot of man hours and use ogre. Generally an rendering/game engine evolves out of games you have previously made not really from scratch.

Ogre3D is OOP C++ and according to Erv that is a performance hit. Besides... isn't Ogre3D a little too complex and too "can be used for everything" rendering engine?

You had better tell that to the AAA game studios then. What language and paradigm do you think they use?
Where did Erv say that

I was making a mistake: I thought he had said OOP in C++. Sorry Erv :(

I can't help you here. I learned basic math many years ago, and it was based on "demo.design.faq". This is very old info, and I do not know english translation of that.

I think that "basic & clean" is incompatible "with easily expandable".

There were several conversions of quake, for example, tenebrae which added per-pixel lighting and shadows. Those engines can be converted and upgraded, but it is up to you to decide if this worth the try.

I think you should take a look at quake 3 conversion instead (ioquake, for example). Quake 3 code isn't easy to read.

Honestly, you should play it, try its' level editor and see yourself.
//personal opinion follows
Saurbraten is closest to what you possible can do alone without a team. Engine incorporates advanced lighting, post processing, it is easily extendable (using scripting, custom-written shaders, and so on). I think it is 75 percent finished commercial engine. Make more details, fix some bugs, increase texture resolution, change shaders to more heavy stuff, change lighting model to realistic lighting, and you will get very good engine. It has source code and it is easier to use for learning than quake 3.
I also like elegant idea behind the engine.

Also you won't make commercial-quality game (without army of artists) alone if you will keep using standard techniques. If you will invent something new, non-standard and interesting (for example - generators for levels, monsters, textures, which will reduce amount of required work), then you will have some chances. Good example of interesting approach is kkreiger, but, unfortunately, its' source code is not available.

Yes, it is worth it. Besides, there is always commercial Mac OS, and there DirectX is also unsupported. I also think that OpenGL is easier to learn and use and with it you will create something much faster.

Which techniques exactly?
Doom 3 uses OpenGL on all platforms. It (I mean Doom 3) is also fairly old by now, so there is no hdr (which I hate anyway, because it makes everything yellow) or similar effects. If you want to be sure if "opengl supports that", then download and check nvidia sdk. Half of examples there made for opengl, and many of them compile on linux without modifications. Also by the time you'll have something working, there will be probably newer OpenGL standard.

I said that C++ is not a performance hit.

Yes it is too complex.
//personal opinion
This is what you will get if you will start making generalized easily-extendable engine without clear goal in mind. To succesfully write an engine, you should concentrate on narrow easy-to-define task. Once it is done, you can start adding features.

No-no-no!... I don't plan to have this entire dynamic loading plugin framework crap! :) Rendering is turning a mathematical, three dimensional scene into a two dimensional frame, right? So you have these processes of computing textures, shaders, lightning effects, etc, right? Well if you make all of these processes functions, you'll have a top-to-bottom list of processes that are processed from top to bottom, which make up the renderer. What I mean is that I could easily expand the renderer by inserting more processes/functions into that list.

Do you mean the style in which the code was written or the structure of the entire source code?


The idea is to create the engine first :) Making a complete game is something I'll be considdering in the future. I will however create at least something (one level maybe) with all the ideas that I've came up with during daydreaming about making my own game even since I was about the age of four :)

I have thought about that too in the past. Stuff like: randomly create a tree for x amount of times. Then have a tool in which you will have a topdown view where you can say: Some vegetation here and there, absolutely not there, create a bit if high here and a large valley there but not steeper than 45 degrees because I have to create a road over there, etc.

I don't remember as I played it back when the Linux client came out for. All I know was that there was no difference between normal, high and ultra high settings. Tried it with both ATI and nVidia hardware.

Yes I hate it when HDR is not implemented correctly! Some studios just implemented it for the sake of having it. For example in Gears of War it is used even though the entire game takes place in a dark, cloudy world. Valve seemed to be the only one who got it right: only the sun has HDR, but when you are going into a dark place (let's say a cave) everything is dark for a few seconds until your 'eyes' get used to it, but when you'r used to the dark and you go outside the entire world is HDR'ed, untill you get used to that for a few seconds and then the entire HDR goes away.

I have an ATI card now. ATI HDRadeon 4870 X2 to be precise. (offtopic) Everything from from watching DVD's in a full compositing OpenGL DE (KDE 4.2) to playing ET:QW and Warsow in 64 bit works like a charm with the latest proprietary ATI driver. (/offtopic)

That's exactly what I want to do. I am currently learning the principles of everything related to a game engine and constantly narrowing things down; ray tracing, ray casting and volumetric rendering... no I am going with rasterisation. Lightning techniques... these are old, these are too heavy... penumbra in shadows in shadow maps is coming to id tech 5, ah that's realisable, ok so I'll take that, etc. The idea of large worlds instead of levels is also appealing to me and not having to deal with a limited set of textures in the memory but streaming a 20GB texture from the HDD is also cool but a huge performance hit. But wait... fast SSD's are on the rise, ok so this is also realisable at the end of 2009. Ok let's 'steal' that from id tech 5 too. But first of all I have to do the basic stuff before even dreaming of that but it will all be part of my goal. Narrow stuff down and work my ass off :P

Not quite. Modern game uses shading languages to define shadings.
//opinion
Sometimes programmer decides to make "an extensible material/shader system" which allows to make any material, complicated lighting effects and custom shaders that are supposed to work on any hardware ever created with several hardware compatibility levels. This often looks plain awful and incredibly complicates engine, and makes engine faulty.
Another standard problems of all beginners - they think only about cool features and technologies, and never try to do game as a whole. They sink in features and fail to do complete game because of all modern stuff.

Quake 3 is written in C. Source is big, code is quite difficult to read and there is little documentation. That is all I can say. Feel free to download quake source from ftp of ID software. That is why I recommend to look for adaptation or saurbraten source.

//opinion
I think that creating engine for a game is easier than making engine without a game, because you have better goals, when you are trying to make a game. You really should start with idea you can imagine.

There are a lot of differences. Main feature Doom 3 uses is "automatic hardware" detection, which will show a lot.
To adapt to hardware, Doom 3 might:
1) disable specular
2) downscale textures
3) disable dynamic lighting from projectiles.
4) disable shadows.
5) Disable postprocessing (blur when you are hit) and refractive surfaces (glass).
All those features were considerable performance hits. Also, for example, texture downscaling and disabling light from projectilves happens completely silently. You can find out if those options are enabled only in doom 3 configuration file.

I think that most studios implemented it only for having it.
Most games that use HDR have that awful yellowish-pinkish color.

If your card supports OpenGL 1.5 or OpenGL 2.0, many demos should work.
There was ATI sdk somewhere, but it was mostly DirectX/Windows related. Nvidia is better for OpenGL+Linux.

//opinion
No offence, but this is a nice way to sink in the features without ever finishing the idea. I was through that before.
For beginning, try to do something that looks like Quake 1, at least, but will work and can be quickly finished. Once you have finished product or prototype, you can add all advanced lighting stuff.

Is this done through OpenGL?

Ok. Yes I've already started reading the Quake 3 renderer code, but I think I'll go with the Cube Engine 2 (saurbraten engine)


I was already thinking about making some kind of space shooter, inspired by the coolness of Quake 2, which is the only shooter I stil replay after all these years.

I hate auto detection as it always gets it wrong.

I bought an ATI card because AMD released documentation and because recent nVidia cards cope with manufacturing problems. I refuse to buy defective products.

Add modern graphics on top of outdated rendering techniques?

I meant that they have some good code freely available in sdk (examples, and so one, and not all of them are nvidia-dependant), and some useful libraries, like nvtristrip. Also (not sure if that is good or bad) their glsl compiler is less picky than the one used on ATI. As for their manufacturing problems - they aren't my concern right now, because I'm happy with my card.

Yes.
Besides there are already conversions of Quake 1 engine to newer technologies. Modern graphics are not that different from "outdated" ones. Besides I meant to use opengl without shaders (so quake 2 would be better example), which will allow to build prototype quicker.
If you won't be able to do game which looks like Q1, you won't be able to create anything that looks better.
Differences in rendering sequence are minor. The only thing you should prepare yourself to is that you might have to render scene or parts of the scene more than once and possibly from multiple points of view (which means that occlusion culling part should be flexible enough to allow that). That is the only thing that matters. Once you have working prototype with old-style lighting, you can easily move it to multi-pass per-pixel lighting, because it all comes to finding objects and lights that affect them (even in old-style lighting, because limits on number of lights are pretty strict even on fixed-function pipeline), determining visible (and/or lit) faces in the level geometry, and so on. And besides dynamic lighting (and setting shaders) the rest is identical - you have scene graph, you determine what is visible, what lights affects it, and you render it, and in many cases you can still use same functions for setting matrices. In my opinion, in the end it all (even rendering) comes to collision detection, and it hasn't changed much.

@ErV: Ofcourse it is probably better to start with something basic, but diving into the complex makes one learn more and faster. Besides... if I'd do a Quake 1 or 2 engine and I would want to make some bad ass renderer I have to start doing things that I had already done before. So exactly how long would it take to build a Quake 1 engine given you already learned enough to make one, but haven't got any experience building one?

"Learned enough to make one" doesn't really tell anything.
I think that making semi-quake1 quality engine might be up to 6 months, and 2 months at minimum. That is - if you are doing all stuff yourself, and it is really rough estimation. "All stuff" includes collision detection routines, scene graph management, custom model format, exporter tools for 3D editor (handling skinned animation during will be tricky, but tweening used in Quake 1 can't be used right now - ineffective and processors are much more powerful than they were back then), load managers (or caches) for textures, sound and objects, few utilities, etc. Most time will be spent on collision detection and export from 3D editor. Each of those can take up to month alone, and are not easy. Also since you are eventually going to turn it into "modern engine", you can skip radiosity calculations for generation of lightmaps and either skip lightmaps completely (it will be ugly, but it will work) or use easier methods. You could also skip skinned animation and use something like robots, since it might produce difficulties once decide to move calculations skinned animation to GPU.
You could also skip export if you will find a way to create good-looking geometry within your engine. But there is no guarantee that it will be easier than writing export plugin.
If instead of writing your own routines you will take ready to use libraries written by other people, this might save you 1/3..1/2 of time, but minimum time will be still approximately two months.

Notice that this is a very rough estimation, it could be wrong and either overly pessimistic or overly optimistic. I'm not a foreteller, and some people spend years "trying to do something" without ever finishing even simple Quake1 style game.

The time you will need to spend depends on how you detailed is your goal. For example, developing all-purpose collision library for generic oriented primitives (point, line, ray, triangle, box, sphere, cylinder, capsule, etc) and meshes with all possible queries and contact information might take a month or two. But making a library that supports only collisions between mesh, capsule and ray (which is enough for fps) might take just few days. Making skinned animation system that supports unlimited number of bones on any hardware will be more complicated than making animation system that supports maximum of 26 bones. Making generlized extensible material system with support for user defined shaders and lights takes weeks. But making nicer (per-pixel lighting) non-extensible replacement of fixed-function pipeline that supports per-pixel lighting and only point lights will take days. And so on. That is why I keep saying that the most important things is how detailed is your goal. The less detailed it is - the more time you will spend. The best idea is to make a list of stuff you can't live without, implement only things in that list and ignore anything else until list is finished..

Diving into the complex without experience usually yields a product that, while it represented a good learning experience, isn't good for much.

Old cliche; You should learn to walk before you learn to run.

The quality of the end product will depend critically on the architecture that you deploy at the beginning of the project, regardless of whether you know going in how to do the whole thing or not. If the architecture is bad, the product will be bad. If you are experienced, you will quickly realize it if you are starting with a bad architecture and you will change it. If you are not experienced, you will not realize that your problems are fundamentally related to your basic design, and you will carry on, cobbling together a "grand bodge" that can't be easily extended or maintained.

I've seen it many times.

If you want to build your massive project, by all means carry on. You'll learn a lot. But more than likely when you get to the end - if you do - you'll throw it away and start over.

Speaking just for myself, I sell a program that I have been developing for 16 years now. I am actually quite pleased with how well it works, and how easily I can extend it. However, when I started out building it, I threw away my first three efforts before I was sufficiently comfortable with the language and the database product that I was convinced I was on the right track architecturally. Furthermore, twice since I have completely rewritten and reorganized the thing to take advantage of new language and product capabilities. And now, I am rewriting the whole thing again, this time in C++ to work with an assortment of SQL backends. But with THIS rewrite, I am keeping the basic architecture - modified to exploit the capabilities of C++ and a multitheaded OS.

Sixteen years. No fooling.

All that said, I think that Erv's speculations about how long it will take you to do a rendering engine are vastly, vastly, vastly optimistic. I am certain that I couldn't meet the kind of schedule Erv postulates, and I AM an expert at that kind of thing.

As I said, time you'll spend developing things greatly depends on how much you simplify the problem. An engine developed in 6 months, might not be identical in every feature to Quake1/2, but will look similar, and probably will be a bit slower. To my experience, it is possible to develop simple space-sim engine within a month, if you are determined/fanatical enough. Another problem is that I meant large amount of time spent coding every day during those 6 month, not just some kind of "coding on weekends".

Game engines are a different story when compared to the program you were working on. And if you weren't working on games, you aren't expert here. It isn't a sql backend, not even close. You can actually implement rather simple engine which will yield good rendering results, or spend years developing complicated systems that just won't work good enough. I can say that when working on the game if you weren't able to produce working engine within a year, you are obviously doing something very wrong and this might mean your project has failed, because industry moves on, and one year might be enough to be left behind. You can't spend 16 years developing fps, because technologies evolve very quickly. Just two years normally mean huge advancement in technologies. Of course, I'm not talking about complicated engines like used in ID or Monolith games, that were evolving for years, upgrading along with technologies. One programmer can't replicate all way those engines went through - there won't be time for this. But you still should be able to do something that will work on OpenGL and look like Quake 1 or 2 before leaping to the next step. 6 months is realistic, because right now developer has much more power at his hand than developers of Quake 1 originally had, so making game that looks similar to Quake 1/2 right now will take much less time than development of Quake 1/2 originally took.

In "rendering engine" hardware (i.e. OpenGL) and SDL takes care about serious amount of stuff. You don't have to implement software renderer, so this is really much simpler than it was for quake 1 developers.

First of all; I am not going to create a product, unless you are refering to the product of ones efforts.

You are either doing something terribly wrong, you don't realy have what it takes and/or you are not doing it fast enough and/or you aren't putting a lot of time in it. A lot of people underestimate themselves and after seven years of webdesign (for example) are still not capable of doing it fully and rightious, while others may learn everything in a year and create the most beautiful and functional websites. It's all about good planning and looking for where to learn stuff before you do it. Talent and interest are two different things. Also... database programs can take up to 50-500MB while game engines are smaller than 5MB, which might be more complex but require a lot less coding. I hope I haven't insulted you or anything because it's certainly not my intention.

I heared a lot of people say that something is too hard, too complex and not realisable. A lot of these people have been proved very wrong.

First of all; it al depends on the person. Secondly people that are realy experts never say it for themselves.

LOL. Carry on.

Out of interest where are you getting this misinformation?
V!NCENT I am sorry to say that you are the sort of person I dislike, you come here asking information, get a little knowledge then think you know better than others. I can say for a fact that some people in this thread have knowledge of/studied games whilst others ... well ... Do you think these people got their knowledge and completed a rendering engine in one year, hell my studies where four years on there own.
[edit] Why not go and post this information over on gamedev.net and then the experts (yes some are the cutting edge guys in the industry) will tell you what they think, but please do not think you know even more than them. :)

@jiml8: I guess my post was insulting to you. I am sorry for that. I don't know your work and I don't know you. But I am a hardhead towards people that take demotivating standpoints and expectations. My very attitude made me accomplish a lot more than people expacted from me, if they expected anything from me at all. Just because others may have a hard time doing things doesn't mean I will have a hard time doing it. I am also a hardhead in not taking standpoints from self-proclaimed experts, sorry for that too. I am very thankful for guidance and advice, but being insulted out of others thinking other than you also says something about you.

:-o
 

The bare Quake 3 sourcecode comes in at 5,5MB, that is ofcourse excluding external libraries and software. Also, executables in commercial games are often 1,7MB once compiled and stripped of copy protection. Ray tracing renderers for example have a very, very small codebase whilst very heavy on the CPU.

I am sorry, but do you expect me to take responsibility for being overly positive and motivated? Does pushing myself realy hard and aiming to perform better than others makes me an insulting stereotype to you? You should, just for the fun of it, look at people that got ridiculed and flamed at for thinking different in history, who turned out to had it right in the end. I am not messuring myself with these people ofcourse (so much for a disclaimer that appears to be nessecary allmost everywhere and I'll exclude my reasons why).

So you are talking about shipping executable size and not the media size, which it is quite normal to be on a DVD or multiple CD's these days for pc games! and you use a game which was shipped nearly a decade ago as your source of information to make a blanket statement. Also where did you get the information about shipping executables without DRM?

Well who else should take the responsibility?
No carry on it is always good to show people examples of epic fails.

Oh I don't know? You mean these cracks that I download when I copy a game I purchased so I can continue to play it after I installed it for more than three times? Red Alert 3 maybe?

You mean those uber-1337-guru-experts at Epic who failed to port Unreal Tournament 3 to Linux? Or maybe those uber-1337-programmers who shipped AAA titles that couldn't finnish Prey and Duke Nukem Forever in time?

But I'll just go away here as I am a complete n00b who isn't capable of anything and doesn't know anything, is unable to learn and thinks he always knows it better but is always wrong in the end-stereotype. Bye.

Thanks ErV and others who weren't in the mood for bashing and actualy gave me real advice and help, I am actually able to use and learn from, in their spare time. It's greatly apreciated :) :thumbsup:

LOL. Carry on.

You are marked. I won't offer any help or comments to you in the future.

In fact, I have had people like you working for me in the past. I invariably wind up firing them.

Wrong. Take a look at large commercial packages. Adobe Photoshop, Microsoft Windows, and so on. Or take a look at wine. 15 years of development is normal for large software, which is constantly being improved.

Wrong.
1) Size of database program will be small. Database might take terabytes, but program that works with database will be much smaller.
2) It is quite common to meet game engine with total executable size about 20..40 megabytes, especially on windows. You should take game libraries in account. Sometimes executable can be less then megabyte, and the only think it does is calling function from 20 megabytes large dll which emplements entire engine.
3) Don't confuse size of executable with amount of coding require to create it. They have very little to do with each other. kkreiger (mentioned before) takes only 96 kilobytes (engine + game data) and shows high-quality modern rendering. But this doesn't mean you will be able to create it within a day.
4) "database program" and "game engine" have nothing to do with amount of coding. It all depends on complexity of task - both games and databases can be incredibly simple or incredibly complex. Also some games work with database-like structures.

For your information, it is said that good programmer writes 500 lines of fully debugged code per day (to my experience it is quite close to reality). For reference - saurbraten has 42165 lines of source code (1668875 characters), and quake 3 has 67989 lines (2250301 characters). This is estimated by "find . -iname \*.c\* -o -iname \*.h\* -exec cat {} \; | wc -lc". To my experience creating software with 200 kilobytes of source code takes approximately a month (even if you keep aside "500 lines" statement) - when you aren't in a hurry, inspiration (or idea) don't hold you at the gunpoint, and you are working few hours per day. Now you can roughly estimate how much it will take to recreate quake 3 or saurbraten while working alone. Simple calculations return 4 (500 lines)..11(200 kilobytes) months for quake 3 and 2..8 months for sauerbraten. It isn't ideal estimation, but it will give you an idea. Notice that with "500 lines" rule there is a problem - while maybe you do add 500 lines of fully debugged code each day, you are constantly overwriting existing code, so you are losing finished lines each day.
To my opinion such numbers aren't perfect, but they are pretty close to reality. You can reduce amount of time by simplifying engine and removing all features that are not required. For example, "wolfenstein 3D" clone written in OpenGL will take 1..2 month at most, and will have higher resolution of textures, filtering, textures on floor and ceiling, particle systems and possibly 3d models of enemies. You can even add high-quality lighting to it. But the level will be a grid made from cells. And hiding (yes, you will have to optimize it, because 20 and 400 fps are a huge difference) invisible cells won't be straightforward.

And another thing. Actually under certain circumstances you might be able to work with the pace enough to recreate saurbraten within two months. There is 1% possibility of that. But this means that you won't be doing anything except coding, in the end of work you will be seriously exhausted mentally. Basically, you will feel like you've fried your brain, you won't be able to think about anything, will have headache, and will feel really dumb. It will wear off but it is not a nice feeling, believe me.

Now I think this was more than enough information about game-making.

I suppose 500 lines per day is OK as a number - when all you are doing is coding. But, I personally don't spend all or even most of my time coding. Most of the time is designing. How I design just depends on the project. I might do it all in my head. I might be having meetings with other people, using up markers and whiteboards. I might be writing formal specifications. I might be doing all of the above. I also spend a lot of the remaining time documenting. The manuals to operate my commercial program, taken in their entirety, run to almost a thousand pages at the present time, and that doesn't include comments in the code that tell me WTF I intended in this section here.

So, the time required to generate a source code file of N lines...consists of the time coding, plus the time designing, plus the time documenting. And let us never forget the little gotchas that tie you up for a day or two trying to figure out why this three line section here isn't doing what you think it should be doing.

Also, I submit that the 500 lines per day is only valid when you are doing something that you know how to do...it is plain vanilla, or it uses only capabilities, functions, and features that you already know about. This is usually not the reality though. You are often pushing into a new direction, learning and doing something you haven't done before. So you spend time reading documents. Tutorials, man pages, textbooks, whatever. Personally, I asked a question on this board just yesterday because I had encountered an issue in socket programming that some people here are very familiar with, but which I had never encountered before. The problem is now solved, but I had help.

Sometimes, in simulations (you know...like graphics engines?) you find yourself doing math. Tensor math. Rotation matrices. Quaternions. Trigonometry. Calculus. Finite element analysis. In this case, you spend a LOT of time working out the algorithms and most especially defining and controlling the boundary conditions. Then you have to test these algorithms - and sometimes that can take a LONG time. I myself have spent literally YEARS validating the logic and calculations in some simulations. In fact, this need to validate is the single biggest (and potentially insurmountable) problem associated with the large and growing computer simulations used in the global warming analysis.

I myself am presently working on a project that is breaking new ground in satellite communications. Conceptually it is simple enough, but my client tells me it has never been done before (they were just awarded a patent on the process), and I have never seen anything quite like it even though I have been doing RF and signal processing work for almost 30 years. So my client has told me what it is to do, and I have a free hand in doing it.

As of now, I have the core piece working reliably. In fact, I am quite proud of it; I have now demonstrated that this technique is feasible.

At this point, I have written approximately 800 lines of C code and a couple hundred lines of C++. It has taken me 3 1/2 months. My client is thrilled. So am I. We both think that progress has been excellent so far. In fact, one thorny design problem was solved when I had an epiphany over a pitcher of beer in a local karaoke bar. Another solution came about due to a discussion on this site. The design problems in this case are not computer architecture issues, they are engineering and physics issues. "Given that this is the physical reality, how on earth do I extract THIS piece of information - and quickly?" Once the way to do it is identified, the computer programming is almost trivial.

So, 500 lines a day is a highly questionable number and really doesn't tell anything about the time required to develop a project.

jiml8, although I understnad you have large experience, I'd like to point out few things out and end arguing:
As I mentioned before - this is a very rough estimation, which is close to reality. I also mentioned caveats of that estimation. I also mentioned that to meet time calculated by "500 lines" you'll need to went berzerk and experience mental exhaustion in the end.

V!NCENT was talking about FPS. You can't spend much time designing this. It is not a database application. All that could be discovered, is already discovered and most games have common structure that is unlikely to change radically in the future. FPS were done before, and engines will have common elements.

jiml8, you really should remember that developing the game is not the same thing as working with program you created. Most things are already discovered. So you will spend much more time coding, especially if this is a "quake-like" game for the beginning.

It is all explained. Many times. There are howtos and explanations, and many of them has source. COmplex parts have libraries ready to use. There is no place for reasearch - all stuff is already finished and implemented by someone, or there is an algorithm. Making a game can end in simply putting together parts made by other people. Of course there will be math. But this will be school level math (+matrices and quaternions), that is normally ends in "sphere"<->"plane"<->"ray" interaction. This is easy and normally can be solved in minutes instead of years.

This application is not a game engine. It chases different goals and should not be compared to game engine. If you have developed application that works with satellites, do not assume that working with game engines will be a same thing. It is an illusion, and, no offense, but your undoubtedly interesting programming experience doesn't have much to do with game development. You must understand it.

When I was much younger, I did develop things that are now called games. But then, we called them "simulations", we used mainframes and dedicated minis to power them, and we used expensive vector graphic displays to display them. We also used four and five degree of freedom cockpits to lend verisimilitude to them. This was for the military.

Today, there are large libraries that are based wholly or in part on the work that people like us were doing way back then.

It was my understanding that OP wanted to develop a game engine. When I think of a game engine, I think of all the work we did back then to make these algorithms run, but I think that you are referring to what I would call the next level up, just using these libraries and integrating them to build an application.

If that is what you mean, then certainly that is a lot simpler.