Hi everybody...
I am looking for a tutorial on how to make a game...not the programing...I looking for the concepts...for example..
I make the scroll of my game creating a variable CameraX and then adding each time you press the right button...
Then all I draw..tilemaps, enemy, etc... I subtract they x value from CameraX..

It works..but when i start to put enemies to stage it becomes dificult and my program become a really mess...:P
All I want is some concepts of things like...To scroll I create a object Camera or make the variables in the player object....There is another way better to scroll??
Things like that would help me a lot...

It sounds to me like your problem is just organizing data and code. Perhaps what you are looking for is object-oriented programming? Perhaps you're looking for something like this to clean the code up:

renderer.render(player, camera);
renderer.render(enemy1, camera);
renderer.render(enemy2, camera);

Otherwise, I'm afraid that I don't understand what you're asking.

I think what she's (?) asking is how to make a game, she's got the C/C++ language and Allegro API down, but what's next?

@Gabriel Campos:
It would help if you told us what kind of game you're making, I'm guessing a side scroller of some type? Do you have some commercial game in mind to emulate?

Gabriel is a male name.

So why did he pick a hot chick for his avatar?

[EDIT]

Upon zooming way in to the image, I guess it could be a guy... a great big ODARN echos through the trailer park!

If you think that's a hot chick, then so be it. I'm not going to question your tastes.

On-topic: Gabriel, there are quite a lot of tutorials on the net depending on the genre you're looking for. I remember finding once a tutorial for a 2D map style like the old JRPGs(think SNES), and it was specific to Allegro as well. These are quite helpful in opening up more room for thinking and creating new, different engines. In the end, it all comes down to your creativity in doing an engine that can be maintained, that is efficient, and flexible. And that it doesn't give you a headache when coding.

Hot is debatable, but it's definitely a chick.

Looks like a male FF character to me.

What is a mess? The code? Or does the game not render correctly?

Here's the article I was talking about.

The Beginners Guide to RPG's in Allegro and C/C++

The size of the head seems to steer it into the "chick" side, though with the FF style, you never know.

it's a bloke, I think:
http://en.wikipedia.org/wiki/Sephiroth_%28Final_Fantasy%29

ah, yes

{"name":"sephiroth.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/e\/fe29d8fa7ec9d9abc59a03c66f76c1a8.jpg","w":432,"h":405,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/e\/fe29d8fa7ec9d9abc59a03c66f76c1a8"}

Indeed, it's Sephiroth:

EDIT: Ninjad!

EDIT: Ok, so what does this tell us regarding gnolam and Arthur?

I must state that I know nothing of Final Fantasy, I just found it here, which was really quite good I thought:

http://www.tineye.com/

and pointed it at the forum static image.

And I selected the Sephiroth string and right-clicked to "Search Google" then selected Images.

http://www.youtube.com/watch?v=rxOMOKqEOVc

That we're not anime-damaged enough to view ladyboys as male?

Swift escape. At least you didn't call him hot. Though in my defense, I based myself on the fact that the name is common for males on Latin America.

Ok, enough off-topic for now.

Well...Its Sephiroth from Final Fantasy...I will change later:P;D
(*thinking* They program games and dont know final fantasy?::))
I will try to be more clear . . .
I am making a platform game...a megaman game..
the link for my game. . .
http://www.4shared.com/file/jfK0vjFo/MEGAMAN.html
A = shoot (hold to charge)
Z = jump
ESC = exit game

I have a good knowledge in c++ and allegro... This is some codes from my game...

Basiclly this is my code and I use in this manner for the other objects like enemies, etc...

My problems starts here when I start to put more objects in the game...
Because I have to check the position of the objects adding (enemy.x - Player.CameraX) . its become a mess . .
I know I need to learn more OOP so i am asking a light in this point . .
I want to know things like:

Its better to create on cPlayer a variable CameraX or create a object / class called cCamera?
If create a object Camera how to make the other objects like player to recognize it?? I tryed to create a pointer in the constructor of the player but doesnt work

Whats the better way to scroll??
Well, things like that ...Will help a lot me and begginers too..

Certainly a Camera should be a single object IMO.

