Tile probleem

[P-Storm]

Om het gelijk beter uit te leggen. Ik wil van de ene subclasse naar de andere subclass. Aangezien het niet realiseerbaar is zoals ik het wil en ik nog niet alle kennis van de taal heb, vermoed ik dat het ligt aan hoe de subclass gemaakt zijn. Het ligt vast welke subclasse naar een andere subclasse verwijst. In dit geval TileF veranderd altijd in een TileE.

Stel ik heb de volgende code:

C#:

abstract class Tile{
   public abstract int Number{ get; }
   public Vector2 Position {get;set;}
   public abstract void Exit()
}
class TileF : Tile{
public override int Number
        {
            get
            {
                return 1;
            }
        }
} 
class TileE : Tile{
public override int Number
        {
            get
            {
                return 2;
            }
        }
} 

Nu wil ik tile in een andere subclass veranderen.

C#:

class Main{
Tile tile = new TileF;
//change tile to TileE
tile = tile.ToNextTileType();

}

Ik heb dit geprobeerd op te lossen door Activator.CreateInstance(tile.NextType()), maar dan krijg ik een object eruit, die ik voor geen mogelijkheid kan veranderen in de type in tile.NextType().

Ook lukt het me met een grote if statement, maar dat lijkt me ook niet de optie. Dit omdat er een stuk of 12 classes er zijn, en je zou toch iets makkelijkers verwachten.

C#:

if tile is TileF
//in de constructor de tile meegeven om de propertys zoals Positie mee te geven
tile = new TileE(tile)
if tile is TileE
tile = new TileD(tile)
if tile is TileD
tile = new TileC(tile)

[RobIII]

Waar hoort mijn topic?
SEA >> PRG (je hebt 't hier namelijk over een C# specifieke vraag; dit heeft niets met 't ontwerpen van te maken)

[ Voor 32% gewijzigd door RobIII op 20-09-2011 13:53 ]

[Herko_ter_Horst]

Doe even een stapje terug en geef even iets meer context over wat het probleem is dat je hiermee denkt op te lossen.

Een aantal vragen daarbij:

1. Ben je bekend met het begrip polymorfisme?
2. Waarom moet je het type van de subclass weten? M.a.w. waarom is het niet voldoende te weten dat "getNextTile" een Tile retourneerd, ongeacht van welk subtype deze is?
3. Waarom zijn Tiles zelf verantwoordelijk voor het opleveren van de nextTile/nextTileType?

[ Voor 61% gewijzigd door Herko_ter_Horst op 20-09-2011 13:56 ]

[P-Storm]

RobIII schreef op dinsdag 20 september 2011 @ 13:53:
Waar hoort mijn topic?
SEA >> PRG (je hebt 't hier namelijk over een C# specifieke vraag; dit heeft niets met 't ontwerpen van te maken)

Mijn vermoeden ligt aan het verkeerd opzetten van de classes, en daarom dacht ik dat dit meer een SEA vraag was.

Herko_ter_Horst schreef op dinsdag 20 september 2011 @ 13:53:
Doe even een stapje terug en geef even iets meer context over wat het probleem is dat je hiermee denkt op te lossen.

Een aantal vragen daarbij:

1. Ben je bekend met het begrip polymorfisme?
2. Waarom moet je het type van de subclass weten? M.a.w. waarom is het niet voldoende te weten dat "getNextTile" een Tile retourneerd, ongeacht van welk subtype deze is?
3. Waarom zijn Tiles zelf verantwoordelijk voor het opleveren van de nextTile/nextTileType?

Om de vragen te beantwoorden

1. Ik ben bekend met polymorfisme, alleen heb het volgens mij nog niet voldoende onder controle, vandaar deze vraag.
2. Wat je hier aangeeft zou een oplossing kunnen zijn. Door een Tile door te geven, wordt de collectie ook gewoon goed aangepast. Even een kleine case schrijven voor de laatste Tile die niks door kan geven, ofwel vernietigen (misschien null) ofwel verbergen, maar dat zal het de moeilijkheid niet zijn.
3. Ik probeer zo min mogelijk elke subclasse van Tile te checken, omdat het een gegeven is dat elke tile het moet hebben. Daarom neem ik (misschien onterrecht) aan dat de subclasses van Tile er verantwoordelijk voor moeten zijn.

[Herko_ter_Horst]

Als je nu het probleem/de context nog even uit de doeken doet, dan kunnen we je beter helpen om te bepalen of dit een goede oplossing is.

Wat ben je aan het maken? Een bordspel? Een citybuilder spel? Iets heel anders?

En wat is de bedoeling van de getNextTile/Type methode? Wie gaat die aanroepen en wat gaat er vervolgens met het resultaat gebeuren?

offtopic:
Ben het overigens met je eens m.b.t. SEA vs PRG: dit is een OO-ontwerpvraag, geen C#-issue.

[ Voor 16% gewijzigd door Herko_ter_Horst op 20-09-2011 14:14 ]

[P-Storm]

Ik ben bezig om een clone/port te maken voor Pyramids of Ra. Beetje lastig om te omschrijven maar een alle hokjes afgaan voordat je het level klaar hebt.

