Creating a "Object" Class

Nibbie
Posts: 2
Joined: 2009.01
Post: #1
Well, disclaimers first: I am a newbie, and I am a 3D animator, so most of my experience comes from that and so it may be fundamentally flawed for working ith OpenGL.

I think I need a class for objects in my game, how have you guys dealt with this? what is included in your object class? does it include more than just the model data? how do you include the information neccesary for colision detection, etc?
Quote this message in a reply
Member
Posts: 304
Joined: 2002.04
Post: #2
ok, here are some way too extensive rambling suggestions/ideas:

If you describe what kind of game you want to write it would help narrow down what you need.

First you need some basic math classes. Real, Point, Vector, Rect, and if you are making a 3d game then Vertex, Matrix, Quaternion, Plane, Sphere, Frustum, AAB (Axis-Aligned Box), Triangle, Texture. You can find examples online (I can post some links if you need).

You need a Camera class. If its a 2D game, then maybe the Camera class only consists of a Point, or a Rect. In 3D you probably want it to contain a Frustum. You need some way of knowing what you are looking at.

You need some kind of Input class to read the keyboard/mouse/joystick.

You need an Image class. For 3D you need a Model class. They should be able to Draw() themselves. They should be able to initialize themselves from whatever file 2D or 3D format you are using (.png, .obj, etc...). The Model class would obviously contain an array of Verts and Triangles and Textures - NeHe has some example code you can download.

You need a Sprite class. The Sprite class is an abstract base class. You never actually make (instantiate) a Sprite object - but first you create a Sprite subclass and make that. The Sprite class should contain a Point called 'position' and a pointer to some Images if its a 2D game or a pointer to some Models if 3D. The Sprite class should have virtual functions Update(Real time) and Draw(Camera * camera). If your animation is going to be frame-based instead of time based you could have Update(int frame) or just Update() instead. When you subclass Sprite to make your PacManSprite class you will override Update() to read the controls and changes the position variable, while you will override Draw() to send an image of a yellow pizza with a slice cut out. Likewise your GhostSprite class' Update() will change its position to follow the pacman, while its Draw() will draw a ghostly image. It might have variables for color, speed, agressiveness, etc... It also will have a PacManSprite pointer that points to the pacman object so it knows what its following.

If your game is physics-based (as opposed to an aracde game like pacman) then Sprite (maybe now call it RigidBodySprite?) should also have Vector variables for force, acceleration, velocity and Real variables for mass and oneOverMass. Then Update() in subclasses wouldnt set the position variable directly - it would update the forces that are applied to the object. So Update() in RocketshipSprite class would set the force vector in one direction if the boosters are engaged - it would set the force vector to the opposite direction if the retrorockets were engaged, and it would set the vector force to the zero vector if we are just coasting. Then Sprite would also need a method UpdatePosition(Real time) that would use the force applied to the object, the time, and the mass to figure out its acceleration, then its velocity, and then finally its new position. Also you would need a Matrix or Quaternion variable to handle its rotation.

A Sprite class should probably also contain a hull object. For 2D probably a rect while for 3D maybe an AAB or a Sphere. This object completely encloses the sprite (but isnt drawn). The hull can be used in your Draw() method to cull objects - that is if the hull is outside the camera's view then you can forgo drawing it. Its also used for collision - that is if two hulls dont collide we know the objects contained in those hulls dont collide.

A Sprite class should have a method Ill call KillMe() which should return true if the sprite wants to be deleted.

We need a container for all these sprites. Lets call this class SpriteList and is a subclass of Sprite. SpriteList keeps a list of *pointers* to sprites. It has a method AddSprite(Sprite * sprite). Since it takes a Sprite pointer, you can add to the list any subclass of Sprite including a PacManSprite, a GhostSprite, or even another SpriteList. If you send a Draw() message to a SpriteList object - it should just pass that Draw() message to all the sprites in its list. Since Draw() is virtual a PacManSprite will correctly draw a yellow wedge while a GhostSprite will draw a ghost. SpriteList also needs a method Ill call Prune() - which will ask all of the sprites in its list KillMe()? and removes any that return true.

A Level class would be nice. Those objects (either by hardcoding or even better by reading a file) will set up the initial conditions of the level - creating Sprites and SpriteLists and initializing them.

And then finally a MyGame class which, runs a menuand a user-interface, starts up Levels and such.

Whew - a little too much - a little too overwhelming. Start slow. Take the shortest path possible to getting some small thing up and running (because thats rewarding and fun) - but with a plan to how it might grow and become more involved. Dont reinvent the wheel - use opensource code examples, libraries, frameworks, sdks, etc... If possible use an engine that exists already so you can concentrate more on the specifics of your game and less on the specifics of engine writing.

good luck man!
Codemattic
Quote this message in a reply
Member
Posts: 148
Joined: 2003.03
Post: #3
Grin
Probably the most informative post I've ever fully read.. Rasp
Quote this message in a reply
Nibbie
Posts: 2
Joined: 2009.01
Post: #4
MacFiend Wrote:Grin
Probably the most informative post I've ever fully read.. Rasp

