serious this time

[Schol-R-LEA]

Well, Joey, since you seem set on your course, then, I hope you luck in it. If you want I'm sure that I and the rest here can give you some tutoring in C++ as well - that is what the board is for, after all.

Any questions to start with?

[Joey]

Um, so far I dont think so. Last night I started reading the Game Programming book. Actually, just one thing. I am a little confused with OOP. I kind of understand it, but what does the objects do when you put them in classes? Thats just programming the code for each ememy and stuff in there right? I thought you could do that without it as well. Could someone just explain it simply to me? I half and half understand it. Today I am going to read again and hopefully get to the part where we make our first skeleton app.

thanks for everything.

[Candy]

Um, so far I dont think so. Last night I started reading the Game Programming book. Actually, just one thing. I am a little confused with OOP. I kind of understand it, but what does the objects do when you put them in classes? Thats just programming the code for each ememy and stuff in there right? I thought you could do that without it as well. Could someone just explain it simply to me? I half and half understand it. Today I am going to read again and hopefully get to the part where we make our first skeleton app.

thanks for everything.

Really simple OOP Game programming overview, or, why you might want OOP in your game

Suppose you have a bunch of cars, vehicles, machine guns etc. They all animate, move, be drawn, go off the screen, add extra things in the world (bullet shells? bullets? people) and generally need an update 20 times a second

In C you would find some creative way to signal them all, and make a game loop

In C++ you make an inheritance tree of all the abstract objects with specifics and make an inheritance tree of object dynamics. Now, you create a set, for instance, for the objects in the game. To this set you add a new player, a dozen cars, and 6 machine guns with each 100 bullets.

Now, the game loop becomes something like:

Code: Select all

void Game::GameLoop () {
  set<GameEntity*>::iterator i = gameEntities->begin();
  while (*i) {
    (*i)->doUpdate();
    i++;
  }
  this->drawScreen();
}

for all the updates. Seems simple, right? Now, let's make bullets dynamic:

Code: Select all

void Gun::Fire() {
  Bullet &newBullet;
  Shell &newShell;

  if (bullets == 0) return;
  bullets--;

  newShell = new Shell("up",12, this); // shell goes up from the point of the gun, with speed 12
  newBullet = new Bullet("forward", 300, this); // bullet goes forward from the gun, speed 300. The this-pointer is passed as a reference so the bullet knows from what gun it came

  GlobalWorld::add(newShell);
  GlobalWorld::add(newBullet);
}

And the bullet and shell would be flying around on their own. then, the only thing you'd have to add would be to check whether a flying object hit something, and what they do to each other (if it hits the ground, it stops and is destroyed, if it hits a person, the speed drops 90% and the person is hit). Now, even that can be made easier:

Code: Select all

bool Person::intersectWith(GameObject *object) {
  // function entered when something enters the person
  if (dynamic_cast<Bullet *>(object)) {
    // hit by a bullet, die
    this->die();
  } else if (dynamic_case<Vehicle *>(object)) {
    // hit by a vehicle, fly
    this->setDirection(object->getDirection());
    this->setSpeed(0.9 * object->getSpeed());
    object->setSpeed(0.85 * object->getSpeed());
  }
}

So, if he's hit by a bullet he dies. If he's hit by a vehicle, the vehicle gives him a push. Note that it's still very much clear what's going on, while this would be nearly impossible in C.

Good luck

[edit] really screwed up the game loop.[/edit]

[Schol-R-LEA]

Um, so far I dont think so. Last night I started reading the Game Programming book. Actually, just one thing. I am a little confused with OOP. I kind of understand it, but what does the objects do when you put them in classes? Thats just programming the code for each ememy and stuff in there right? I thought you could do that without it as well. Could someone just explain it simply to me? I half and half understand it. Today I am going to read again and hopefully get to the part where we make our first skeleton app.

I'm not sure I'm following this, but it sounds like you have things a little backwards. Objects aren't put into classes; an object is an instance of a class.

You need to think of classes as a being like types which you define yourself. That is actually what they are, in fact (C had an older method of defining new types, using [tt]typedef[/tt] (EDIT: not deftype), but it is not nearly so general as classes are). When you create a class, what you are creating is a kind of 'master mold' or blueprint for the objects of that class. That way, rather than having to describe each whole object separately, you can define the properties and behavior of a whole group of objects, which then get specified for a given object when the object is declared or modified.

