[Nathan2222]

Forum newbie.
Been searching google for things like "my 3d game engine project" to see already created engines and how long it took but no new results so i thought to ask here.
I just want to know how long it took to get the 3d game engine to a usable state (years/months). How many/what libraries you used (ogre, fmod, directx, physx, havok, qt, cegui etc.) and if not c++, which language
Thanks .

[modi123_1]

Curious question - why would you want to build one? What benefits are you expecting to eek out of one that would be different from - say - an existing 3d engine?

'usable state' seems like a subjective issue.. if you are going custom it is because you think you can snatch some unaccounted for benefit by coding your own.. so that tends to fluctuate with the project's goals..

http://gamedevelopme...s--gamedev-8143

[BBeck]

The term "game engine" has different meanings to a lot of different people. It's not an "exact" thing.

Take Unity for example. You don't have to have such a "game engine" to make a game. 90% of what Unity is capable of doing isn't necessary for 2D games. Most of it's code is really written to support 3D games. Even then, you can make a game without most of that code.


You could probably write somewhere between 100 and 1,000 3D games in the time it would take you to make Unity by yourself.


If the question is "How long would it take to make Unity by yourself with no experience or prior knowledge?" I think the answer (and this is just a wild guess) would be probably about 20 years or so. The number of books you would need to read would probably be somewhere between 100 and 1,000 just to acquire the necessary knowledge.

That's not to say that you can't do it, or that you can't write 3D games on your own. Just get ready for a long uphill battle in learning it.

And also keep in mind, that you don't need 99% of Unity's capabilities to make simple 3D games. Unity is stuffed full of capability that obfuscates the complexities of bringing a 3D game to life.

For example, maybe your 3D game doesn't need a full blown physics engine. Maybe instead two pages of self written "physics" code can give your game enough "gravity" to work.

Just keep in mind, that you don't necessarily need an "engine" to have a "game" even in 3D and even more so in 2D games.

If you want to do 2D games, I would say "forget the engine" and just dig in to programming games without an engine (either one you acquired or one you built yourself). Once you know how to program, it's not that hard to get started in true 2D game programming without an engine.

[Nathan2222]

modi123_1, on 02 January 2014 - 06:32 AM, said:

Curious question - why would you want to build one? What benefits are you expecting to eek out of one that would be different from - say - an existing 3d engine?

'usable state' seems like a subjective issue.. if you are going custom it is because you think you can snatch some unaccounted for benefit by coding your own.. so that tends to fluctuate with the project's goals..

http://gamedevelopme...s--gamedev-8143

(Almost beat qt forums) Well, i'm not building the engine to learn (not the actual reason) but to make games with it. A specific game to be exact (others will follow). I've asked about other engines on forums and while some aspects are possible, some are not, at least not without paying for the source code. The only engines that came close were cryengine and torque but they had issues.

[modi123_1]

Quote

(Almost beat qt forums)

I don't follow.

Quote

Well, i'm not building the engine to learn (not the actual reason)

Okay.. just be aware

Quote

but to make games with it. A specific game to be exact (others will follow).
[...]
while some aspects are possible, some are not,
[...]
The only engines that came close were cryengine and torque but they had issues.

So I'll bite - what issues? What problems, or lack of features, were you missing from engines line Cry's, Unity, etc?

[SplinteredChaos]

Others here might be able to better assist in pointing you in a direction if they knew more about either your project or the requirements that the project has. I would say that with the mention of the Cry engine and torque having issues, knowing the issues you believe that they present to your project to make them undesireable choices would be pretty important information as well.

[Nathan2222]

BBeck, on 02 January 2014 - 09:14 AM, said:

The term "game engine" has different meanings to a lot of different people. It's not an "exact" thing.

Take Unity for example. You don't have to have such a "game engine" to make a game. 90% of what Unity is capable of doing isn't necessary for 2D games. Most of it's code is really written to support 3D games. Even then, you can make a game without most of that code.


You could probably write somewhere between 100 and 1,000 3D games in the time it would take you to make Unity by yourself.


If the question is "How long would it take to make Unity by yourself with no experience or prior knowledge?" I think the answer (and this is just a wild guess) would be probably about 20 years or so. The number of books you would need to read would probably be somewhere between 100 and 1,000 just to acquire the necessary knowledge.

