The ZERO knowledge guide to making a game

UPDATES

9 May 07
  • Updated prepacked blank project zip to Ogre 1.4

* Added link to DirectX SDK (Not needed usually)

INTRO !THIS ISN'T FINISHED YET!

SUPER DUPER WARNING, This isn't finished! It's plain wrong in some bits, come back when it's linked from the main wiki site

Go into 'discussion' at the top to help me out if anything doesn't work or is unclear, or TOO clear ;)

By Cameron Bonde aka 'Vectrex' on the forums

If you like this buy my game if I ever finish it :-) http://www.kartsim.com
email my gmail.com account 'octamed'

OK I don't mess about usually so I'll get straight into it. This is a quick starters guide on how to make a game with no knowledge of... anything!
We're going to make little game where you have to balance a ball on a tilting platform. PS3 watch out!

I tend to bold significant words. Probably words that would be in the code itself eventually.

I use these titles to catagorise stuff. Note I don't always do it in this order and sometimes not at all.

INTRO

  • General ramblings about the subject. More of a fuzzy explaination.




WHAT

  • What is it. Basic bullet point descriptions




WHY

  • Why we even bother using it. Alot of these things won't be obvious why they are even needed.




WHEN

  • When do you need to use it. People have trouble knowing when they need to use certain things.




WHERE

  • Code is pretty finiky where it goes




THE CODE

  • Code examples




TASK

  • An exercise for you to do. Actually do them though.. punk




If you know programming already skip to the 'Ogre' stuff.

Glossary

  • "3d engine" Draws all the pretty pictures
  • "Physics engine" moves objects on screen about in a realistic fashion
  • "programming language" instructions which tell the computer what to do in semi-human readable words.
  • "C#" a relatively easy programming language which is still considered a 'proper' programming language
  • "Mesh" a 3d object made up of a 'mesh' of triangles
  • "Texture" the surface colouring on a mesh
  • "Ogre3D"... you're looking at it (a 3d engine) ;)
  • "Newton" the physics engine we'll be using
  • "3d Studio Max" or "3dsmax" a 3d modelling program to make meshes/3d models.
  • "Blender" a totally free but still excellent 3d modelling program

Prerequisites

  • Zero knowledge in programming/3d engines/physics engines.. in fact if you understood any of that, you're over qualified
  • General knowledge of normal computer stuff
  • Visual studio express (used for programming)
  • .NET 2.0 (a microsoft thing)
  • 'MOgre' (3d engine + physics engine)

  • Optional
    • 'FreeSL', for doing sound
    • General knowledge of 3d modelling programs (I quickly cover it though)
    • '3d Studio Max'
    • 'Blender'

Setting it all up

Note: These versions are outdated - look for newer depency versions.

First we'll download everything we need. If any of these links don't work, just search for them in google.

  • ".NET 2.0" - This is basically a bunch of handy code made by microsoft. Get it here - DOWNLOAD

  • Visual Studio Express C# - The main program you'll be using to code. It's totally free. Get it here - DOWNLOAD





This will download a little installer. Run this and it will (hopefully) download and install the whole thing by itself. For smartarses you can get the complete iso image and burn it for easy reinstalls here - ADVANCED OPTIONAL DOWNLOAD ONLY

  • "Visual Studio 2005 Service Pack 1" - An update to Visual studio which is needed (may already be applied to the core download). Run this after you install Visual Studio (even if you use version 2008) - DOWNLOAD

  • "DirectX Redistributables from November 2007" - You need it, if you use the Direct3D9-Renderer - DOWNLOAD

  • "MOgre" - This is the 3d engine and physics engine in one. I've packaged up a ready to go version here 1.4-CSharp wiki guide blank project.zip DOWNLOAD. Just unzip somewhere sensible. If you want to manually set it up yourself and get the latest version go here ADVANCED OPTIONAL and follow the introduction instuctions. Frankly it's pain and I don't cover the extra stuff you need to set up, so it's for advanced users only. I'll update the prepackaged version here, but the full install also includes other examples which are good to check out.
  • "DirectX SDK" You MAY need this if your program crashes whinging about directX DOWNLOAD PAGE




That'll do for now. We'll get some other stuff down the track.

See also: MOGRE Installation and Mogre Basic Tutorial 0 for installation details.

Basics of programming/coding

"Ok you don't understand, I SERIOUSLY don't know what programming or coding is" - you.

