Building an Engine: Rough Schedule of Learning

I think my goal now is to slowly build up my knowledge of building a 3D game engine and put that knowledge into practice over a number of years.[/quote]

A lot of people will tell you that that's a bad approach. A multi-year project is going to make it much more likely that you don't complete it. You can run into a wall and get frustrated, you can lose interest. This is especially true for new programmers. I've been there, and so have many others. That's why everyone recommends "make games, not engines". A short, simple, realizable game is much more likely to get completed and will give you an easily achievable feeling of accomplishment.

In addition, its a bad idea to learn on production code. When you are doing something new, you tend to take shortcuts and program sloppily; this is not something that can be done on a multi-year project (which is one of the reasons you'll likely get fed up and abandon it). Things become more and more bloated until you just can't keep up with all of the patches and duct tape. You end up spending weeks refactoring your code, or more likely abandon it.

Think of a new painter: would it be reasonable for them to buy one canvas and expect to slowly paint it up over the years until they've achieved a Creation of Adam quality work?

A lot of people will tell you that that's a bad approach. A multi-year project is going to make it much more likely that you don't complete it. You can run into a wall and get frustrated, you can lose interest. This is especially true for new programmers. I've been there, and so have many others. That's why everyone recommends "make games, not engines". A short, simple, realizable game is much more likely to get completed and will give you an easily achievable feeling of accomplishment.

In addition, its a bad idea to learn on production code. When you are doing something new, you tend to take shortcuts and program sloppily; this is not something that can be done on a multi-year project (which is one of the reasons you'll likely get fed up and abandon it). Things become more and more bloated until you just can't keep up with all of the patches and duct tape. You end up spending weeks refactoring your code, or more likely abandon it.

Think of a new painter: would it be reasonable for them to buy one canvas and expect to slowly paint it up over the years until they've achieved a Creation of Adam quality work?

I think the most important thing in starting out is to set a goal but make sure that goal is not too ambitious.

In my first attempt to develop a video game i set my goal like this:
1. To develop a simple side scroller shooting game (like Gradius type of game)
2. Graphics will be 2D so all i have to do is create a sprite based rendering engine
3. Collision detection (contact check between space ship, enemies, and projectiles) is a simple overlap test.
4. Sprites are just simple polygons (circle, triangle, rectangle, etc...)
5. simple system for power-ups and score.

That said, in 3 months i was able to create an engine that runs the game and the actual game itself. Graphics look like a 80's video game but it works and very fun.
Completing this small project gave me a sense of achievement and motivated me to try out a more complicated project next time.
Or i can actually build up from this small project and extend it to 3D, add shader based animation and effects, add features that has physics based collision response, etc...
The point is this - it's like playing Diablo. As you kill monsters, you level up. And when you level up, it has to feel rewarding. That way, you get motivated to keep going on.

I hope this helps!

[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

[background=rgb(250, 251, 252)]So far my efforts have got me to a point where I've got a 3D model loader, I can add some reasonable fixed pipeline lighting, textures and materials and also some basic physics and collisions - nothing too flashy. I'm at the point now though where the deeper I get, the darker it gets. Looking to add a more global collision detection in anticipation of larger scenes in the future, I started reading about Scene Graphs. In adding lighting, I've also looked into shaders. Basically, the amount of material and techniques seems quite daunting but I'm more than willing to get stuck in. I don't want to dive into the wrong pool however - if it's possible, I'd like to approach things in a logical manner so I'm not going to hit a wall because I didn't use magical technique X.[/background]

[/font]
[/quote]

I would actually recommend moving onto the programmable rendering pipeline and trying to re-implement what you've done so far with fixed function. That means learning shaders. They look intimidating at first... And actually - they just go downhill from there but its absolutely worthwhile to learn.

building a somewhat simpler 2D engine[/quote]

It's called Flash. It's a painfully solved problem. Why not try that? Build a game in one week. Then another.

Then move to Unity3D and do the same.

And in one month, you'll either have 4 games or realize that what you really want is to build engines, something that has no real world use (because nobody builds an engine, everyone builds a game first, then perhaps reuses that for second one and calls it an engine).

Engines as a technical challenge were relevant in the 90s with lack of drivers and GPUs and whatnot. These days there's library for everything. Look at Unreal, 30 or so external libraries.

There are exceptions, but they don't apply to someone starting off.

To take your painting example, I would compare it rather with a new painter buying a canvas and slowly learning the techniques, each time painting a different picture, maybe one with a certain brush stroke, one with perspective etc.[/quote]

That means making games.

Building an engine is akin to growing and chopping wood for frame and shearing sheep to make canvas.

my main interest are in the 3D graphics and architecture side of things, I'm not as focused on creating a game just to have it played - I want to know what's going on underneath.[/quote]

Architecture is not art. It's means to an end.

After all, someone has got to make the engines of the future![/quote]

All engines that are in use today were built as means to an end. They were not designed upfront.

Unreal was a game. It was designed to be better than its arch rival of the time - Quake. And Unreal won.

As it turned out, developers behind Unreal did a few things right, so others looked at the game and started modding it. Unreal then slowly transformed into an engine through games Unreal Tournament, Unreal 2 and 3 (or however the numbers went).

Each of these reused large portion of the code, but term engine was loose.


The key to Unreal Engine is not the engine - development of original Unreal game created a toolchain and an editor. Engines today are about that. So to build an engine, you need to build a toolchain for the runtime. There lies the value.

And the only way to develop an effective toolchain is to absorb what actual developers and artists and managers and publishers and users and .... do.

That's the futility of engine (framework, library) design. They cannot be created in an ivory tower, they need to grow from habits and techniques of all of its users.

There is no "Engine 101" course. There are graphics techniques, simulation techniques, hardware details, ... But all of those can only be put together for actual case.