That's not to say that you can't do it, or that you can't write 3D games on your own. Just get ready for a long uphill battle in learning it.

And also keep in mind, that you don't need 99% of Unity's capabilities to make simple 3D games. Unity is stuffed full of capability that obfuscates the complexities of bringing a 3D game to life.

For example, maybe your 3D game doesn't need a full blown physics engine. Maybe instead two pages of self written "physics" code can give your game enough "gravity" to work.

Just keep in mind, that you don't necessarily need an "engine" to have a "game" even in 3D and even more so in 2D games.

If you want to do 2D games, I would say "forget the engine" and just dig in to programming games without an engine (either one you acquired or one you built yourself). Once you know how to program, it's not that hard to get started in true 2D game programming without an engine.

You happen to talk about two things i am least interested in and one thing i don't like. (the two things) Unity and 2d games. (the one thing) The part about the physics. To me, realistic physics is as important as realistic assets and game play. I need realism and can't compromise on physics (it has to be as realistic as possible). And i am not making a unity replica.
The 20 years part in your post is so WRONG. I know up to 5 guys that have made unity/almost unity replica's in less than 4 years.

[modi123_1]

Quote

I know up to 5 guys that have made unity/almost unity replica's in less than 4 years.

Yes.. "know".

Again - it's all subjective on what you want to add, features, goals, and talent. There is, literally, no set answer in stone.

[axel1994]

And unless you're going to use libraries that already deliver those physics, you better get comfortable with lots and lots of maths.

Also, 5 guys working 4 years. That's means that they deliver the work of about 20 years fulltime work.
Considering you're always slower alone than in team. (talking relatively, 2 people work 1 year, than alone you'll work more than 2 years)

So 20+ years alone is actually a good guess from BBeck.

Probably those 5 people will be quite experienced people. So you'll definitely be slower than them (1 on 1)

This post has been edited by axel1994: 02 January 2014 - 10:28 AM

[Nathan2222]

modi123_1, on 02 January 2014 - 10:15 AM, said:

Quote

I know up to 5 guys that have made unity/almost unity replica's in less than 4 years.

Yes.. "know". />

Again - it's all subjective on what you want to add, features, goals, and talent. There is, literally, no set answer in stone.

By know, i mean i spoke to them (online) not just seeing their posts on the net.
To the part about the engine problems: Cryengine has problems (i was suprised when i checked on their forums). It has problems with vehicles etc., the online log in stuff, their forums (worst response time surpassed only by the qt forum), the map/world size limit due to floating point accuracies, the fact that they don't have a license or they do and it could cost more than i'm willing to pay.
As for unity, it's got problems with really open world games (gta genre), the fact that i gotta pay before i get the full stuff and no source code access.
Torque: Their forum is great but the engine has some issues. Map size limit, problems with character sounds, lip synching, problems with realistic effects like walking on a beach and having sand being kicked, it's scripting language.
Only cryengine uses the language i really want to use.

[Nathan2222]

axel1994, on 02 January 2014 - 10:26 AM, said:

And unless you're going to use libraries that already deliver those physics, you better get comfortable with lots and lots of maths.

Also, 5 guys working 4 years. That's means that they deliver the work of about 20 years fulltime work.
Considering you're always slower alone than in team. (talking relatively, 2 people work 1 year, than alone you'll work more than 2 years)

So 20+ years alone is actually a good guess from BBeck.

Probably those 5 people will be quite experienced people. So you'll definitely be slower than them (1 on 1)