WHAT


  • It's basically like an instruction manual made by you for the computer to follow.
  • It's not a simple list of instructions though. eg an instruction manual might ask you

e.g "'''if''' you have the deluxe model of the vibromatic, install the pleasure flange now"
  • Code 'runs' or 'executes' from top to bottom.
  • Each line of code does what it's told to do, then it goes onto the next line.
  • Code jumps around a lot usually. Think of those old 'choose your own adventure' books where decisions dictate where in the book to jump to, or tax forms where you are asked questions and you jump to different parts depending on the answer.



e.g. "'''If''' you earn less than 30c a year go to page 3"

WHY


  • Computers are dumb shit. They don't do anything for you really. You have to be really REALLY specific when telling them to do things in code. This is why code isn't like the english language, because if it was it'd be to ambiguous and easy to misinterperate. Some people have tried to do natural language coding but they've mostly failed miserably.

First things first

Before we bother with concepts I'll just state a few common things here

  • In the code there are 'comments'. Any text after a // is totally ignored. You can put in comments to remind yourself or describe things. THEY DON'T DO ANYTHING. The text will be green to remind you that THEY DON'T DO ANYTHING :-)
  • Most lines of code end with a ; character. This tells the computer that that's it for this bit of code (code CAN run across multiple lines you see but usually doesn't)
  • These characters { } are used to logically group bits of code together amongst other things
  • Code is cAsE SeNsItIvE
  • You can't use spaces in names of things. If you name something cams_item_of_awesome you can't put actual spaces there, hence using _ for a space. I usually type names like camsItemOfAwesome, but I'll stick with using _ for this tute as I think it's clearer. The only exception is when specifing a piece of text surrounded in quotation marks, like "DOG EGG"
  • DON'T PANIC if you don't understand something. You WILL be confused and feel stupid. Most programmers are in a constant state of not understanding half the shit they wrote themselves. We aren't born with this knowledge. Learning is meant to make you feel stupid at first, that's why you learn, so you can feel better than the peasants.



Before we start with the scary code, what are we making?

The game we're going to make is going to place a ball on a balancing/tilting platform. We'll use the mouse/keyboard to tilt the platform to try and keep the ball from falling off. Pretty simple but still vaguely amusing and a good base for something cooler in a later tute.
Of course you don't have to make this game specifically but for christ sake don't expect to make the next WoW for a while (read: EVER). Think fun Wii games and you'll get loads of satisfaction from making something with less than 50 people and 4 years. Games are alot of work, so if you want to make games for fun, make FUN GAMES, not games that rely on 6000 mildly different items to keep you addic... I mean entertained ;)
Later on we'll expand the game to have multiple balls/platforms and a proper level layout. Maybe even multiplayer stuff which instantly makes any game fun if you can crush another human.
Right, that's you told off, now on to the bit you've been dreading.
{CODE(wrap="1", colors="c#")}
{CODE}

Basic Classes and Object Orientation


INTRO

Right I'm going to skip WAY ahead of normal programming tutorials and go straight to 'classes'. Experienced programmers will think I'm insane right now.. probably because classes are usually the last thing students get taught because they're soooo scary, woooo!

Right, our game has 2 objects right? A ball and a platform, lost you yet? We're going to code a framework to get these 2 objects working

THE CODE


class Ball
 {
 }
 
 class Platform
 {
 }

"nooooo!!! it's SOOO HARD, I HATE PROGRAMMING!!", right shut up *SLAP*, it's really not that hard. Everything in life is an object to some degree. You're an object, the seat you're on is an object, so it should be pretty natural to think in terms of 'everything is an object' which is precisely what you'll have to do from now on.
Before I explain specifics I'm going to hit you with some code. It doesn't DO anything yet, but you'll often nut out the design of code before you start typing frantically. So strap yourself in and hook up the colostomy bag, here goes.


This example.. is you. Words to ignore for now are 'public' and 'void'.
So, you're a person (I presume), this is what you'd look like as an empty class

class Person
 {
     public string name;
     public string gender;
     public int age;
     public float height;
 
     public void sleep(int hours_to_sleep)
     {
     }
     public void jump(int how_high)
     {
     }
     public void be_annoying(float how_annoying, float time)
     {
     }
     public void make_the_tea(bool milk, bool sugar)
     {
     }
     public void sex_change(string new_sex)
     {
     }
 }

