Sign in to follow this  
BUnzaga

Examples of your 'game object' class.. ?

Recommended Posts

I am about to start programming my game object class and I am running into a bit of confusion. This game is a 3d game, with a 2d UI. Objects can be picked up off of the 'ground' and an icon associated with that item is placed in the users inventory. If the user picks up a 3d object, when he clickes and drags the object, it turns into the 2d icon. When the user drags the 2d icon from their inventory and drops it on the screen, the 3d object is placed on the ground. When the user equips a sword or armor, etc. They drag (or double click) the icon in their inventory, and then drop it on a 2d character sheet. When they do this, the proper mesh subgroup is hidden/revealed(in the case of armor) or the proper mesh is loaded from file and attached to the proper attach point, such as weapons or other attachable objects. Also the proper texture for the object is applied to the map channel (in cases where objects have the same base mesh, but different textures). Some objects in the world are 'usable' such as a doors, turning on or off lights, putting out a fire, etc. They can use the object, but they don't pick it up. Most objects will have various leftClick, rightClick, doubleLeftClick, onHover, onHoverEnd, functions, etc. This goes for both 2d and 3d versions. (such as you can hover over the item in your 2d inventory to see the stats of the item, or you can hover over the item on the ground to see what the items name is). These will sometimes be the same, but sometimes different. So what do you suggest for my world object class or inherited classes look like? I was thinking of something like:
//psuedo
class GameObj
var scriptFile2d //script file to be used for the 2d version of the object
var scriptFile3d //script file to be used for the 3d version of the object
var meshDefinition //mesh to be used
var iconDefinition //icon to be used
var objType //such as sword1h, sword2h, food, gloves, etc.
var objOwner //the npc, container, or map this obj belongs to
function make3d(pos, rot, scale) //function to make the 3d version of the obj
function make2d(pos, rot, scale) //function to make the 2d version

Next I will have the scripts for the two versions..
// js include file for the object script
function onUse()
function onEquip()
function onRemove()
function itemRef() //this is used to refer back to the GameObj
function leftClick()
function rightClick()
function doubleClick()
function hoverBegin()
function hoverEnd()

The main difference between the 2d and 3d are some texture/color info...
var ambDiffuse
var spec
var emiss
var texMap

// js include file for the object script
function onUse()
function onEquip()
function onRemove()
function itemRef() //this is used to refer back to the GameObj
function leftClick()
function rightClick()
function doubleClick()
function hoverBegin()
function hoverEnd()

Ok so I guess for the GameObject, I will also need things like longDescription, shortDescription, prerequisites, damageMin, damageMax, range, quantity, condition, buyPrice, sellPrice, and everything else I forgot. What about specific objects for quest items? So you can see I am a bit overwhelmed about all of this. Any examples of your game hierarchy or super/extended classes, I would appreciate it a lot.

Share this post


Link to post
Share on other sites


function make3d(pos, rot, scale) //function to make the 3d version of the obj
function make2d(pos, rot, scale) //function to make the 2d version




Putting this in your GameObj class leads me to suggest following a strict MVC pattern.

Ideally, the model (your GameObj and its derivatives in this case) should include nothing related to the UI. It sounds like you have two Views for GameObjs - 2D and 3D.

Other than that, I'm afraid I'm not entirely sure what the problem is past conceptual issues.

Share this post


Link to post
Share on other sites
I avoid having a fixed hierarchy (readme and readmetoo).

I would split things up as follows:
  • Item data. This is independent of location (floor/inventory) and represents things such as name, weight, type (weapon or other) as well as specific related properties for equipping.
  • On-the-floor items exist in the game world. Interacting with them attempts to pick them up. They are bound to item data, as well as anything required to render them. Can be converted to an inventory item.
  • Inventory items exist in the inventory. They react as would be expected in the inventory. They are bound to item data, as well as anything required to render them. Can be converted to an on-the-floor item.
  • Items that cannot be picked up (but merely change their state when clicked, without affecting the player directly) are stored separately and are not associated with item data.

