Engine components

Started by
7 comments, last by Mussi 12 years, 10 months ago
Hey guys,

So my plan is to learn the inner workings of game engines, not through making one, but through building multiple games without one and slowly building common functionality of an engine. My true goal is to make games, not engines, but I really want to learn how they work, so I am making my games using basic middleware and not full blown engines/authoring tools. I know the process will be slow, but for me the value is in the learning... Ill leave the super polished 3d games for the big companies :) . I am using java/slick2d and I might want to learn libgdx eventually to try out Android. Anyways that is not the topic of this thread, I already discussed that on here.

I want to pick up a book or two about specific game fields such as physics, AI, etc. Since I want to take this one subject at a time, what would you say are the topics I should explore first, before some of the others? My general idea is to develop my games in my own way, and then use specific books to gain knowledge of how to better implement parts of my games. I feel like this will really help me to learn. So for example if I made a SHMUP with very slow brute force collisions because thats all I could figure out, I would read up on physics and realize how I could do it better, you get the idea. So what are the "must know" areas that I should learn in more detail if I want to really be a better game programmer?And is there a particular order that you would recommend I read in? Realistically I cant do it all at once, Im thinking of getting one book at a time on one topic and truly understanding it/learning to implement it.
Never, ever stop learning.
- Me
Advertisement
I would recommend to keep yourself motivated by making visible progress; don't focus too much on one specific component. Ask yourself what it is that's currently really lacking in your project and start 'fleshing it out'. For example:

What am I missing? Input, I can't do anything in my game yet :(. So I go ahead and take some user input. Now what? Well I'd like to move the view with my input. Hmm I need some way of controlling my view. Done. I can't see any movement though, I need some sort of world/object, so I can see the change in view. I load up a box and play around for 10 minutes, happy that I got some basic movement done. Now what? Well I'd like my box to be more of an environment so I go and change that. Hmm I was supposed to have enemies in this game, lets add some way of representing those. Great, I can see some enemies, but they're just standing there... Lets make them follow me around. Jay! They're chasing me around. I want to be able to kill them now and make them disappear, they've become so annoying! So I implement a way of killing them. If they get close enough, I'll press my attack button to kill them. I now have the basics of my game done and I can start sculpting it the way I want until I'm satisfied.

Seeing your game progress is highly motivational. Once you have basic things going on, you'll start noticing what components are missing and which ones need improvement.
Oh ok so your saying I shouldn't attempt to just learn a subject for the hell of it... instead learn it as the need arises in my games? That does make sense, so if I find that my physics really sucks and it needs to be improved.. I should then read a book/article on the topic and refactor my game with the new knowledge?




I would recommend to keep yourself motivated by making visible progress; don't focus too much on one specific component. Ask yourself what it is that's currently really lacking in your project and start 'fleshing it out'. For example:

What am I missing? Input, I can't do anything in my game yet :(. So I go ahead and take some user input. Now what? Well I'd like to move the view with my input. Hmm I need some way of controlling my view. Done. I can't see any movement though, I need some sort of world/object, so I can see the change in view. I load up a box and play around for 10 minutes, happy that I got some basic movement done. Now what? Well I'd like my box to be more of an environment so I go and change that. Hmm I was supposed to have enemies in this game, lets add some way of representing those. Great, I can see some enemies, but they're just standing there... Lets make them follow me around. Jay! They're chasing me around. I want to be able to kill them now and make them disappear, they've become so annoying! So I implement a way of killing them. If they get close enough, I'll press my attack button to kill them. I now have the basics of my game done and I can start sculpting it the way I want until I'm satisfied.

Seeing your game progress is highly motivational. Once you have basic things going on, you'll start noticing what components are missing and which ones need improvement.
Never, ever stop learning.
- Me
http://www.terathon.com/c4engine/architecture.php

That's the architecture of the C4 engine, kinda shows how it all goes together.

http://www.terathon....rchitecture.php

That's the architecture of the C4 engine, kinda shows how it all goes together.


Holy crap lol. Well thats a good reason why I dont want to "build an engine". Creating all of that stuff with no specific game in mind would just be mind numbing. I think that by just constantly working on games and sort of having the engine "build itself" very slowly, I can actually make things Im proud of, and end up with some reusable engine code at the end.. And learn a a shit load too :)
Never, ever stop learning.
- Me
Yeah they're complicated as shit.

Like Mussi said, the best thing to do would be add to it as you go along. What I think you'll want to do (well, what I think you should do) is start writing a basic engine, or modifying an open source one, such as the old id Tech engines (I think they'll be releasing id Tech 4's source pretty soon, but now that ZeniMax owns id it's not entirely their decision), and just add what you need as you need it. I mean, building a game without an engine is still going to be extremely complicated.

http://www.terathon....rchitecture.php

That's the architecture of the C4 engine, kinda shows how it all goes together.


I found that link to be very useful so thought I'd say thanks.

smile.gif
Just start making games with your framework and start thinking : "What could I do to make my future projects easier"

At the moment im totaly sick of writing lllllllllllloooooooooooooong lists of Input comparisons so I got myself up and created a whole Input Managing system for my own future projects which is coming along very well.

The first thing I did was creating a texture managing class for my XNA game which made it more comfortable for me to create small games.

I think thats definetly a good way to get into the inner process chain of a game (engine).

If you want to build an own kick ass engine you better gonna read some books about them.
[size="2"]Java / C# Developer

Oh ok so your saying I shouldn't attempt to just learn a subject for the hell of it... instead learn it as the need arises in my games? That does make sense, so if I find that my physics really sucks and it needs to be improved.. I should then read a book/article on the topic and refactor my game with the new knowledge?

That's basically it, it'll make the why and the how much clearer to you.

The C4 Engine diagram looks mind boggling at first, but once you've programmed some of those components you'll find it much easier to understand.
You guys have been extremely helpful... I appreciate that you didn't just tell me to go and use unity because ill never finish games without an engine :) So my plan will be to slowly build my small games and add engine functionaliity.. also I will grab an engine that provides source (something like the source engine or an id engine) and try to learn from it/modify it. So do you think a lot can be learned about engine programming from taking something like sdk and making a mod?

As far as my goals go for finished games, I am not really concerned with making huge, flashy, commercial level games.. If that were the case I would just grab a proven engine like Unity and enjoy the design process. My real interest lies in the physics, AI, etc, working behind the scenes of these engines. I would be happy making some simpler platformers, puzzle games, rpg, top down shooters, etc. I really think that the caliber of games I have in my vision are definitely achievable in a reasonable time frame just using a framework like Slick or XNA, plus I feel like it will become faster as I create more reuseable engine code so I dont have to rewrite crap over and over. And most importantly.. I will LEARN how this stuff works.. not just accept that it works and move on. Hopefully all of what I just rambled about is true :)

So do you generally only interact with an engine through a built in scripting language, or actually interact with the engine level code? For example if I wanted to work with the Quake engine and make something from it... would I actually go into the engine code and change it?? Or would I just use a scripting language they provided? Ive never used an engine before so Im not very familiar...
Never, ever stop learning.
- Me

This topic is closed to new replies.

Advertisement