The first thing you'll notice are the words 'public' and 'void' BECAUSE YOU NEVER LISTEN TO ME. Forget them for now.

The other bits that aren't obvious are the words 'int', 'string', 'float' and 'bool'. That's in the next section, but you might be able to guess what they mean.

  • So you can see there's two seperate chunks there. Classes are generally seperated into 2 chunks.





First chunk is the attributes of the thing. Which are called "Variables"

Second chunk is what this thing can DO. Which are called "Functions" or "Methods"

  • Attributes are just single bits of information like age, height etc. You can't DO age, you ARE an age, so it's an attribute.

  • For things it can DO it's more like jumping, or breakdancing. People don't ask you 'what's your breakdancing', 'yeah it's 5' pfft. You DO breakdancing, so it goes here.





Likewise a gun shoots and reloads. Both things it can DO, so they'd be methods of a Gun class. Ammo would be a variable, like this

class Gun
 {
     public int ammo;
 
     public void shoot()
     {
     }
     public void reload(int bullets_to_reload)
     {
     }
 }

You might notice that the methods can also have extra information. Since if you do something like jumping you would want to know how high (assuming you were in the army).

  • When designing a game do this excercise every time. Write out an empty skeleton for each class of object you want and think about it's attributes and what it can do. It'll make your code much easier to follow and it'll make you think about the full scope of your project. Plus it makes your code easier to adapt to different idea's. It's shit when you want to change certain ideas but your code is set in stone to another idea.

WHAT

  • Classes neatly package up code into 'objects'
  • Classes have variables and functions. The what am I and the what can I do.
  • Classes can be spawned as many times as you like. e.g So you only need to code our ball once and can then easily have loads of them with little extra code.

WHY

  • Flexability. Easier to change and expand ideas
  • Clarity. Easier to understand and ignore code that you're not concerned with.
  • Easier to fix. Mistakes are easier to track and fix.

WHEN

  • When you need an object that has distinct functionality that logically fits together.
  • When you want more than one object of the same type in the world.

TASK

So, I want you to type out, just in notepad or something, the classes we want for this game. Ball and Platform.

  • Think about the variables/attributes and methods/what it can do and fill in the code the same way I did above. Leave out the odd words for now, but just think about what each might need. You'll get it totally wrong most probably, but it's a good exercise for later when you see what we actually put in.
  • Remember the ball and platform are for this GAME, not nessasaraly what they would have in real life.
  • If you're adventurous you can also do the actual game "class Program" aswell, because everything is basically a class, even the program itself! Sounds a bit Matrixy doesn't it and it's got a more plausable storyline.



Variables

WHAT

  • Basically they use a word to mean something else. The meaning can change but the word stays the same, hence they are 'variable' (genius!)
  • Variables are used to reference something that exists so you don't 'lose' it
  • They can be called anything, don't make the mistake of assuming the name of a variable has a magic meaning. Variables are all dumb and they are all the same deep down.
  • Sometimes they are called 'Fields' in some cases. I'll call them variables because most people do.
  • Variables are used CONSTANTLY.

WHY

  • They are used to store information. e.g. numbers, words, sounds, players etc.
  • They are used to keep track of objects in your world.

WHEN

  • You use variables when you want to store information for later use. 'Information' could mean a number, a word or more abstract things like a 3d mesh or sound, basically ANYTHING that needs to be tagged, stored or referenced.
  • You use variables to pass information around to different parts of your program. eg you might store the health of your character in a variable which other parts of your program can check to see if you're DEAD.

THE CODE



A simple example, see if you can figure out what's happening without explanation.

int firstNumber;
 int secondNumber;
 int answer;
         
 firstNumber = 1;
 secondNumber = 5;
 answer = firstNumber + secondNumber;
  • What will 'answer' equal? Yes you got it right! *pats back patronisingly*, it's 6! whooos a cwever 'iddle programmer..you are! yessss etc

"I understand the last bit, but what's with the first bit?"

WHAT

  • you have to define a variable first. It won't 'contain' or equal anything at this stage. So "int firstNumber;" defines this variable but it's still 'empty' or not pointing to anything useful.
  • 'int'??. You have to tell it what type of variable it is. This goes first, then the name you're giving it. In this case all our variables are integers (whole numbers). After they are defined you can't make them equal ANYTHING other than what you defined them as. eg 'firstNumber' will complain if you set it to equal "CAM!!!". Think square peg in round hole.
  • after you define it you can use it willy nilly without specifying the type of variable that it is (e.g. an integer in this case)