To use a example, let's say you had a class Vehicle. All vehicles have some things in common: they have mass and dimensions, they can move, they can carry one or more passengers (this is really simplified, but you get the idea). So to define a class Vehicle, you would create variables to represent those properties, and functions (called methods) to access and control those properties. So one way of defining a Vehicle class might be:

Code: Select all

// Vehicle.h

class Vehicle
{
private:
   int mass; // approx. mass of vehicle in kilograms
   imt height, width, length;  // approx. maximum dimensions of the vehicle in cm
   Motion_Vector velocity; // assumes the existence of a class Motion_Vector for describing direction and speed
   int carrying_cap;  //  # of passengers it can carry
   int passengers;

public:
   // constructor function - sets all the starting values
   Vehicle(intm ms, int hght, int wght, int len, Motion_Vector starting_velocity, int capacity, int psgnrs);
 
   // destructor - cleans up after a variable is finished
   ~Vehicle();

   // access functions - return the value of the instance variables
   // Since these are defined in the header, they are inline functions
   int Mass() {return mass};
   int Height() {return height};
   int Width() {return width);
   int Length() {retun length};
   Motion_Vector Velocity() {return velocity};

   // change functions - functions for altering the instance variables
   void Enter(int new_passengers) throw (TooManyException);
   void Exit(int leaving_passengers) throw (DangerousExitException); 

   Motion_Vector Accelerate(int acceleration);
   Motion_Vector Turn(Motion_Vector heading);
   Motion_Vector Impact(int opposing_mass, Motion_Vector delta_v);
}

The other functions might be implementing in another source file, like so:

Code: Select all

void Vehicle::Exit(int leaving_passengers) throw (DangerousExitException)
    { 
        passengers = (leaving_passengers >= passengers) ? 0 : passengers - leaving_passengers;
        if(velocity.Speed() != 0) 
          throw DangerousExitException();
    }

(The use of the exception here is purely gratuitous; if you don't know what it means yet, don't worry. Implementation of the remaining functions is left as an excercise )

When you then go to create a Vehicle object, you would use the constructor function

While you could do all of this without classes, or even without structures, using individual variables, classes allow you to design a framework which can be easily reused. Also, but keeping access to the variables restricted, it allows you to have variables and even functions that are completely internal to the class, and prevents certain kinds of mistakes. Classes can be treated as black boxes, just like the predefined types (int, float, char) are.

[Schol-R-LEA]

To continue:

Classes also allow you to group related types together, or conversely, to specialize classes by subclasses. For example, a car is a particular type of vehicle; so if you wanted to describe cars in general, you could create a class Car which is a subclass of Vehicle:

Code: Select all

class Car::Vehicle 
{
private:
  int horsepower;  // maximum engine power

public:
   Car(int ms, int hght, int wght, int len, Motion_Vector starting_velocity, int capacity, int psgnrs, int hp);
}

The Car class would have all the same properties and functions as Vehicle (that is to say, it inherits them from Vehicle), but it would add the horsepower property as well, which could be used in a specialized version of the function Accelerate() to determine the maximum acceleration.

More importantly, a pointer to a class can also point to variables of any of its subclasses, which means that you can use a Car object in any place you have a Vehicle pointer (if you don't know about pointers yet, don't worry; it will be clear soon enough).

HTH. I wrote this in a bout of insomnia, so if I screwed up anything, let me know...

[Schol-R-LEA]

Anyway, the most important thing about objects and classes (or one of the important things at least) is that once a class is defined, you don't need to worry very much about what is inside of the class; you can simply use it as if it were just another standard type. So, let's say you had a Car object, which you want to move around an area:

Code: Select all

#include <car.h>

