Gebruikelijke namen voor classes en methods in games

[Gamebuster]

Ik speel nu al een tijdje met allerlei programmeertalen met heb toch regelmatig moeite met het bedenken van goede namen voor classes, met name (abstracte) super-classes.

Zijn er ergens richtlijnen voor het bedenken voor namen voor classes en hun methods, met name bij de ontwikkeling van (kleine) games?

Zelf gebruik ik "Entity" als (abstracte) root-class voor alle in-game objecten. Dit is bijv. mijn Entity root-class in een huidig projectje:

C++:

#ifndef _ENTITY_H
#define _ENTITY_H

#include "model.h"

class Entity
{
private:
    
    // The last known determined coordinate of this entity before the start of
    // any kind of applicable motion. Coordination is measured in points.
    EntityCoordinate2D coordinate;
    
    // The last known determined orientation of this entity before the start of
    // ant kind of applicable motion. Orientation is measured in radians.
    EntityTheta1D orientation;
    
    // The current velocity of the entity. The angle is relative to the angle
    // of the entity, which is relative to the world. Speed is measured in
    // points per second. Rotation is measured in radians per second.
    EntityVelocity2D velocity;
    
    // The current speed of the angular movement, in radians per second. 
    EntityTheta1D angularSpeed;
    
    // The motion-duration of the current velocity and rotation in milliseconds.
    EntityTime motionDuration;

private:
    
    // A method to apply the new coordinate and orientation based on the current
    // active motion (velocity and angular speed) and motion duration.
    // properties "coordinate" and "orientation" will be updated and property
    // "motionDuration" will be reset to 0.
    // This method doesn't affect the "velocity" and "angularSpeed" properties.
    void applyMotion();
    
protected:
    
    // Construct a new entity based on a coordinate and an orientation.
    Entity(EntityCoordinate2D coordinate = EntityCoordinate2D(0,0),
           EntityTheta1D orientation = EntityTheta1D(0));
    
    // Set the velocity of this entity.
    virtual void setVelocity(EntityVelocity2D velocity);
    
    // Set the angular speed of this entity.
    virtual void setAngularSpeed(EntityTheta1D speed);
    
    // Get the maximum speed of this entity in a certain direction.
    virtual EntityCoordinate1D getMaxSpeedInDirection(EntityTheta1D theta);
    
public:
    
    // Get the current coordinate of this entity. Might be calculated if there
    // is a movement active.
    virtual EntityCoordinate2D getCoordinate() const;
    
    // Get the current orientation of this entity. Might be calculated if there
    // is an angular motion active.
    virtual EntityTheta1D getOrientation() const;
    
    // Get the dimension of this entity.
    virtual EntityDimension2D getDimension() const = 0;
    
    // Increment the time of this entity by milliseconds.
    virtual void incrementTime(EntityTime1D time);
    
    // Get whether this entity is solid and should be checked for collisions
    // with other entities.
    virtual bool isSolid() const = 0;
    
    // Get the speed of the angular motion of this entity.
    virtual EntityTheta1D getAngularSpeed() const
    {return this->angularSpeed;}
    
    // Get the velocity of this entity.
    virtual EntityVelocity2D getVelocity() const
    {return this->velocity;}
    
    // Apply a transformation (translation + rotation) in a 2D coordinatable.
    virtual void applyTransformIn(EntityCoordinatable2D * c2d) const;
    
    // Apply a translation in a 2D coordinatable.
    virtual void applyTranslateIn(EntityCoordinatable2D * c2d) const;
    
    // Deconstructor
    virtual ~Entity(){};
};

#endif

Dit is de root-class voor alle objecten die zich kunnen verplaatsen voor in een 2D game van bovenaf. Denk aan kogeltjes, raketjes, tankjes, vliegtuigjes, etc. Er komt nog een superclass boven (dat wordt dus de nieuwe root-class) die ook gebruikt zal worden voor objecten die zich niet (nooit) kunnen verplaatsen, maar daar weet ik nog geen naam voor. Denk aan stenen, gebouwen, muren, etc.