We'll be using these types often, but there are lots of them for specific uses.

'''bool''', true or false. e.g '''bool cam_is_awesome;'''   '''cam_is_awesome = true;'''
 '''int''', an integer or whole number e.g '''4'''
 '''float''', a decimal point number e.g '''3.142'''
 '''string''', a word or character string e.g '''"CAM IS PRETTY"'''

WHY


  • Some languages don't make you define variables by specifying what type of information they can hold. They're shit though, so don't use them. It's more typing but it's basically saving you from yourself. As soon as you accidentally try and make your variables equal something they shouldn't, it'll complain. Otherwise a typo could cost you ages in tracking the mistake down.

e.g. if I tried to make an integer variable equal a word like
 '''firstNumber = "FIT DAMN IT!";'''
 it'll complain when you go to run your program.

WHEN


  • You have to define variables before they are used obviously. WHERE you define them is something for later. For now you can define them just before you use them.

TASK

  • A code preview. Here I declare a few variables. Remember they won't equal anything yet. See if you can figure what I'm doing with our 'Person' class from earlier.

int aNumber;
 string aString;
 Person cam;
 Person some_other_dude;
 Person crowd_member;

Answer: I'm making some empty variables that can hold 'Person's! Just the same way that 'int aNumber' makes a variable that can hold an integer number.

  • All variable types are just classes! Even our homemade 'Person' class can be used when defining new variables. SOMEWHERE 'int' is a class just like our 'Person' class. There's nothing magic going on here. This might do your head in, I can see your veins throbbing, so I'll cover this later.




Basic Functions/Methods


INTRO

Ok I'll quickly cover the basic concept and later do the technical stuff because I can see your eyes glazing over already. SHESH

WHAT


  • Methods are little packets of code. e.g from our 'Person' class we had a 'make_the_tea' method. Cool, so the idea is you would code everything about making tea inside this method (between the { and } braces)

WHY

  • LISTEN because this bit is important. The whole point is that now we can 'call' that method from somewhere else with just it's name and it'll do it!



Imagine in real life I asked you to make some tea, I would say "Chump, make me a cup of tea", you would then naturally obey. I WOULDN'T have to spell out every last detail everytime I wanted a cup of tea. In your brain is the 'method' to follow to make one already.

Here is the method in question

public void make_the_tea(bool milk, bool sugar)
 {
 }

Now to the 'milk' and 'sugar' parts. Making tea never really changes EXCEPT whether people take milk and sugar. SO methods can accept extra infomation at the time they are called.

Calling this method might look like this

make_the_tea(true, false);

Here I call the method telling it that I want milk and no sugar. What it's doing is it's replacing the variables 'milk' and 'sugar' with the information I included when I called it.

The 'make_the_tea' or 'jump' method etc might be huge with 100 lines of code, so imagine, WITHOUT methods, everytime you wanted to jump, you'd have to type those 100 lines over and over again. It would be a NIGHTMARE of typing and errors. I know... because that's how I used to program when I was learning! An example might be if you press the spacebar you can then happily call 'jump()' and it'll do it without knowing HOW it's doing it. Nice and neat.

WHEN


  • When you have a chunk of code that will be used over and over.
  • When you want to hide the annoying details for doing something behind a simple name.


That'll do for now. The real use of methods will be shown later.

Basic Visual Studio use

Ok We're about to finally do some actual code. First I'm going to abbreviate Visual Studio to VS.

First thing we need to do is fire up VS with the empty 'project'.

  • If you have successfully unzipped the 'Wiki guide blank project' you should see 'TheGame.sln' inside the first folder. Double click this (or run Visual Studio first and open it from the file menu like normal)
  • With some luck the righthand side should show the 'Solution Explorer' with some files in it. This is your main view. If it doesn't show it there will be a tab there, click it. If all else fails open it with the top menu 'View->Solution Explorer'
  • The solution explorer is where you add and create new or existing files. VS needs to 'know' about these files so the file list ISN'T just showing you files on the disk like normal explorer. You have to selectively tell VS what files to care about. You can also organise files into directory style sections. It's just for readability really, no real file stuff is going on.
  • Anyway double click 'Program.cs'. This is the main program starting point. It's a Class! Yes even the main program is a class *sound of glass smashing in your head*
  • This class has some predefined methods and variables using a technique to hide those details, so it might not be clear where these magic things were made. That is for the next guide.
  • The main program class is set out like this



