# Game Code Structure & Stitching It All Together

## Recommended Posts

In designing my sprite class today I realized why I am a lousy programmer. If you give me any one basic concept, I can program it. Physics? You need to know what effect gravity would have on your game character after it jumps? I can program a simple function to calculate the change in Y position. That's easy. I can make a function that calculates the angle at which a ball bounces off of a surface. No problem! Graphics? I can blit a sprite, I can draw a triangle. Collision detection? I can tell if objects on the screen are overlapping. The problem I get is when I have to stitch it all together in a game! I had originally intended to design a sprite class that did everything. A sprite object would know what it was, where it was going, what AI state it was in, what frame of animation it was in, how fast it was moving, how fast it was accelerating, and whether it was colliding with any objects. I would then have a singly-linked list that the program would traverse several times with each frame so that it could decide what changes to make in all of these values and then what to draw! But if you remember by thread on this topic, you'll remember that most people found I was going at this the wrong way. A sprite object should know what to draw and that's it. Any movement data should be stored somewhere else - perhaps a game object (WTF) or some sort of sprite manager. This is something I had not previously thought of, and is a totally new concept to me. And to tell you the truth it still confuses me. I can see how having this sprite data spread across different classes, and therefore different objects, makes the code more flexable and reusable, but it certainly seems to complicate things! I spend so much time worrying about details like physics and AI and collision detection -- of which there is a WEALTH of information online -- I have never given any thought about how to stitch these concepts into a working game. It may be trivial for many of you, but to me it is a total mystery and it's a topic I don't think is written about very much (from what I can see). What should I do about physics, for example? Should I just write my own all-encompassing physics library that contains all of the functions that I think I would need and include it in my project? Or should these functions be methods in an "entity" class of some kind? I would hate to reinvent the wheel -- I mean I'm talking about Super Mario Bros.-type games here, not Half-Life 2. This stuff has been done a thousand times. On the other hand, though, I would hate to have this knowledge "handed" to me and so maybe reinventing the wheel myself would be a good experience. I've gotten this far without any sort of formal teaching, but I have a long, long way to go.

#### Share this post

##### Share on other sites
Quote:
 I would then have a singly-linked list that the program would traverse several times with each frame so that it could decide what changes to make in all of these values and then what to draw!

sounds questionable. the classes themselves should do this.
since you're only doing 2D mario style stuff, then you could probably get away with placing all the stuff in the enity(or object container) class. for instance,
class Enity{sprite* m_sprite;int m_currAnim;public:     void Jump(int deltaTime);     bool collidesWith( Enity& enity );     void drawMe(whatever goes here);};class AIEnity : Enity{public:     void calcAI(some ai iq level);};

and then create another enity that has ai, or something. there really is no best way - just go for it and hash it as needed. if it doesn't work rearrange things.
hope some of that made sense.

#### Share this post

##### Share on other sites
class Enity
{
sprite* m_sprite;
int m_currAnim;
public:
...

hehe, beat me to it! Actually, your problem is talked about a lot in the game programming and the graphics and theory sections. What you want to do is build a game object system. Normally with the C++ method, one will make a base class which all other classes are inherited from, such as unreal's actor class which I believe vehicles, characters, weapons etc are derived from.

StormRunner explain it nicely in his code snippet. After you got your object classes down, you may want to look into scene graphs.
this was a very good article on the subject. It should give you some good ideas. Also, try this out. Actually, try this one first ;)

Hope this stuff helps.
~Jason

#### Share this post

##### Share on other sites
"Entity". Please. [smile]

#### Share this post

##### Share on other sites
The point of classes in C++ is to group bits of code together in a logical and reusable way. Classes were created so it would be easier to test, maintain, and debug code - tossing physics, drawing code, and a linked list into a class pretty well defeats the purpose.

By using OOP coding styles, you can break a large object (like a sprite) into many smaller, more modular objects. Here's a sample class listing (its by no means the only one tho).

1) Object -> keeps X, Y position, maybe some simple stats
2)RenderObject(Object) -> inherits from object, you can load an animation into this object and draw it @ the location in Object
3)PhysSprite(RenderObject)-> This class contains physics code, and extra sprite only stuff
4)StillSprite(RenderObject) -> Notice that this class inherits from RenderObject! This is a sprite class without the physics engine, making it faster. You could use this for background tiles, or immovable game objects.

#### Share this post

##### Share on other sites
Thanks guys. One thing that is confusing is that different entities are ultimately going to have different AI schemes and respond to collisions differently (bounce? explode?) and perhaps even have different physics. This makes reusability difficult, doesn't it? I mean, even if I have different types of entities that I inherit from the base entity class, I'm going to have to overload almost all of the methods in the class, which basically means I'm re-writing it several times anyway.

I'm just venting, by the way. I don't expect anyone else to provide the answers, nor do I think that's a proper way for me to learn.

Also I was thinking of making the animations themselves be nothing but a series of envelopes. There would be envelopes for each of the entity's properties (x-position, y-position, acceleration, velocity, rotation, etc.). An envelope would itself just be an array of Key objects, and Key objects would have two properties: a time and a value.

So an envelope for the x-position might look something like this:
key[0].value = 0;key[0].time  = 0;    // millisecondskey[1].value = 100;key[1].time  = 1000;

So at the 0th millisecond of the animation, the change in x-position is 0. At the 1000th millisecond of the animation, the change in x-position is 100. If a frame is rendered at the 600th millisecond, the xposition is extrapolated from this envelope and a value of 60 is returned.

And actually, I would want it to be a curve if you graphed it and not a line (otherwise it wouldn't be an envelope, right?). So if there was a third key:
key[2].value = -100;key[2].time  = 2000;

...the result would be a bell curve, because the value would curve up to 100 and then back down to 0 (100 - 100).

edit - since I suck at explaining things, here is a diagram:

Though perhaps the envelope class can also have a tension property so that the diagram on the right would be possible if need be.

-end edit-

And there would be envelops for y-position, rotation, size, acceleration (which alters the velocity), velocity (which alters the position), etc. The frames of animations themselves will have keys too but rather than interpolate the frames in between keys, it would just display the last frame rendered until the frame changes. Make sense?

[Edited by - gimbal_lock on September 20, 2004 1:44:34 PM]

#### Share this post

##### Share on other sites
As Onemind pointed out, classes should stay relatively small and clean. However, there will be cases when you may need to derived several classes from a base class that all share common properties,
this is when your base class could have all of these variables and methods.

However, there are many many ways of doing things. Im going with multiple inheritence with my object system. For example, each class deals with a particular thing, such as a render class, collision class, physics class (variables and such your objects can use for physics), controller class etc. This way here, when a certain object doesn't need say collision routines, you simply don't derived from the collision class. Personally, however, I like using pointers over inheritance where possible.

Scripting comes into play when you need to create several entities that are basically the same but may have slight differences in behavior, rendering, maybe even physics. For example, a sniper and a standard foot soilder are not really that much differnt code wise, but a sniper carries a sniper rifle and sneaks around...

Physics I haven't delt with much in my project yet, so I won't mention to much about them. However, what im probably going to do is create a physics class which has common physics routines like applying gravitational acceleration and such and then in each object class, ill add the remainding vairables associated with the objects, such as a vehicle would have drag, ground/water/air friction, torque, etc where as a humanoid normally doesn't have a level or torque and or use gears ;)

## Create an account or sign in to comment

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

## Create an account

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

Register a new account

## Sign in

Already have an account? Sign in here.

Sign In Now

• ### Forum Statistics

• Total Topics
628381
• Total Posts
2982359

• 10
• 9
• 15
• 24
• 11