Bovenstaande code is gebaseerd op een rommelig, half "prototype" in Javascript: http://kutcomputers.nl/jsrts/

Verder code- en structuur-gerelateerd commentaar welkom.

[.oisyn]

Wat impliceert dat een Entity kan bewegen dan? Waarom is Entity niet je root class en is een beweegbare entity geen MovableEntity? Als je root class veel abstracter dan een entity dan kun je ook gewoon denken aan GameObject oid. De naam hangt natuurlijk nogal af van de verantwoordelijkheden van de betreffende class, dus er is sowieso geen gouden formule voor.

[Gamebuster]

"Waarom is Entity niet je root class en is een beweegbare entity geen MovableEntity?"

Ik zal het inderdaad in zoiets gaan veranderen straks, maar ik vroeg me af of er gebruikelijke namen zijn voor zulke objecten bij game development. In games zie je namelijk altijd bepaalde soort objecten:

-Objecten die daar maar "staan". Ze kunnen niet kapot, ze bewegen niet, je kan er alleen tegenop botsen maar verder niets.
-Objecten die kunnen bewegen. Denk aan prullenbakken, flessen, kogels.
-Objecten die op basis van input van een controller, AI of "mens" kunnen bewegen.
-Zooi subclasses met nog meer details, zoals voor vijanden en speler. Die namen zijn niet zo moeilijk meer.

[Voor 48% gewijzigd door Gamebuster op 29-10-2010 14:48]

[.oisyn]

Gamebuster schreef op vrijdag 29 oktober 2010 @ 14:43:
-Objecten die daar maar "staan". Ze kunnen niet kapot, ze bewegen niet, je kan er alleen tegenop botsen maar verder niets.

Die vallen meestal onder de noemer "terrain".

-Objecten die kunnen bewegen. Denk aan prullenbakken, flessen, kogels.
-Objecten die op basis van input van een controller, AI of "nmens" kunnen bewegen.
-Zooi subclasses met nog meer details, zoals voor vijanden en speler. Die namen zijn niet zo moeilijk meer.

Ik zie niet echt een verschil tussen deze drie. Je moet imho niet proberen om alle functionaliteit in 1 class te stoppen. Er is niets op tegen om de avatar van de player eenzelfde soort object te laten zijn als een prullenbak. Er is alleen een controller die dat object door de wereld beweegt op basis van je input.

Persoonlijk zou ik niet zo'n diepe hierarchie maken, en in plaats daarvan classes maken per subsysteem. Het gedeelte dat van belang is voor de culling en rendering heeft weer niets te maken met het gedeelte dat je gebruikt voor collision detection en physics. Sommige objecten zijn wel zichtbaar maar hebben geen collision mesh. Andersom zul je ook collision mesh hebben om te zorgen dat je ergens niet doorheen kan bewegen zonder dat daar zichtbare graphics achter hangt. Oftewel, veel meer gebruik maken van has-a relationships, ipv is-a.

[Davio]

Ik zou kiezen voor:

root: Entity
subs: MovableEntity, ImmovableEntity

En dan AIEntity en PlayerEntity als subs van MovableEntity?

Zoiets, denk ik.

Daarbij vind ik dat je je er niet teveel zorgen over hoeft te maken; het feit dat je er over nadenkt en zorgt dat je in ieder geval voor namen kiest die logisch zijn en te begrijpen door iemand die de details van je project niet kent, is goed genoeg.

[jip_86]

Ik probeer meestal iets van de eigenschappen er in te verwerken. MovableEntity zou hier een goed voorbeeld van zijn.

[Gamebuster]

Dit is 'm geworden:

Entity
MovableEntity
Unit

http://pastebin.com/iis2HmHn

De meeste classes zullen direct 1 van deze 3 classes als superclass kunnen gebruiken. "Entity" zal gebruikt worden als super-class voor statische objecten, "MovableEntity" voor alles wat kan bewegen, maar verder geen/beperkte intelligentie heeft. "Unit" voor ingame objecten ("units": tanks, vliegtuigen, boten, etc) die bestuurd worden door een pathfinder, die weer bestuurd wordt door een speler of AI.