De Update methode roept de getNextTile aan, en veranderd de collectie die de Tiles vastheeft. De resulataat wordt vervolgens in de update van de Tiles (zoals beweging of animatie) en daarna ook de draw (dus het laten zien van de Tiles)

[Herko_ter_Horst]

Ik zou niet elke Tile verantwoordelijk maken voor een volgende tile, maar ik zou er een speelbord of speelveld class tussen zetten.

Ik heb overigens net even snel een paar levels gespeeld, maar ik zie nog geen verschil tussen de tiles (m.u.v. het startveld). Wat stellen de verschillende Tile subclasses voor?

[P-Storm]

Als je de demo een laat afdraaien (geen knoppen indrukken na game options), krijg je al snel bounce tiles. Dit is een voorbeeld van een veranderde Tile. De verschillen van de subclasses zijn:

C#:

public abstract bool Destructable { get; }
public abstract Vector2 TexturePosition { get; }
public virtual void Enter()
public virtual void Exit()
public virtual void Draw(GameTime gameTime)
public virtual void Update(GameTime gameTime)

Daarnaast heb ik ook animated tiles (zie bijvoorbeeld de start en de ronddraaiende jumppad), die hebben ook nog:

C#:

protected abstract TimeSpan AnimationTime { get; }
protected abstract int TotalFrames { get; }
public override void Draw(GameTime gameTime)
public override void Update(GameTime gameTime)

En voor de subklasses (heb er wat weggelaten):

Tile->OneTouch (1 keer aanraken en zijn weg)
Tile->TwoTouch (1 keer aanraken en na animatie wordt OneTouch)
..
Tile->AnimatedTile->Start (Knippert telkens)
Tile->AnimatedTile->RotatingJump(Veranderd telkens van richting)

[Herko_ter_Horst]

Ok, helder m.b.t. de verschillende tile-subclasses.

Klopt het dat getNextTileType gaat over bijv. de overgang van TwoTouch naar OneTouch? Ik vraag me in dat geval af of het nodig is dit met een nieuwe tile van een ander type op te lossen, maar ik ken niet alle mogelijke overgangen.

TwoTouch + OneTouch zou ik in elk geval vervangen door NTouch(int n), waarbij je na elke "touch" de variabele n aflaagt. Dan hou je gewoon dezelfde Tile, maar wijzig je z'n interne state. Afhankelijk van hoe je de types kiest en welke overgangen mogelijk zijn, kun je zonder type-verandering en in plaats daarvan alles met interne state-wijzigingen oplossen.

Is er ergens een overzicht van de regels m.b.t. hoe tiles zich gedragen?

P.S. let ook nog even op dat je netjes scheiding aanbrengt tussen de visuele aspecten van een tile en zijn gedrag in termen van de regels van het spel (zie ook MVC pattern).

[ Voor 15% gewijzigd door Herko_ter_Horst op 20-09-2011 14:52 ]

[P-Storm]

De enigste mogelijkheden van overgang zijn

• Ntouch

• Niets


Dus het lijkt erop dat ik veel te moeilijk dacht ervoor. Ik kan dus beter een NTouch maken, en daarbij de interne state bij houden.

Om voor de volledigheid een overzicht te hebben van Tile effecten:

OneTouch->Mag maar 1 keer op staan
TwoTouch->Mag maar 2 keer op staan, veranderd in OneTouch
ThreeTouch->Mag maar 3 keer op staan, veranderd in TwoTouch
InfinityTouch->Mag je zo vaak op staan, doet verder niks
Reverse->Mag maar 1 keer op staan, keert je beweging om
Jump->Mag je zo vaak als je wilt op staan, beweegt je naar bepaalde locatie gelijk.
RotateJump->Mag je zo vaak als je wilt op staan, beweegt je naar bepaalde locatie gelijk.
HMirror->Spiegeld de speelveld horizontaal, bewegingen worden niet gespiegeld.
VMirror->Spiegeld de speelveld verticaal, bewegingen worden niet gespiegeld.
Start->Hier kom je uit en moet je weer in
Unknown->Random effect van een hier boven behalve start en RotateJump

Movables->Dit wordt een aparte klasse die beweegt.

Die scheiding waar je het over hebt, kan ik zeker gebruiken. Even opzoeken hoe je dit netjes kan doen, heb jij daar een makkelijke link over (ik zoek zelf ook links, maar misschien heb je er een in favoriete die heel makkelijk/duidelijk is)

[ Voor 10% gewijzigd door P-Storm op 20-09-2011 14:59 ]

[Herko_ter_Horst]

Ja, die One/Two/ThreeTouch zou ik zeker vervangen door NTouch.

M.b.t. het splitsen van gedrag en GUI: ik zou geen AnimatedTile subclass maken in je Tile hierarchie, maar al het gedrag m.b.t. het tekenen van de tile uitbesteden aan een view-class. Een link m.b.t. MVC heb ik zo niet voor je, maar Googlen op MVC pattern, al dan niet i.c.m. "C# example", zou behoorlijk wat informatie moeten opleveren.

[ Voor 5% gewijzigd door Herko_ter_Horst op 20-09-2011 15:15 ]