main()
{
Motion_Vector tmp_vect;
Car kitt(1000, 150, 180, 220, PARKED_NORTH, 2, 600);
Car karr(1000, 150, 180, 220, PARKED_SOUTH, 2, 600);

kitt.Enter(1);            // Michael Knight gets into driver's seat
kitt.Accelerate(88); 
kitt.Turn(SHARP_LEFT);
kitt.Turn(SHARP_LEFT);
kitt.Turn(SHARP_LEFT);
kitt.Turn(SHARP_LEFT);   // back at our starting point, going 88KPH

karr.Accelerate(88);  // uh-oh, collision course
tmp_vect = kitt.Velocity();   // need to keep velocity from before impact

kitt.Impact(karr.Velocity(), 1000);
karr.Impact(tmp_vect, 1000);

kitt.Exit(1);  // a very stunned and woozy Michael gets out
}

Do you see that you don't have to worry too much about how the class works this way, and just use it as if it were just another part of the language? The idea is to abstract away the details, so that you can concentrate on the overll design.

[Joey]

i dont understand any of the code that you typed in. haha, but thats fine i understand how oop works now, and ill get an even better idea once i start making the games in the book to see how everything works. but do you think i should have a knowledge as great as the code you typed in before going through this game programming book? i read the first chapter already which explained steps that should be taken when making a game, and explained a bit of oop. today i will start the 2nd chapter which starts coding a skeleton application. i guess ill see how it goes after today.

[Joey]

also, does anyone know of a good free c++ compiler that I could sell games with if I make one with it? ill try out that dev-c++ for now, but i would want to get really familiar with a compiler by the time i can start making a game that i would be willing to distribute.

[Candy]

i dont understand any of the code that you typed in.

The idea was that this code represents most of the C++ OOP concepts as opposed to doing C programming in C++. On the other hand, we (or at least I) did hope you could read some of the more graphical examples and understand roughly what the code does. These examples are a lot more clear than those in the book where they explain how one theoretical class interacts with another (which is very dry, I can tell you).

haha, but thats fine i understand how oop works now, and ill get an even better idea once i start making the games in the book to see how everything works. but do you think i should have a knowledge as great as the code you typed in before going through this game programming book?

Ehm... I wouldn't expect you to be able to type this code until you finished a CS degree or did a lot of hobbytime programming. Still, being able to read it is a very big plus.

The concepts of OO design:

Every bit of data you have gets its own object.

All objects are of a class, that means, you might have three apples, a pear, a banana and a fruitbox, but they end up being 5 classes even though you get 6 objects. You'd get the general class Fruit (which does not get created, not directly at least), the class Apple, which is a Fruit, and you get 3 apple-objects. Then you have pear, which is a subclass of Fruit, Banana which is another subclass of Fruit, and Fruitbox which is not a fruit, but can contain fruits.

Every bit of data is encapsulated. This seems like pure nonsense at first, why would you make an accessor function for an integer that's right in the class? After a while though, you'll find that that integer needs a new data type, or needs a different handling inside the object. Now you'd be in big trouble with your int accessing functions, but not here. You just make the getX() function use the new method of accessing things.

Objects of the same class (even if the object itself is of a subclass of that class) can all be treated identical, and all functions of that class can be used. The subclass-functions that have the same name automatically get called, so if you want to know how long the pear has until it expires, it doesn't matter whether you call it when you hold it as a fruit, or as a pear, it's got an expiry date, and it's still the same. This is called Polymorphism.

This is the end of the list for me on general C++ concepts.

When you want an object, create it using new. When you want to delete it again, use delete. These functions give you a pointer to the object, that you can use to access it, and pass it around.

When you create an object with new, more happens than meets the eye at first instance. The things that a C programmer would expect is a bit of memory to be gathered. Most C++ programmers see it as a bit of memory being gathered and initialised. In fact, you can customize both the gathering as well as the initialisation. The first is a little out of the ordinary, but for some things (such as an always-present judge, of which there may only be one) it's useful. The second means, that each time you create an object for a class, you can put things in it that you want to put in there. You actually can make a parameter list for all the things you want to know, and then create an object accordingly.
<cut because the forum whined again>

[Candy]

</cut>
To start you off, a very basic class:

Code: Select all

class Basic {
  public:
    Basic(int i);
    ~Basic();
  private:
    int i;
};

Now, let's see what it has. It is called Basic. The object has a number of public functions (everything under the public: keyword until the next keyword is public) that you can use from any place. It has a number of private parts (which you cannot touch of course).