Ben er zo wel tevreden mee

[Voor 63% gewijzigd door Gamebuster op 29-10-2010 16:27]

[.oisyn]

En wat als je nu ineens besluit dat de prullebak bestuurbaar moet zijn, ga je dan die klasse ineens van een andere superclass deriven?

[Voor 13% gewijzigd door .oisyn op 29-10-2010 16:26]

[Gamebuster]

.oisyn schreef op vrijdag 29 oktober 2010 @ 16:26:
En wat als je nu ineens besluit dat de prullebak bestuurbaar moet zijn, ga je dan die klasse ineens van een andere superclass deriven?

Ja.

[Voor 6% gewijzigd door Gamebuster op 29-10-2010 16:29]

[Woy]

Gamebuster schreef op vrijdag 29 oktober 2010 @ 16:28:
[...]

Ja.

Waar .oisyn op doelt is dat het flexibeler is, als je de besturing van een World Object uit die class zelf haalt. Je introduceert dan bijvoorbeeld een class Controller, die als property weer een object heeft die hij bestuurt. Die controller kun je zien als een soort puppet master.

Op die manier hoef je je prullenbak object straks niet aan te passen als hij opeens door een user bestuurd moet worden.

[Gamebuster]

Woy schreef op vrijdag 29 oktober 2010 @ 17:08:
[...]

Waar .oisyn op doelt is dat het flexibeler is, als je de besturing van een World Object uit die class zelf haalt. Je introduceert dan bijvoorbeeld een class Controller, die als property weer een object heeft die hij bestuurt. Die controller kun je zien als een soort puppet master.

Op die manier hoef je je prullenbak object straks niet aan te passen als hij opeens door een user bestuurd moet worden.

Aah, ik vroeg me al af wat hij ermee bedoelde

Ik zal er eens over brainstormen. Is het hierbij de bedoeling dat de Entity (World Object, zoals jij het omschrijft) zijn eigen locatie kent en de Controller de locatie van een (of meerdere) Entity(s) kan updaten?

[Voor 47% gewijzigd door Gamebuster op 29-10-2010 17:32]

[.oisyn]

Gamebuster schreef op vrijdag 29 oktober 2010 @ 17:28:
[...]

Aah, ik vroeg me al af wat hij ermee bedoelde

Deze post wel gelezen: .oisyn in "Gebruikelijke namen voor classes en meth..."?

[Gamebuster]

.oisyn schreef op vrijdag 29 oktober 2010 @ 17:29:
[...]

Deze post wel gelezen: .oisyn in "Gebruikelijke namen voor classes en meth..."?

Ja, maar waarschijnlijk heb ik over dit zinnetje heen gelezen: "Er is niets op tegen om de avatar van de player eenzelfde soort object te laten zijn als een prullenbak. Er is alleen een controller die dat object door de wereld beweegt op basis van je input."

Ik vind het in ieder geval een erg interessant ideetje. Terug naar de "tekentafel". Ik ga in Java of Javascript wel even experimenteren met dit idee.

edit:
Niet nodig om in Java/Javascript te doen. Ik kan een subclass schrijven van Entity die "bestuurd" wordt door een Controller.

[Voor 21% gewijzigd door Gamebuster op 29-10-2010 18:50]

[Woy]

Even een trap richting SEA, aangezien het daar beter thuis hoort.

[Gamebuster]

*bump*

Hoe noem je een struct/object dat zowel een (2D) positie als een richting/hoek bevat? Ik zit me gek te google'n en te wikipedia'en

Ik heb wel 1tje voor beweging, namelijk "Velocity"

Hierboven had ik namelijk:

C++:

    EntityCoordinate2D coordinate; 
    EntityTheta1D orientation;

En dat wil ik in 1 struct/object smijten, maar kan maar geen goede naam bedenken.

[Voor 28% gewijzigd door Gamebuster op 05-12-2010 19:27]