Your code snippet doesn't look wrong there, I'd say that you're not passing the pointer properly.

But IMO, the key is that maybe the objects shouldn't render themselves to the screen, but actually let a "Renderer" object handle it. That way, you can make different "displays" based on the same world.

I guess your camera class should handle that.

EDIT:

FF7, no. I know about the character, but I couldn't recognize it at first sight on your avatar.

Hmmm....
But I will pass the objects in parameters??

But how I define the Renderer class??

I always have a class Object as a base class for every object that has to be drawn, and have it have at least one virtual function: virtual void draw();
Then, I have a vector of Object pointers to all objects. The drawing code looks like this:

for(int i = 0; i<objectsvector.length(); i++)
{
    Renderer.render(objectsvector[i],&Camera);
}

And in the render function:

void cRenderer::render(Object* object, cCamera* camera)
{
    masked_blit(object->getSprite(), Buffer, object->getFrame()*object->getW(), object->getStance()*object->getH(), object->getX - camera->getX, object->getY - camera->getY(), object->getW(), object->getH());
};

you will have to make getW,getH,getY,getX,getSprite,... virtual members of Object as well.

No need to change it.

<------ Ahem.

I would create a camera class. I would probably just name it Camera though. Assuming the 'c' stands for "class", it is a useless prefix that won't add anything useful to the game. If you need more than one camera type then use namespaces to organize them or give them more descriptive names.

As Dario ff pointed out, I would probably not let the player class know about the camera class. Let the camera be managed separately.

class cRenderer{
     