Share this post


Link to post
Share on other sites
Thanks guys, both great feedback!

zdlr, so my icon and my 3d mesh would just pass the event through to the event handler, passing in the pointer to their 'GameObject'.

Then the event handler goes through and calls gameObject.iconLeftClick() or gameObject.meshLeftClick(), depending on who fired the event.

Next the code in my gameObject will update the game, such as equipping the object, etc. So the icon/mesh/UI/game world is the view, my GameObject is the model, and my event handler is the controller? Awesome, thanks.

ToohrVyk, thanks for those readme files! I am already using a similar approach for my AI, and it makes sense to try to carry it over to my objects. In my AI, I have actions and what I call behaviors. A behavior could contain many actions, and is more or less an event object. An action is pretty much a method. So in a situation where I need to move an NPC to a target, I would do something like...

aiQue.add (new goTo(new Vector(x, y, z)));

goTo(target)
{
update()
{
if(notAtTarget(target));
{
turnToward(target);
moveForward();
}
else
{
aiQue.remove(this);
}
}
}

The only difference between this and the 'cowboy' concept, is I usually script all of these into a specific animal or NPC script, like 'spider' or 'ogre', etc. It does make more sense though to just have all the actions and behaviors on a global level, and just create them by passing in the entity.

I also like how you broke down Item Data. I was thinking of separating the world objects from the others too, but wasn't sure if this was the best way to do it or not. It looks like it is. :P

Share this post


Link to post
Share on other sites

Quote:
Original post by BUnzaga
zdlr, so my icon and my 3d mesh would just pass the event through to the event handler, passing in the pointer to their 'GameObject'.


Sounds about right.

Quote:
Original post by BUnzaga
Then the event handler goes through and calls gameObject.iconLeftClick() or gameObject.meshLeftClick(), depending on who fired the event.


No, iconLeftClick and meshLeftClick are view-centric methods. This might seem like pedantic method-naming semantics, but you should call them something more model-centric. gameObject.inventorySelected() and gameObject.gameWorldSelected() do not imply any view, instead focusing on the intent of the method.

Quote:
Original post by BUnzaga
Next the code in my gameObject will update the game, such as equipping the object, etc. So the icon/mesh/UI/game world is the view, my GameObject is the model, and my event handler is the controller? Awesome, thanks.


Yeah, that sounds about right, although gameworld is likely to be a model which contains all of the gameobjects. Views are merely visual representations of the model. Every time you put something in your model, assume that your game instead has a dos console interface - no mouse or fancy graphics, just text commands and text output. If what you've just put in your model contains view implementation details (like left-clicking), you've gone wrong.

Share this post


Link to post
Share on other sites
Ahh, I get it now. So the code shouldn't indicate anything about the view, it should just do what it does, regardless of how or who called the function.

I did something like this in my movement script. When the user pressed keys['upKey'], I set movement.up = true. Also if the user presses the right mouse button, I set movement.up = true. This way they can either press the upKey, or the right mouse button, or both, and it all does the same thing. They are independant of eachother, and the code is not dependant on them.

That is a good tip about the text mud visualization. Thanks!

Share this post


Link to post
Share on other sites
Ok so I had most things going great so far, but I ran into a slight snag...

For most of my armor, I am just setting different subgroups to visible / invisible.

I have three suits of armor, light, medium and heavy. Each is broken up into things like legs, boots, gloves, etc. I physiqued them so that they can be swapped out a piece at a time seamlessly.

So now this creates a situation where now I have an object, which isn't a separate mesh, and has other things such as diffuse color, specular color, texture map (the texture map can also be changed to create more variety).

So... I was thinking of creating a separate object for these 'meshObjects'.

What do you guys think?

GameObject - Things in the world that the user can use, but not equip.
MeshObject - Parts of the user mesh that can contain different textures, etc.
ItemObject - Object in the game such as weapons, health potions, etc.

Share this post


Link to post
Share on other sites

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

Sign in to follow this