@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.

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

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.