   void Render( /* what parameters here??? */);

Rather than passing pointers, you might as well pass references. You might do something like this:

If you're comfortable with inheritance and polymorphism then you could do as J-Gamer suggested and create an IDrawable interface and just make your Player class and Enemy class and other drawable classes implement that interface. That way you should be able to easily draw anything that supports the drawing logic implemented.

That picture of Sephiroth isn't from the game of FF7...thank Yevon for that.

It's from the FFVII: Advent Children promotional materials. IIRC, I think that I used that very picture of Sephiroth as my A.cc avatar back when I joined in 2006... Prior to switching to Cloud for long forgotten reasons.

Here's a direct link to the original wallpaper from the official [English] site: http://na.square-enix.com/dvd/ff7ac/wallpapers/wp1-1.jpg

I think the way of J-Gamer show the solution is very good . . .and will help me with other things too..like drawing by the Depth.
So, lets see...

Is this the way correct??
I dont understood why J-Gamer said to use a virtual void draw();
Is really necessary??

I haven't read the thread, but he's probably referring to polymorphism, i.e. loose coupling is king.

It means you can have lots of sub-classes but still have call draw() called correctly when using the base class, e.g. assuming Sprite1 and Sprite2 were inherited from Object, then:

void MyGreatFunction(Object* a)
{
a->draw();
}

if not using virtual then Object::draw would be called. If using virtual then the correct ones are. The drawback is a slight overhead in determining the correct method to call.

I think that J-Gamer starting giving one suggestion and ended up giving a better one. Ignore the part about the draw method. Game objects generally shouldn't know how to draw themselves (they should have no concept of a screen, etc.). A third-party, like the Renderer concept should know how to draw all objects. It's the getSprite or getFrame method that you'll want to be virtual (and likely abstract AKA pure virtual) in the base class.

Did I?

I always have a draw() method in each game object. Those functions mostly take (BITMAP* buffer,float x,float y) as parameters. I do it this way, because e.g. my spacecraft has to be drawn in different ways according to a frame and mode variable within the spaceship class.

Well, at least you were able to identify that your code looks ugly. That's an important step. Now you just need a decade or so of experience and you might be able to write some decent code.

So lets see if I understand . . .

I must have a class cObject, a class cRenderer . . .

Now my last doubt(I think) . .
First, is this code correct?
And, where I put the virtual draw??
in the class cObject, in the class cRenderer or in the other classes (player, hud, enemy)??:-/

You're mixing up two concepts here... You can do it by putting a virtual draw function in the cObject class, and making all classes like player,hud,enemy,... members of it with their own non-virtual draw that draws them. OR, you can have a cRenderer class draw function that checks all Objects for their type and draws them accordingly. In the latter, you have all drawing code in the cRenderer class, whereas in the former, you have the corresponding drawing code specified in each of the classes.

Out of curiosity, what kinds of things vary based on the "frame" and "mode"?

Most of the time: which of the bitmaps in the different sequences are drawn.

I have e.g.: a flying mode, propulsion mode, explosion mode, vanish mode, etc.
For the flying mode, nothing special, just a plain spaceship sprite.
Propulsion mode: increase frame, draw corresponding bitmap in the propulsion sequence
Explosion: idem as propulsion, except it doesn't loop trough the sequence.
vanish mode: get smaller and smaller, according to the frame(amount of frames is set beforehand)

I think you should be able to accomplish all of those with an animation class and possibly a separate interface for spaceship position vs. spaceship sprite position (if those aren't always the same as the position).

The getSprite(gameTime) or getFrame(gameTime) method should return an appropriate sprite for the given mode/animation/game time. That way the actual drawing can be handled by a single rendering class and the differences in what are drawn get returned by the individual objects (preferably managed by another class under the surface, like an animation class, if non-trivial). This way your objects don't need to know anything about the drawing surface, or how to be drawn at all. They only store the data that is their state (including the visual and audio representation) and separate service objects, like our renderer, determine what to do with that data.

I remember about 15 years ago when I first got started into game coding (at that point I thought there was something magical and complicated about how you display moving things, not knowing it was just a case of blanking the screen and drawing stuff elsewhere), I wondered whether when a player picked up an item and moved with it, whether I had to have a graphic with the player and the item and thought this will take a lot of graphics

/me thinks bamccaig is falling into the OO/C++ trap of overcomplicated, overengineered patterned designs...

That might be what it sounds like, but in actuality it's simplifying the design instead of complicating it. Instead of making 20 different redundant calls to blit or al_draw_bitmap or whatever, you make one (or a handful) and everything else just works the same way. Your objects have a visual state and another external class knows how to draw that state (but knows nothing of specific types, like spaceships or moonmen or whathaveyou). It's actually a lot simpler of a design, but it requires a bit of forethought.

Depends. Every post you come up with more and more complicated patterns to add, for a BEGINNER.

And no, it isn't simpler.

It's more complicated language-wise because you need to understand polymorphism, but the solution is simpler than redundantly duplicating the same basic logic over and over again. IIRC, the OP said he was knowledgeable in C++. At least, he seems comfortable enough to be introduced to/reminded of polymorphism and its benefits.

And a crap ton of new "design patterns". I'm not against a little polymprphosm, but springing a bunch of fancy design patterns on a newbie is silly in the extreme.

Just my oppinion, but if you haven't been introduced to Polymorphism, you aren't comfortable with C++, and you probably aren't ready for most of the fancy design patterns you are suggesting

You don't need design patterns to use polymorphism, and there aren't any design patterns being used here...

All it is is inheritance, to replicate an interface for different classes, so they can be used interchangeably through a base class pointer.

I was talking about some of the stuff bamccaig was proposing. Fancy adapters and MVC...

Good use of polymorphism as I said above helps you with loose coupling. What's worse - having a bit of thought before you write your code, or turning your code into spaghetti within a few weeks with either 30 case statements in a method or 10 methods that do the same thing but slightly different and having to remember what they all are?

I agree design patterns can be bad in the wrong hands and they do over-complicate things, but where it's relevant it makes things better. For example, most people end up coding using the Strategy, Adapter and Facade pattern without even realising it.

Ok, lets some code:

Please, help me...I am learning a lot here...

if you have sprites then a good idea is to let the renderer class handle it.just make a spriteholder class(basically a class with a map/list/vector<string,Sprite*> of all the Sprites in your level or even the whole game though it's not advised) and whenever you instantiate a sprite you register it(insert it) in the sprite holder('s map/list/vector).so in the game loop the first thing you do is call the renderer and have it blit everything visible on the screen and afterward do every other calculation to change the state of the game,player,character etc so that in the next loop the renderer has all the updated info on the sprites including the new destination point and possibly another frame of the same film.

i'm currently taking a course in my uni for 2D bitmapped games and this is the way we are doing it.it's simple enough imo.then again it might not fit in this situation,i didn't really see the code but it's a good concept to know.and you don't need to implement any design patterns.

This is my take:
(I renamed cObject to cSprite because the name Object can cause a lot of confusion in c++.)

I didn't want to make this too complex, but note that the sprites will be displayed in the order of the collection (vector) : last ones are "above".
In my own games, Sprite has a member called Priority, and I build a collection for displaying (I omit the invisible sprites at this step) then I sort this collection by Priority, before browsing it to call Draw().

you have to have priority given one way or the other if you want your characters to be able to go behind graphics as well.
this is called z-ordering.where each priority value represents something like a layer of graphics.where the layer with the lowest priority is the background,the next priority is anything else static or not that you always want your character or other characters to pass in front of,then it's your player's character with any other characters/enemies and stuff and then the highest priority is the layer with all graphics that you want your character or others to pass behind of.this is just an example nothing more.you can have more or less layers depending on what you want to do.

and principally Audric's solution is the same as what i said.

ehh... I didn't know virtual functions cause overhead... BTW, what is overhead exactly(srr for the noobish question)

@bamccaig:
I always have the drawing code in a draw function in each class that is to be displayed on screen. It's easier to debug them because you know where to find the exact drawing code your looking for. In a cRenderer that checks the type etc, you'll have a LOT of get-functions, so you'll have to put all those in the classes as well. As you're looping trough an array of objects, the get-functions need to be declared in the object functions, but not all objects share the same properties. E.g.: a spaceship needs multiple bitmap vectors/arrays to store different animation sequences. a black hole/planet only needs one bitmap.
Because of this, you could have a virtual getcurrentbitmap() function or something like that in the object class, but that would completely destroy the purpose of an external renderer. You can as well have a draw function in your class.
In my case, the only purpose of a renderer is to sort the objects by depth and move the drawing calls out of your main loop, to avoid messy code.

overhead is a term to describe the excess work that the CPU or any other part of the pc has to do when given a difficult task.for example if you call too many functions then you get an overhead in the call stack.you make too many records of function calls when you could have made less to attain the same goal.another example of overhead is polling.before interrupts where implemented the CPU had to poll the hard disk to see if a transaction had ended thus having to queue many other processes and perform context switches all the time just to make sure the transaction of a data transfer was completed.then interrupts came and then DMA.when a data transfer needs to be done it is approved and started and then DMA manages it until it's finished without having the CPU involved.

And virtual functions cause a little overhead because every object uses late binding to determine which function to use,that of the super class or the derived.but i don't think it's such an overhead to even be mentioned.i mean with today's hardware and all the object oriented programs in c++ lying around and very often well known ones at that you can see it doesn't pose a problem.

I'd say overhead is best described by the computer doing at runtime with brute force what you were too lazy to do with your brain at program design time.

i hadn't thought of it like that....interesting .

The very slight overhead with virtual methods is because the program has to lookup the function in a vtable at run-time (every time the method is called using a pointer or reference). It's this very mechanism that allows inheritance and polymorphism. Nearly every language that supports these concepts will implement it in a similar way. It's nothing to be concerned about. It will almost never be a bottleneck in your code.

@J-Gamer: /me is writing an example program. It's nearly 500 lines and counting, but that initial overhead should be outweighed by the code reuse later on (in a real game, when there's many different types of objects to be drawn). I think all I should have to do now is A5 stuff (initializing A5, loading some bitmaps, etc.). Well, and then debug it.

Hmmmm be careful that "each instance of a spaceship" doesn't need it.

For small games, you should load such bitmaps once, on startup, and release them once, when quitting program.

Putting them as static members of each game object's class isn't an universal solution either : It prevents you from having several game elements that "share" the same image: For example a "computer-controlled allied ship" that needs the same sprites as the player ship.

I think the Speed game included in the latest Allegro 5 releases demonstrates well a situation where you render the same objects in different ways:

While the Speed game is pure C, it uses different "view" structures for rendering the same game objects.

You don't want to include a parameter for the cObject in cObject::Draw because it is already there in the hidden 'this' parameter.

Note that cPlayer::Draw() is not derived from your virtual cObject::Draw(cObject* Object , cCamera* Camera) function. They have two different function signatures. You're overloading the name, but not the function. The function signature of your Draw function in CPlayer should match the function signature of Draw in the cObject base class :

class Base {
...
   virtual void Function(int x);
}

class Derived : public Base {
...
   void Function(int x);// correct, function signatures match
   void Function();// incorrect, function signatures are different
}

You might want to take a look at the cplusplus.com tutorial, or the section on polymorphism.

I kept it all in one file to keep it simple on the forum, but I would put each class in its own header and source file for real. The actual main program stuff is hacked in and hard coded, but the polymorphic API is what matters anyway. Sadly, I have noticed one annoying shortcoming of my particular implementation. The player has dynamic dimensions. In order to retrieve them you need to query the current animation for the current frame, which requires the current animation to be set and started, and therefore requires game time as well. It's a little bit heavy doing all of that to determine the width and height, but one could always code static dimensions if they needed it to be cheaper/easier. The only reason I really needed it was to center the "player" on the screen for aesthetic reasons. I was able to get it done with prior knowledge anyway.

The code is pretty long. I counted 745 lines using wc. It's obviously a lot of overhead for what little it accomplishes in this simple example, but the code is reusable now. You can create n different types of objects that follow these same interfaces. It should save a lot of code, though you may find the interfaces need revision to deal with cases that I haven't accounted for.

The program mostly just dumps errors and exits if anything goes wrong, but it doesn't have to. It's built using RAII types and exception handling, so in theory it should be easy to handle errors gracefully (as can be seen in the drawing section of the main loop). I will say this: it's a lot easier to write this sort of code using Allegro 5 than it was with Allegro 4. Intern's Quest^[1] wasn't designed as well as this from the start (though I learned a lot from it that lead me to here). That aside, it was still a lot more difficult to write because of all of the global state in Allegro 4 that we had to try to wrap and work around. With Allegro 5 there's less global state to deal with, and the global state that you are stuck with is already neatly hidden beneath interfaces. If I wore hats I would take one of them off to honor the developers!

Teh Codez

(A.cc seems to be wrongly counting my post as 90 KB long, when in fact it's only 19 KB long, so I'm forced to attach the code and link to it instead of inlining it, which would have been a much more convenient way to read it IMHO, but I digress)

