Sign in to follow this  

Building an Engine: Rough Schedule of Learning

This topic is 2045 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi folks,

My first post here so hello all [img]http://public.gamedev.net//public/style_emoticons/default/biggrin.png[/img] .

For many years I've been interested in Game programming and it's only been recently that I've put a good amount of effort into 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. I will soon start working in the computer industry after graduating and spending a year out so I'm not necessarily looking to do this as a job but if after 10 years of studying whenever I get the time I have the knowledge that would let me do so, that would be great (or indie dev on the side).

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.

I realise there might not be a simple path through all of material out there but if someone using their experience could provide a rough schedule of what I should be teaching myself in respect to building a 3D engine, that would be great. Just a list of broad or specific topics set out in what you consider a natural progression and I'm a happy bunny [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] .

While I imagine a lot of this is pretty general stuff, I'm programming on Windows, using OpenGL and C++ in case that helps.

For now I think I'll put Scene graphs to the side and look into VBOs and then maybe animation or shaders.

Thanks for any help, I appreciate it.
JC

Share this post


Link to post
Share on other sites
[quote]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?

Share this post


Link to post
Share on other sites
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! Edited by GodFear

Share this post


Link to post
Share on other sites
[quote name='turch' timestamp='1335966767' post='4936753']

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?
[/quote]

Thanks for the reply.

I have to say, I partially agree with you. I know that big ambitious long term projects usually end prematurely - we're pretty fickle beings, especially when it comes to programming [img]http://public.gamedev.net//public/style_emoticons/default/wink.png[/img]

I consider it slightly different however, as my goal isn't so much to develop a 3D game engine (at the moment) but rather to learn the concepts. These would be my milestones and seeing each one implemented albeit in a small use-case would give me a great sense of achievement I think.

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.

For that reason, I'm still looking to continue to learn how to build a 3D engine and would appreciate it if anyone would provide me with a "technique check list" if such a thing is possible. Your suggestion coupled with GodFear's however, has led me to consider a smaller, more manageable goal in the long term that I can focus on now or work on simultaneously...


[quote name='GodFear' timestamp='1335972707' post='4936782']
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!
[/quote]

Thanks for the reply. As I mentioned above, I'm still looking to learn the 3D stuff but your post has inspired me to look into building a somewhat simpler 2D engine. I think I'll do this while still trying to learn the 3D stuff, maybe alternating them when I get bored [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

Share this post


Link to post
Share on other sites
[quote][color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][left][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][/left][/size][/font][/color]
[/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 [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img] but its absolutely worthwhile to learn.

Share this post


Link to post
Share on other sites
10 years ago, there was no Facebook, Gmail, quad cores, Twitter, let alone Kickstarter, ...

Don't worry about 10 years from now.

Instead, make sure you complete something every week.

[quote]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.

[quote]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. Edited by Antheus

Share this post


Link to post
Share on other sites
Thanks again for the replies.

I've seen quite a few people recommending an early move away from the fixed pipeline stuff so maybe I should give that a go pretty soon, even if you do describe as going downhill from the start hehe.

Antheus, 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. After all, someone has got to make the engines of the future!

JC

Share this post


Link to post
Share on other sites
Trying to create a game engine without a game in mind will lead to a weak engine at best. Take collision for example. There are several kinds of collision algorithms, each with pros and cons. Are you going to implement each and every one? Without a game in mind, how do you define which types of collision ge implemented? You're either going to decide arbitrarily, or support everything; neither approach leads to a focused end result.

You can learn all the concepts you want to learn by making games. Conversely, without having made some games, you lack necessary experience to make a game engine that is actually useful. By making actual games your engine will emerge from your projects, will have features that you've shown to be useful, and won't be cluttered with features that you didn't actually need.

And as you complete aspects of your engine, how ae you going to show it off to others, or judge your own success, if you don't have a game of some sort to make use of it's niftiness? The unreal engine is pretty sweet, but without a game that uses it, there would be little evidence of its merits.

Share this post


Link to post
Share on other sites
[quote]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.

[quote]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.

Share this post


Link to post
Share on other sites
yckx and Antheus, thanks for your detailed and insightful posts. I think it's starting to hit home that an engine is more of an organic thing, born out of the need to make a certain style of game, or indeed from those games. I think this has highlighted a certain amount of naivety on my part.

Now to start making a game!

Share this post


Link to post
Share on other sites

This topic is 2045 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this