@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?
|
Quote:
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.. |
Quote:
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. |
Quote:
Quote:
Quote:
|
Quote:
Quote:
Quote:
Quote:
|
Quote:
|
Quote:
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
Quote:
Quote:
|
Quote:
Quote:
Quote:
|
Quote:
Quote:
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: |
Quote:
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. |
Quote:
Quote:
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:
Quote:
Quote:
Quote:
Quote:
Quote:
|
All times are GMT -5. The time now is 11:09 PM. |