absolutely, thansk man!
Quote this message in a reply
Moderator
Posts: 770
Joined: 2003.04
Post: #5
A little tip: be careful about in which classes you place methods: Putting a Draw() method on your object/model class is a good idea; putting it on your triangle class and calling it once for every triangle on your model is not Wink (performance-wise)
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #6
The "enginuity" (spell?) series on flipcode.com gives a lot of ideas in this range, too. Can't find the link, though.
Quote this message in a reply
Nibbie
Posts: 2
Joined: 2009.01
Post: #7
k, thanks guys
Quote this message in a reply
BobbyWatson
Unregistered
 
Post: #8
DoG Wrote:The "enginuity" (spell?) series on flipcode.com gives a lot of ideas in this range, too. Can't find the link, though.

The Enginuity series is not on flipcode, it's on gamedev.net. Here are the links to the articles :

Enginuity I : http://www.gamedev.net/reference/article...le1947.asp
Enginuity II : http://www.gamedev.net/reference/article...le1954.asp
Enginuity III : http://www.gamedev.net/reference/article...le1959.asp
Enginuity IV : http://www.gamedev.net/reference/article...le1973.asp
Enguinity V : http://www.gamedev.net/reference/article...le2011.asp
Quote this message in a reply
Nibbie
Posts: 2
Joined: 2009.01
Post: #9
thanks again guys
Quote this message in a reply
Member
Posts: 268
Joined: 2005.04
Post: #10
I had this big long post about Gaichu's structure written out, but it somehow got deleted (think I accidently reloaded the page), and I'm too tired to redo it. If anybody actually wants to see it I'll try rewriting it later. For now I'll just ask a question.

For Gaichu I tried the Model-View-Controller paradigm just for the hell of it. I can now safely say that MVC just wasn't designed with games in mind. Can anybody recommend a better OOP paradigm that's better suited to games? Or how about any game engine design articles other than Enginuity, which has some good info, but is still far too C++ and Windows-centric for my tastes.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #11
BobbyWatson Wrote:The Enginuity series is not on flipcode, it's on gamedev.net. Here are the links to the articles :

Enginuity I : http://www.gamedev.net/reference/article...le1947.asp
Enginuity II : http://www.gamedev.net/reference/article...le1954.asp
Enginuity III : http://www.gamedev.net/reference/article...le1959.asp
Enginuity IV : http://www.gamedev.net/reference/article...le1973.asp
Enguinity V : http://www.gamedev.net/reference/article...le2011.asp
No wonder I couldn't find the link then. Whoops.
Quote this message in a reply
Member
Posts: 70
Joined: 2004.06
Post: #12
Would there be any benefit to having a graphics class that has a drawFrame method, and simply passing that an array of objects to be drawn? I would think that maybe it is a little less-efficient, as the drawFrame function still has to request vertex data from each object, then draw it.

Any benefits that some of you more experienced people can see?
Quote this message in a reply
2xp
Unregistered
 
Post: #13
thanks codematte, saved me a lot of time
i also come from the c++ world, and this summer, i am planning to make a 3d space game, this is kinda serious project

Quote:First you need some basic math classes. Real, Point, Vector, Rect, and if you are making a 3d game then Vertex, Matrix, Quaternion, Plane, Sphere, Frustum, AAB (Axis-Aligned Box), Triangle, Texture. You can find examples online (I can post some links if you need).

ca we have them Grin

also
1 - how good is the MVC design for macosX games ?

2 - how do i create objects ? i have to create scenery objects and spaceship objects all the time. i saw the xcode ports of Nehe's lessons, and they used structs to handle ennemies / player and everything. but i don't like this because in my game everything is dynamic and kinda random and need some kind of object container or a list and just do a :
for ( entities.begin(), entities.end() ){ updatelogic(); updatedraw()}

edit : i saw your addSprite( * sprite) method in the spriteList class, so my question gets reduced to this : how do i create objects in cocoa ? do i have to design a factory ? i feel this is a very basic question, but i wanna make sure how things get done in cocoa

3 - how do i handle events ? i have this gameAI class which will process all game logic and send series of events like paths to follow and stop/attack/communicate orders. so the objects need to have a list of events to process. any thoughts on how to do that ? this is important because i'll use the same desing for the levelmanager class.

4 - is there any standard 3d format on macos ? do you guys use 3ds ? is there any standard file loader out there which will give me nice and clean vertices directly ?

i really need an answer to these questions
Quote this message in a reply
Member
Posts: 370
Joined: 2002.04
Post: #14
As for the 3D format I don't use it myself, but Meshwork seems to be a very popular utility because of its low cost.

Did you ever wonder why we had to run for shelter when the promise of a brave new world unfurled beneath the clear blue sky?
Quote this message in a reply
Member
Posts: 70
Joined: 2004.06
Post: #15
There is also Blender, a free 3D modelling application. It has been used for a lot of game content creation I believe, and I think it can save to quite a few different formats, although you may need plugins to do it.
Quote this message in a reply
Post Reply