You can create a Basic object by calling

Code: Select all

Basic *object = new Basic(123);

. This Basic object has been allocated the right amount of memory (the compiler decides how large it needs to be and allocates enough) and the Basic(int i) function has been called. Since it's public, you can call it from anywhere.

The function Basic(int i) is called a Constructor. It constructs an object from the arguments it gets.

The function ~Basic() is called a Destructor. It destructs the object it is called on (say, an apple is in a fruitbox. The apple knows it's in the fruitbox, and the fruitbox has the apple in its inventory. When you delete the apple, it can let the fruitbox know it's gone, and you can put these associations in the destructor for deletion).

The constructor and destructor have the special property that you should not call them directly. You can of course (I had to try!) but you should not. They are called automatically. The constructor is called when you've made an object with New, after the memory is allocated (so you can put things in it), but before it is returned (so it's not in use at the moment you execute the constructor). The destructor is called when you destroy an object with Delete, before the memory is deallocated. You can still use everything in the object, and do virtually anything you like.

Hope to have given an understandable & nice C++ intro here...

[Candy]

also, does anyone know of a good free c++ compiler that I could sell games with if I make one with it? ill try out that dev-c++ for now, but i would want to get really familiar with a compiler by the time i can start making a game that i would be willing to distribute.

Well, I think you can with dev-c++. Dev-c++ is only the environment, and they want to make it generate non-GPL programs. It uses GCC, which you can use for non-gpl software, and it uses the libraries, which have special software so you don't need the GPL. Just use it, the authors are on your side concerning GPL not being forced upon you.

[ark]

Without knowing what that game programming book is telling you and how many C++ language features you are already comfortable with (since you said you know "a little C++"), it's hard to say whether you should take a step back or not. It depends greatly on where the book you're learning from is going in the next few chapters.

Regardless, the only I advice I can give is avoid the "C first" method of learning C++. There are higher-level and easier-to-use constructs for a lot of things that C does.

Incidentally, the constructor and destructor get called whenever an object is created or destroyed, not just when you use new and delete. With the class definition:

Code: Select all

class X
{
public:
    X() { y = 5; }
private:
    int y;
};

the constructor is called in both of the following lines of code:

Code: Select all

X x;
X* px = new X;

For x, the destructor is called when x goes out of scope. For px, the destructor is not called until you explicitly delete px.

[Joey]

ok cool. well today i have guitar lessons at 4, so when i get back, ill try and finish chapter 2 around 5 o clock. what i am going to do though, is if i dont fully understand everything from chapter 2, im going to read it over and over until everything sinks in and i understand it. i will do this with all the chapters so i really understand it. hopefully, i can finally learn c++, although it will take months, it will be well worth it i hope.

[Joey]

just a little update for those of you who have been reading this thread.


i finished the second chapter, and even though its early to say this, i think things are coming a long good. there was a lot discussed in this chapter, and i read a few things over and over until i got a better understanding of it. then we developed a basic skeleton application. he said (the author of the book stated in the book that): there was a lot thrown at me right away, and i dont have to have much of an understanding of it. he just wanted to show me how a windows program worked. after i compiled and ran the program, it worked like it should, but i decided to go a step further. i re read the source to get a better understanding of it, and then i tried editing a few things and observing the changes it created. most of the things i edited, i knew what i was editing. i was able to change the name of the window, the text inside the window, and the background color. i tried changing the cursor, but i got a message about it not being declared, so i just left that alone because i wasnt expecting myself to be able to do that yet.

so so far i think its coming along good, and hopefully the rest of the book will. thanks everyone for your input, and if i ever have questions i will post them.

one more thing, after finishing this book, i wont really know c++ will I? I will only be able to create a few games. I wont really be able to design applications and stuff like a text editor or things like that will I? I would have to read more books to learn more code i presume, but im not quite sure.

[Schol-R-LEA]

one more thing, after finishing this book, i wont really know c++ will I? I will only be able to create a few games. I wont really be able to design applications and stuff like a text editor or things like that will I? I would have to read more books to learn more code i presume, but im not quite sure.

I suppose it depends on what the book covers, really. Which of the books are you using, anyway?