           (see below)

that --> al5polytut.tar.gz <-- that

            ^ this

The following QnD GNU Makefile was used during the development of this demonstration and could be used to build it given a compatible platform.

If you're on an incompatible platform then you'll just need to know how to compile a single C++ source file and link to the core of Allegro 5.

Meh. This is the way that I like to code. It's more fun for me, but then I've never finished a game... I also find it a lot easier to work with though. It's a lot less error prone because you're writing once instead of writing over and over again.

The code could still use revision, but I think it's a pretty good start. If anybody actually finds it useful enough to use directly in a game then I would appreciate a mention in any credits or whatever, but I'm not going to demand it.

Update: moving camera now so you can see it working.

So, if a I understand i can do this

Sorry if I am wrong...I am studying and trying to learn...is a bit dificulty
Thanx for the advice of the virtual function...so it must be exactlly equal to the derived classes functions...and thanx to the site..very good...
I am working now , in home I will read with attention . ..

When writing a class method, you don't need to use the this pointer to refer to data members, but you can if it helps you keep your code straight. You probably don't want to hardcode Buffer into your classes either, but use a parameter for the bitmap to draw to.

Isn't it also better to have the x and y variables of cCamera private? This to prevent accidental changes of these values. Just have a getX() and getY() function in the class.

With accidental changes, I mean like looking over something like this:
if(camera.y=0)
instead of
if(camera.y==0)
If they're private, the compiler will throw an error here... If not, each time this if-statement is called, the code underneath will execute and camera.y will be set to 0.

I had this problem a lot when learning C++ after I had been programming in a BASIC language for a long time.

It counts the actual size of the post-processed contents, after its done transforming bb-code and <code> tags, and highlighting code causes the size to bloat up significantly.

J-Gamer: use the -Wall option of gcc to get warnings on all suspicious code, and it will warn you on each "if (x=y)".

My Solution:

This is the solution I liked...Suggestions will be very apreciate..
But I still have doubts...
I create a vector and doesnt work...

The compiler says that vector SpriteObjects has no member named length();
If I use .size(), .capacity(), it accepts....but not length()..
I use allegro 4.2 and DevC++...
Someone???

That's because std::vector doesn't have a length() member function. The one you're after is size().

Ok..but when a put size it doesnt draw anything on screen...
Sorry if I am making a topic too long...
What is the problem with my logic??

You're either showing us parts of your program or you're forgetting to actually initialize your objects and draw to the screen. If you're still having issues, show us the full program.

Also: the code you're giving us shouldn't even compile...

masked_blit(Sprite[Object->GetImage()], Buffer, Object->GetFrame() * Object->GetW(); Object->GetStance() * Object->GetH(); Object->GetX() - Camera->GetX(); Object->GetY() - Camera->GetY(); Object->GetW(), Object->GetH());

Why?? I couldnt realize . . .
I make all functions of get() virtual....

well,
I will try later in home...If doesnt work i will post here . .

I didn't know that... thanks
But I think it's still better to make them private, just for OOP's sake

I hope you don't think this is a dynamic array... You need to replace the x by a hard-coded number, OR you should make it a vector/list/deque/whatever to let it be able to have a costumable size.

What is this supposed to do? In this case, Object->GetImage should return the index in the Sprite array of the current sprite that should be drawn... This makes code from the object to change when the order of the sprites in the Sprite array changes...

When I wrote BITMAP *Sprite[x], x will be the number of all sprites..Lets supose that we will use 10 enemies + 1 player...will be 11 sprites, so

So when I create a object...lets supose...Player I will refer his sprite with the number of this array...
if Sprite[0] = load_bitmap("Data\\Gfx\\Player.bmp", NULL);
then the variable Image will be 0....
when the class call Sprite[Object->GetImage()], it will return the number of the image, in this case 0..

Maybe because I wrote
virtual VOID GetX()???
I think it is
virtual INT GetX() . . . Always do it...My compiler is working hard you know

When compiling, the compiler wants to know how much memory it should allocate for each instance of a class... this means that when using an array, it needs to know the size on beforehand. This way, you can't do this:

BITMAP *Sprite[11];
//then load all bitmaps
Sprite[0] = load_bitmap(.......);
...
...
...

In a constructor/initialisation function because the amount of bitmaps in the array sprite is set to x, for which the compiler will throw an error if it can't find an int called x that is already been given a value(it has to be global to do this, somebody please correct me if I'm wrong).

