Public Group

# Game Code Structure & Stitching It All Together

This topic is 5025 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

##### 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 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 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 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 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 ;)

1. 1
2. 2
Rutin
18
3. 3
4. 4
5. 5

• 14
• 12
• 9
• 12
• 37
• ### Forum Statistics

• Total Topics
631428
• Total Posts
3000027
×