class Program
 {
     public override void CreateScene()
     {
     }
     
     bool FrameStarted(FrameEvent evt)
     {
     }
 }

so it has two methods 'CreateScene' and 'FrameStarted' that we can put our code in. I've commented what each does in the code so check it out there.

There is some code there already for setting up a bunch of standard things which you can check out. I've commented most of it. Some of which you won't need to understand for a while

Your code will go under the *** YOUR CODE GOES UNDER HERE *** comment... clear enough? ;)

  • To actually make your code into a working program go to the top menu 'Build->Build Solution'. This will make an actual 'TheGame.exe' file which you can double click to run.
  • Try it NOW! It *should* say 'successful' down the bottom somewhere.
  • Press escape to bail out once it's running.
  • Now go into the normal file directory and run it. It's in 'TheGame->bin->release->TheGame.exe'
  • You'll get a standard OGRE engine graphics card setup box.
    • Select 'Direct3D' from the 'Rendering System' pulldown menu.
    • I recommend setting 'Full screen' to NO while developing. It's easier to quit the game when things go hairy when it's windowed.
    • Change the Video mode if you want (it defaults to super blocky 800x600). Google 'screen resolution' to understand. 1024x768x32bit is a safe bet.
    • Click OK
  • Sweet! A black screen! One for the portfolio!
  • There are quicker ways to run the game from within VS but lets stick to directly running the real exe file for now. You could make a shortcut to it in the quicklaunch bar perhaps (right drag it there)



Making a skeleton program

WHAT

Now we're going to nut out a bunch of empty code to better help organise ourselves.

WHY



When starting a game you CAN just start typing horrid code to get things flying about on screen completely ignoring classes and design and you'll be able to show your friends who'll think "WOW it's nearly finished already! You are SO smart" and your head will be THREE times bigger than it is now. BUT I guarantee you will never finish that game. It'll be a nightmare to expand and you'll start to dry reach at the thought of adding new features. So we're just going to do it right from the get go. It's actually less typing in the long run

WHEN



Well the first thing I do is make a few seperate files for the classes. Luckly our game is pretty simple, but this will give it the flexability to expand really easily later.

THE CODE



Ok first thing is to make 2 new files. If you want to see what the blank class file should look like open 'BlankClass.cs' from the Solution tab on the far right

  • In Visual Studio
  • "solution" tab to the right
  • rightclick on "Program" at the top
  • "add"
  • "new item"
  • In the class name text box enter Ball
  • Click ok



  • One technical thing when you make a new class is to paste this at the top, replacing whatever is there already (above the 'class' bit of code)

using System;
 using System.Collections.Generic;
 using System.Collections;
 using System.Xml;
 using System.Text;
 using Mogre;
 using MogreNewt;
 using Mogre.Cegui;
 using CeguiDotNet;

If you care this just tells Visual Studio that this class is probably going to use someone elses code as well as yours. e.g 'MOgre' is the 3d engine etc.

Now do the same for "Platform"
You should have two new files under the "Program" heading in the solution tab. You can double click these to jump about. Also there are smaller shortcut tabs for all open files across the top.

Your first object on screen - THE BALL

INTRO

Ok you're probably getting pissed about learning stuff and seeing no visible result. Here we'll start by putting a ball on screen. Just for looks, it won't roll about yet.

WHAT



An fully physical object or 'entity' consists of these things.

  • SceneNode. This is a NON VISIBLE anchor point which everything else attaches too.
  • Entity. This is the visible 3d mesh. You know.. the pretty thing
  • Physical body. We can ask the physics engine to push this about realisticaly and everything else such as the Entity will follow.
  • Collision mesh. This is used internally by the physics engine for detecting collisions.
  • A purely visible 3d mesh only needs a SceneNode and an Entity.



WHY

  • "Why can't I just stick stuff on screen ffs?" - because objects rarely consist of just one thing. With scenenodes it's possible to attach anything to them.