This means that the Object needs to know which location the image to be drawn has in the Sprite array(which is in another class)...

J-Gamer: Just use the <quote> </quote> tags without specifying anything and the a.cc's magic searching bunnies will do the work for you.

Example:
<quote>When compiling, the compiler wants to know how much memory it should allocate for each instance of a class...</quote>

Thanks... I was wondering how you guys all do that :p
Edited the quotes in the previous message

You dont understand me...I will put explicit the number 11...the x is not a variable or a parameter or nothing...it was just a example....
When using Object->GetImage()...it will return the number...its simple..

Simple...

Could somebody please explain to me why the getImage() function is a function returning an int and is part of the class cObject, while it is giving the index of an image in an array of the class cDrawManager?

This would mean the cObject class should be aware of the contents of the cDrawManager's Sprite array.

acc.js

That's not necessarily true. Think of file descriptors. A file descriptor is basically an index into some table that the kernel has for an application. That's why STDIN, STDOUT, and STDERR are 0, 1, and 2, respectively. Your application doesn't actually know anything about that table, and couldn't get access to it if it did.

The object doesn't actually need to know what the image index refers to because (presumably) it will be passed in and set from the outside world by something that does know. Using indexes like that for your sprites isn't a terrible idea, but there are better ways to do it, especially in C++. For example, you could store boost::shared_ptr<BITMAP> and then store a copy of the sprite's smart pointer directly in your class. You could even load your sprites into a std::map<std::string, boost::shared_ptr<BITMAP> > so that you could later refer to them by name. That's generally how I have done it.