Like i said, 20 years is wrong because the 5 guys made their own engines seperately. Some don't even know each other. They made the engines on their own, solo. So it's wrong (for me). Maybe right for you. The one that had the most features (still in dev) started around may 2012 (that's less than 2 years).
As for the math, don't worry about that. When i start any project, i relearn everything from the basics and for this project, that includes maths, programming, asset creation. As for gameplay, i can get enough if not excess ideas for the game and game engine before i even start it.

[macosxnerd101]

Quote

To me, realistic physics is as important as realistic assets and game play. I need realism and can't compromise on physics (it has to be as realistic as possible).

How much game development experience do you have? What experience do you have in writing physics components for game engines? I know from BBeck's posts he has quite a bit of experience in this area. A lot of times in computer simulations (which is what a game is, really), things only need to be realistic enough to "fool" most people. Animations are just repaints of stills that go fast enough to fool the human eye. What makes you believe such an approach would not suffice here? Do you have any experience to back this up, rather than simply arguing on the principle of demanding perfection?

[BBeck]

I might qualify a couple of things I said. When I said you could make 100 to 1,000 3D games in the time it would take you to make Unity, I meant fairly simple 3D games like 3D Breakout, 3D Checkers, and 3D Pac-Man. I'm not necessarily talking WoW or GTA there.

GTA in its most recent versions took a highly skilled and relatively large team of professionals about 4 years or so to put together.

It's all relative.

I suppose my point there was that you can do some fairly simple 3D games yourself in a matter of months, but Unity is far more complex than 3D Pac Man.

When I said 20 years, I'm basically trying to guess how long it would take someone. But, I'm assuming that the vast majority of that time would be in learning what you are doing. If you are already an expert, you might be able to single handedly program Unity in a few years. But by "expert" there I mean you are well known throughout the industry as one of the best and Bethesda hires you regularly for consulting on their biggest projects. It's really a hypothetical discussion as to how long it would take.

But just the math alone would blow most peoples' minds. Maybe the easy way to get that math knowledge would be to go to college and get a mathematics or engineering degree that is heavy in mathematics. A solid understanding of trig is an absolute must. Linear Algebra is something you will use all the time and that's the course you take after a couple years of calculus. But there you're largely talking vectors and matrices and I'm not sure you have to go through a full course in Linear Algebra to understand that stuff. The trig stuff also may apply more to the actual game.

Now the physics engine is likely going to require you to get a degree in physics or the equivalent knowledge. Most physics books are written in calculus. So, you'll need a solid understanding of calculus to even start reading a lot of the books you will want to read. And a physics engine is basically applied calculus. I try to make due without any knowledge of calculus, but I constantly find myself wishing I knew calculus so that I can read and get more help. And my physics simulations are still fairly straight forward (but still use vector math, matrix algebra, possibly quaternions (multi-dimensional imaginary numbers), and such, not to mention I took physics in high school and have read a college physics text book on my own. Not to mention that I'm extremely solid with trig and vectors to the point of being ready to teach them at the college level.

And a lot of writing an engine is in knowing what the engine needs to do. Do you have a knowledge of IK and FK animation? Do you know how to write a file parser to pull a .blend or a .fbx file apart and put it into a data structure that will be optimized for the game? Do you know how to turn that data into actual animation? Do you know how to animate a model in the first place? If you don't know the process the modelers, riggers, and animators go through to create the data file, how to interpret the data file, and how to turn a pile of data into a moving model, how do you expect to write the code for it?

Again, I'm not saying you can't learn all this stuff. I'm not saying you can't write relatively simple 3D games on your own without a team. I'm not saying you couldn't put Unity together on your own, given enough time and knowledge. I'm just saying that its a tremendous amount of work and you need to be determined to do it no matter how difficult it is or how long it takes because it's unimaginably difficult and will take an unimaginably long time. To succeed, I think you have to enjoy the journey, because its a very long one. Having someone who can show you the ropes will help tremendously too.

I think the key is to start out by learning the basics of 3D game programming and work your way up from extremely simple projects that emphasize learning a single concept, because there are 100's if not 1,000's of concepts in a 3D game engine or FPS type game.

But anyway, I would suggest playing with Unity for a year or so. Learning Unity will allow you to see what needs to go into a game engine and how the pieces fit together. If you make your own stuff in Unity, rather than buying a bunch of stuff for Unity, you will learn a lot about how art assets are created and put together. And if you do C# and Java scripting in Unity pretty heavily you may get a start learning those languages although that's still very different from even C# code with XNA (which is much more complex than anything you will get into in Unity, but at least its a place to get started coding). Maybe you can make a few simple games, as opposed to the open world idea you currently have. Then once you kind of understand what it takes to put together a game, then maybe branch off into doing it without an engine. It's all about getting experienced and learning. You can't expect to do Skyrim or GTA for your first project; it simply isn't going to happen. Those games took large teams of highly skilled people working for years to build. Granted, a whole lot of the reason it took so long was the level building and creating the art assets, but just the core, or engine, is a pretty significant accomplishment.

I like XNA as a platform for learning 3D programming. I consider it a great way to get into DirectX and OpenGL. But it's like Unity in that you get out of it what you put into it. Unity is setup to let you buy everything it takes to put a game together, but its also setup to let you build all that stuff yourself. The more you do things yourself the more you will understand it all. And if you never get into that lower level of doing it yourself you're not really learning anything. XNA, likewise, is something where you can go a lot deeper into the process than Unity, but you have to make the effort and go there.

If you start with XNA 3.1 and Visual Studio 2008 you can go through a lot of the XNA 3.0 books which are some of the best XNA books. And those are free downloads. You can learn a whole lot about 3D game programming from those books. And it sets up a good path towards learning DirectX. Once you get solid in C# and XNA, then maybe delve off into doing the same thing in DX9. Learn HLSL as you're building up to that. Both XNA and DX9 support HLSL but neither force you to know it. By the time you get to DX11 (or OpenGL 4.0) you should be an expert with vectors, matrices, Blinn-Phong shaders, cube mapping, parallax mapping, etc. And I don't mean "what they are" and "how to use them". I mean you know how to program them from scratch. In Unity you use them. When you go to make a game engine you need to be able to explain to a computer the mathematics behind your shaders.

Take a look at my blog. The link is in my signature. There it discusses just the logic that goes into making a terrain. Start with the "Brute Force" algorithm discussion and just read forward. Almost everything there is about making a terrain. Making a terrain is really the first step in making a game like you are talking about. One of Unity's abilities is that it not only takes height maps, but also has a fairly extensive terrain editor. This is just one small aspect of Unity, but if you read through my blog, you can hear a lot of what it takes to program a terrain, although Unity's terrain editor is 100 times as much as my blog covers. Still, my blog covers everything it takes to get started programming your own terrain editor from scratch even if it doesn't take you all the way up to Unity's terrain editor.

My blog doesn't get as far as going into a ROAM algorithm or other large terrain algorithm. Unity terrains use such a large terrain algorithm straight out of the box. But you have to have a solid foundation in basic terrains before you get into ROAM or any of the other more complex (and larger) terrains. Honestly, I've studied ROAM and a couple of the other large terrain algorithms and I'm still not quite "getting it". I need to sit down and dedicate a week to learning ROAM myself. I figure a week and about 40+ hours of focused effort studying it "should" allow me to understand that one very basic part of a game engine. I just haven't had time to dedicate to it yet and it hasn't been a high enough priority as I have a lot of things going on in my personal life right now and I'm also focusing on learning about Unity. But anyway, everything I outline in the blog should be learned before you even think about trying to learn ROAM or some very large terrain algorithm because it will all get used with them as well.

(I don't know that I'm going to do Unity rather than DirectX, but I want to at least get pretty solid with Unity so I can advise other people on it and help them use it to get better at game programming. It also allows me to understand better what goes into a game engine. I've already gotten ideas that I intend to take back with me to XNA or DX programming just from observing what they did in Unity. And it seems like a good prototyping tool and test tool for art assets and such even if I eventually go off and do DirectX instead. Unity is one of many options but it seems like a good place to get people started who have no experience at all with 3D game programming. XNA is much more low level than Unity. And then DirectX is much more low level than XNA. Anyway, I've been spending quite a bit of time playing with Unity lately. It's a neat toy if nothing else.)

And I guess my primary advice is to work on projects that are maybe just slightly more difficult than your current level of experience. Making a game engine like Unity is an advanced project for experts. Start out with something far more simple, like 3D pong or 3D Pac Man. And just get started learning how to code things. Maybe even consider starting out doing some 2D games, although I don't think that's an absolute pre-requisite. If you don't like 2D, there's no reason you can't jump straight into 3D although you will need to become a very solid programmer either way. You're simply not going to be able to make anything remotely like Skyrim or GTA for your first project. Start with something simple and work your way up to more advanced projects slowly.

This post has been edited by BBeck: 02 January 2014 - 03:45 PM

[Nathan2222]

You guys seem to be answering the question as if the topic is '' Should i make a game engine ". The answer to that question is yes, i've already decided that.

[no2pencil]

Until you've actually made games with other engines, I disagree. Just my 2cents.

Before you can design, concept, & build your own (anything), it is best to understand using ones that exist. This extends gaming engines.

But best of luck!