e.g A rocket consisting of a rocket shaped '''mesh''', a ''''particle''' effect' for the smoke and a rocket '''sound'''.
 The '''mesh''', '''smoke''' and '''sound''' can '''attach''' to a '''scenenode'''.
 Now you can move just the '''scenenode''' and everything '''attached''' to it moves too.

WHEN


  • Most, but not all objects consist of a scenenode and something attached to it.

Cameras and Lights can exist by themselves with no scenenode. But they CAN still be attached to one for greater control.

THE CODE


Variables

Right, lets get this suck nut on screen. Open up your 'Ball.cs' file in the 'solution' tab and stick this right under the class definition.

Think about what variables and methods you thought would go into the Ball class from earlier.

class Ball
 {
     public Entity theEntity;
     public SceneNode theSceneNode;
     public Body theBody;
     public Collision theCollision;
 }

lol, I bet you had things like 'bounciness', 'shinyness' and 'size', what a |\00b, DER. As you can see I tricked you into thinking the class variables had to correlate to real life, *MUNGGGG*. In computer land you have to be pretty specific and put in things that you wouldn't need to think about in real life. But yes... bounciness and shinyness would go there I SPOSE.

class Ball
 {
     public Entity theEntity;
     public SceneNode theSceneNode;
     public Body theBody;
     public Collision theCollisionMesh;
     public float shinyness;
     public float bounciness;
     public float size;
 }
  • First thing you'll notice is the apparant repetition. There you go NOT LISTENING TO ME again. Remember when you define variables the first word is WHAT the variable can store and the second word is just whatever name that makes sense to you, because you're the one who'll be using it later.
  • I'm naming my variables like 'theEntity' so I don't confuse the poor computer. In other words don't name variables exactly the same as the class/type of that variable. Confusingly enough "Entity entity;" is ok because code is case sensitive. But your puny brain will burst if you do that. Give it a clear name.




So we've gone and defined the variables which we'll need for a kick arse amazing ball. Now if this was a frigging RPG character like an elf or some other bollocks this is where we'd be defining the statistics variables. Like stamina, mana, dexterity... fuckn AURAOFSHOOTINGNESS or whatever pointless crap they have. Balls aren't renound for being especially interesting so we don't need many other variables/attributes like Mr elfie over there (you could give it a health variable if you just couldn't bare the thought of a game with no killing)

Methods

Now onto the methods/functions/'stuff it can DO'.

  • In our game the ball will reposition itself above the platform when you loose. So I think the first method will be called 'respawn'. Remember this is a computer game so some things don't translate too well to real life.

  • One last method is where we're going to do the nitty gitty of setting the ball up. Stuff like loading the 3d model from disk etc. I'm going to call it 'setup' because I'm awesome.



class Ball
 {
     public Entity theEntity;
     public SceneNode theSceneNode;
     public Body theBody;
     public Collision theCollision;
     public float shinyness;
     public float bounciness;
     public float size;
     
     public void setup(SceneManager theSceneManager)
     {
     }
     
     public void respawn()
     {
     }
 }

Ok, it's still empty... we want to SEE something NOW for christ sake.

Change 'setup' to this

class Ball
 {
     public Entity theEntity;
     public SceneNode theSceneNode;
     public Body theBody;
     public Collision theCollision;
     public float shinyness;
     public float bounciness;
     public float size;
     
     public void setup(SceneManager theSceneManager)
     {
         theEntity = theSceneManager.CreateEntity("Ball", "ball.mesh");
         theSceneNode = theSceneManager.RootSceneNode.CreateChildSceneNode();
         theSceneNode.AttachObject(theEntity);
     }
     
     public void respawn()
     {
     }
 }

Now open up 'Program.cs' in the 'solution' tab. Put "Ball theBall;" directly below the 'class' definition. So it looks like this

class Program()
 {
     Ball theBall;

Next find the bit that looks like this

void CreateScene()
 {
 }

and add this code between the { and }. It'll look like this

void CreateScene()
 {
     theBall = new Ball();
     theBall.setup(sceneManager);
 }

haha *points*, are you shitting yourself yet? Because you should be.

Before I explain all that lets run it. Press F5 or use the top most menu 'Debug->Start debugging'
Quick! Run to mummy and show her the pretty ball you made! If it didn't work then... you're fucked, bye. Oh ok, jump to the 'Debugging' section.

Right now you're thinking "holy jesus mary, that was a shitload of work for just THAT. If I have to do that everytime I'm off to play my 387th hour of WoW". Well as I was saying, we're setting up a game here. Once it's setup RIGHT it gets quicker to do things. We COULD have hacked a few lines in and seen the same thing in 2 minutes, but we'd be immediately screwed once we tried to make a decent game out it.

Ok that was a big section so now lets explain what just happened with all the 'SceneManager' stuff.

3D engines - The Scene Manager

INTRO

I'll cover a few extra basics about 3d engines continuing from scenenodes and entities etc. These things aren't magically created. YOU have to tell the computer to do it. This is where the 'sceneManager' comes in.

WHAT

  • Most 3d engines look after their own, so you basically have to 'ask' them to do alot of things. In this case we're asking the 3d engine to create the sceneNode and the entity.
  • The sceneManager creates most graphics related things, like meshes, particle effects, lights, cameras etc
  • The sceneManager is in control of how things like shadows are drawn, most visible things really.

WHY

  • We COULD create these things ourselves but 3d engines are insanely complex. There's LOADS of crazyness going on behind the scenes to get 3d graphics fast enough to run on home computers. To hide all this from our qwivering brains we politely ask the 3d engine to do it for us.

Advanced Variables

INTRO

ADVANCED stuff already? Yes, you're a big kid now, deal with it.

WHAT


  • All sorts of stuff can be assigned to variables, not just simple numbers. Totally abstract things like a 'Person', a sound, an 'Entity' or ANY class you have made yourself!

THE CODE

  • You'll notice a few new things we just added

theEntity = theSceneManager.CreateEntity("Ball", "ball.mesh");

Here we are really doing two things.

  • First we are taking the variable we defined 'theEntity' and making it 'equal' what ever is on the right hand side of the = sign.



theEntity =

Just like 'aNumber = 2' we are about to make 'theEntity' equal... A NEW ENTITY! Get the smelling salts, you're fading!

  • Remember 'theEntity' is an EMPTY VARIABLE at this stage. It's an 'Entity' shaped bucket that we're about to fill with a brand spanking new entity.
  • The second thing this does is it asks the 'sceneManager' to create a brand new entity, consisting of the 3d mesh called 'ball.mesh'. Once it's created the variable happily 'equals' this new Entity.



WHY

  • WHY do we do this? We COULD just create the entity... but then what?? It's like if you were born and never given a name or some way of getting your attention. Imagine you in a room with 100 other nameless people. It'd be INSANE. Asking just you a simple question would be like herding cats.
  • We assign the new entity to the variable 'theEntity' so LATER on we can do things to it. They might be change the texture, play an animation etc etc. KEEP THIS IN MIND, the idea of assigning empty variables to new objects/things for LATER use is VERY important.

WHEN

  • All the time. Even the 'sceneManager' we're dealing with is just a variable! The actual scene manager is like a mafia boss, lurking in the shadows. This variable punk is just his channel of communication.

Logic/making decisions

  • If
  • For and ForEach
  • Do/While

Advanced Classes

<FONT COLOR="#cc6600">sample text</FONT><FONT COLOR="#006600">sample text2</FONT>

Special words you can't use glossary

(called 'keywords')

What to do next

  • You can check out the MOgre website and do their tutes which explain how the Ogre 3d engine works more.



Main MOgre site and specifically MOgre tutorials

  • You can download the full MOgre installer which has various working examples for 3d objects, Gui's, physics etc



Cheat sheets

Programming

  • Variables are a way to store information for later use

usage <class the variable 'is'> <variable name>;
 eg string playerName;
 where 'string' is the 'type' or 'class' this variable is able to contain
  • Functions/Methods are small packets of code to perform... a function! See class 'methods' for an example
  • A class is a container to logically grouped variables/functions/code into 'Objects'. Used in Object Oriented coding.




usage

Class <class name>
 {
     <class variables go here>
 
     public void <class methods/functions>
     {
         <your code>
     }
 }

 eg
 Class Person
 {
     public int age;
     public string name;
     
     public void jump()
     {
     }
     
     public void run()
     {
     }
 }

3d engines/physics


  • To make a visible mesh you need
    • A 'SceneNode'
    • An 'Entity'

  • To make a visible static mesh that can be collided with you need
    • A 'SceneNode'
    • An 'Entity'
    • A physical 'Body'
    • A 'Tree collision' collision mesh

  • To make a visible mesh with moving physics you need
    • A 'SceneNode'
    • An 'Entity'
    • A physical 'Body'
    • A simplified collision mesh (most common in newton is 'Convex')