I dunno, if you treat the "index" as an opaque "bitmap id", rather than an index then you can change the underlying implementation at any time and not have to worry about passing pointers around, or using string based hashing.

I was actually talking about how to be able to copy both the text AND the link to the specific post ^^

I haven't studied Java yet, so I don't really understand the code ._.
I might look into it later, when I have some spare time to learn Java.

In the code we get to see, it's clear that he wants the function to know which number to return, probably based on some state parameters of the object itself.
I have to say I never used Boost, so I don't know how it works.

The forum auto links it most times.

That's actually specifically what it can do. Though it isn't perfect: it doesn't handle HTML properly [yet]. When it fails to quote, you can use a separate feature to just fill in the <quote name="user" src="uri"></quote> part though.

It's JavaScript, not Java. They are two completely different languages with little in common. In theory, you should be able to just drop it in and use it, but in practice having some JavaScript experience would come in handy because it isn't perfect. (ML also discourages its use because he doesn't want people abusing its convenience)

The object would just store its sprite index, or an animation, which itself would contain a set of indexes. That would be part of the object's state. The object doesn't physically need to know what those indexes mean. It can trust the outside world to give it the right indexes. Of course, it's not a perfect model, but it can work if you're careful.

A better model is probably storing an animation or a set of animations, each of which containing a set of smarter pointers to your sprites. That's a relatively complicated model though for beginner.

Boost is a very large C++ framework. The boost::shared_ptr<T> is a smart pointer that manages the memory for you automatically. Essentially, it just stores a copy-count/reference-count internally. When you make copies of it the count is incremented, and when those copies are destroyed the count is decremented. When the count reaches zero, the stored object is automatically destroyed, freeing the memory. It's entirely automatic.

It's a bit like garbage collection, except that it works immediately instead of waiting some indeterminate amount of time and checking for objects that can be freed. The downside is that it can't handle cyclical references, so you do need to pay some attention if you end up creating those.

I was referring to the semicolons.

I should have know that at least...

Oh..yes, I dont realized...
The function works nicely after I declared pure virtual...
if dont it says..undefined reference to vtable in cObject..or something like this...
Strange . ..

It's because every function you declare has to also be defined. Also, you should note that every base class that has virtual functions should also have a virtual destructor. This is so that the appropriate destructors get called for the derived classes.

/// In Base.hpp

class Base {
protected :
   Data d;
public :
   Base() : d() {}
   virtual ~Base() {}
   virtual void DoSomething();
};

/// In Base.cpp

void Base::DoSomething() {/*...*/}

But why to put in the destructor??
I couldnt understand this part of the code

Other thing I want to learn is..why use this implementation on the constructor code of some object, something like player..

I want to thanx evebody too.. Since this post I learned a lot about OOP..

Data is just a made up class, used for an example.

The code in the constructor after the semicolon and before the braces is called an initialization list. It gives the member variables of the class an initialization value. Always initialize the members of the class before using them. If you don't, then their starting values are undefined, and hold the value of whatever was left over in memory from before.

An example of what not to do :

Data::Data() {
   printf("i = %i , f = %f , c = %c" , i , f , c);// Could print anything
                                                  // because i , f , and c are
                                                  // uninitialized
}

Well, couldnt understand yet...But I got a c++ book from a good university here, so I will study all this part. . .
But lets go to another game concept question, How to make a lot of stages and add enemies there.. My solution is this, but I think its a little weird..

So, this is the right way to do this??
Or should create all objects, lets say..make them global... and use it??
Create a method to put them in the right stage and position??

I would use something like this. You can set up the current stage in the CreateStage function, and then just run the current stage in main.

Hmm... So you are telling me to make all the game in a class and there make a system to load the maps and the enemies..??
So in the main function I only call the functions of this class...But I make my map based on tiles... I will look more detailed this in home..thanx