hello everyone. I am working on an RPG, and i am now at a part in the development stage where it is necessary to create clsses for weapons,items and spells. But i dont know what the best way would be to set this up.Should I have a spell class,and then objcts off of it,like description,damage,etc...But i dont know how rto do this. Could someone please give me a small sample on how to get started on this.I am using Visual Studio, and VB6.Thanks. "Good,evil,I got the gun" Ash- Evil Dead

Compartmentalize. Instead of having domain-isomorphic classes, have classes for the "behaviors" of the items, and throw the items together as a "generic" item class of these behaviors:

BEHAVIOR EXAMPLES
CDamageObjects
CVisualEffects
CSoundEmit
CActorSpeak
CActorMotion
CActorSound

OBJECT CLASS
CGameObject
member
CGameBehavior& GetBehavior();

(I believe in VB you have to use polymorphism and the Implements keyword to do this, unless you actually have VB.NET, which you probably don''t yet have. )

Unless your using VB .NET, don''t use classes. VB isn''t really OOP, and attempting to use OOP in VB WILL run you into many problems. I made an OOP Tetris clone and it was hell the whole way. Here''s one of the great ways VB truly sucks:

Try to make a custom data type. Something like
Type Goof
Stuff as Integer
Stuff2 as String
End Type

(forgive syntax errors, I haven''t done VB in a while thankfully)

Then make a class. Now try to make a function which takes an argument of type Goof (or returns type Goof, same problem either way).

VB complains saying you can only do this in a public object module. So yea, sure, try and put the Type Goof into a module instead of class file. Same problem. Apparently only way to get VB class functions to accept custom data types as arguments is if the data types are created in a .dll.

You''ll run into many problems such as this, so stick to structured programming if you insist on using VB.

thanks for the help,guys. That all makes sense, and that was also what i was debating on doing, but it semms it would be easier to just set up public variables for everything,like fireball description,fireball damage,fireball animation.Think that would work,or would it be even more slow?

"Good,evil,I got the gun"
Ash- Evil Dead

Don''t shove everything into public variables whatever you do.

I find the best substitute for classes (which are slow, and can get annoying to use if you mix them with UDTs) is to make a standard module a bit like this:

Type udtThisModule	Property As Type	Property As Type	...End TypeDim Instances() As udtThisModuleDim UBoundInstances As LongConst OVERDIM As Long = 5Sub Init	''Start with a few instances ready	Redim Preserve Instances(OVERDIM)	UBoundInstances = -1End SubFunction CreateInstance(Arguments) As Long	''Make room for this instance	UboundInstances = UBoundInstances + 1	If UBound(Instances) < UBoundInstances Then		Redim Instances(UBoundInstances + OVERDIM)	End If	''Set properties	With Instances(UBoundInstance)		.Property = Argument		.Property = Argument		...	End With	''Return Index	CreateInstance = UBoundInstanceEnd FunctionSub RemoveInstance(Index)	You''ll have to write this one yourself because depending on how you are using it, different optimisations can be done, like if the order of the objects doesn''t matter, you can speed it up a lot.End FunctionSub Method(Index As Long, Arguments As Long)	With Instances(Index)		DoStuff	End WithEnd SubSub Method(Index As Long, Arguments As Long)	With Instances(Index)		DoStuff	End WithEnd Sub... 

That works really well. Fast, and readable. The constant OVERDIM tells it how many extra elements of the array to declare than necessary, so it will run faster because when creating new instances it does less "Redim Preserves" (which are slow).

And then rather than using UBound(Instances) to get the size, use UBoundInstances because it doesn''t include the dummy instances.

I would consider using Classes for business apps, but for anything else... spare me

btw... reread that first sentence and memorise it. I can''t stress that enough.

Trying is the first step towards failure.