[.oisyn]

Pose, al heeft dat voor niet-rigide objecten een wat uitgebreidere betekenis (zoals bijv. ook alle bone matrices). Overigens klopt je terminologie sowieso niet. Één coördinaat is een enkel getal. Iets als (100, 300) bestaat dus uit 2 coördinaaten. Ik zou het gewoon position of origin noemen (en je type ook even renamen).

[Voor 16% gewijzigd door .oisyn op 05-12-2010 23:26]

[doskabouter]

.oisyn schreef op zondag 05 december 2010 @ 23:13:
Overigens klopt je terminologie sowieso niet. Één coördinaat is een enkel getal. Iets als (100, 300) bestaat dus uit 2 coördinaaten. Ik zou het gewoon position of origin noemen (en je type ook even renamen).

Volgens mij klopt het wel. een Coördinaat heeft 2 getallen, zie ook http://nl.wikipedia.org/wiki/Ordinaat

[.oisyn]

Nee. Je hebt een x-coördinaat, en een y-coördinaat. 2 coördinaten. Je zegt ook "wat zijn de coördinaten van dit punt", niet "wat is het coördinaat van dit punt".

Daarnaast denk ik dat je die door jou aangehaalde wikipedia pagina maar eens goed moet gaan lezen

De beide getallen, abscis en ordinaat, worden algemeen de coördinaten genoemd van het punt P in het beschouwde coördinatenstelsel. Omdat in een plat vlak twee coördinaten nodig zijn om een punt vast te leggen, zeggen we dat een vlak tweedimensionaal is.

[Voor 54% gewijzigd door .oisyn op 06-12-2010 00:32]

[Gamebuster]

.oisyn schreef op zondag 05 december 2010 @ 23:13:
Pose, al heeft dat voor niet-rigide objecten een wat uitgebreidere betekenis (zoals bijv. ook alle bone matrices). Overigens klopt je terminologie sowieso niet. Één coördinaat is een enkel getal. Iets als (100, 300) bestaat dus uit 2 coördinaaten. Ik zou het gewoon position of origin noemen (en je type ook even renamen).

Rare naam; nooit van gehoord. -maar bedankt

En dat Coordinate was me idd niet eens opgevallen Zal voortaan Position gebruiken.

[Bahmi]

Op de HU werkt ik met een groep aan een spelletje (Game design & Technology), hier is hoe wij het gedaan hebben, misschien heb je er wat aan.

De root van alles is de Component class, die zorgt voor het registreren van het object aan de engine, en zitten wat virtual functions in zodat je makkelijker door je gameobjects looped.

Dan hebben we 2 interfaces, een I3DComponent en I2DComponent, en die bevatten positie,rotatie in de wereld. Dit is om de draworder wat gemakkelijk te maken, zodat we de gui altijd over de rest van de scene tekenen.

De rest van de componenten zijn verdeeld over 2 namespaces, en wat losse componenten.

Als losse componenten hebben we Actor (3D model in 3d space), GuiElement, Camera, ParticleSystem etc.

De twee namespaces zijn Components (die van de rootcomponent inheriten, dus niet in de 3D wereld leven, denk aan de network/input handlers etc) en Entities (die een I2D of I3D interface hebben, dus 'echte' objecten in het spel).

Van daaruit is het een clusterfsck van klasses en om dat uit te leggen heb ik een heel groot schema nodig, 5 maanden development met 4 man gaat hard.

Ook, voor de I2D en I3D interfaces, dit zijn allemaal properties met getters en setters om te kijken of er geen onzin in word gepropt:

I2D:
Vector2 Position
float Rotation
Vector2 Scale
Rectangle BoundingBox

I3D
Vector3 Position
Matrix Rotation
Vector3 Scale
BoundingBox BoundingBox (ja, origineel)
, en nog wat dingen om het gemakkelijk te maken
Vector3 RotationAsEuler
Quaternion RotationAsQuat
Vector3 PositionPrev
Vector3 Velocity

Spel is in C# dus alles beginnen met een hoofdletter .