Klassediagram project

[Verwijderd]

Bij wijze van differentiatie/minorproject hebben we een RTSGame gemaakt. Dat hebben we inmiddels afgerond, het is niet bepaald een grafisch meesterwerk, maar 'it does the trick'.


Nu het achter de rug is, vind ik het eigenlijk zonde om alles af te schrijven en wil ik er een beetje aan werken als hobbyproject. Probleem is alleen dat het een verschrikkelijke ononderhoudbare bende is geworden als gevolg van slecht plannen, modelleren en veel pleiterwerk toepassen. Nu ben ik wel in voor een beetje uitdaging en wil ik het klassendiagram eens helemaal om gaan gooien en wat een wat beter design toe te passen.

Ik ben dus aan de slag gegaan en heb tot nu toe dit (ja, erg groot, maar resizen maakt onleesbaar ben ik bang):

Units, Buildings en Resources heb ik volgens mij vrij goed ontworpen, gedrag niet in de units zelf, HAS-A relaties, geen IS-A.

Maar dan begin ik te twijfelen. Het idee is dat elk van de 3 genoemde items een GameObject is, een dergelijke GameObject heeft een plekje op een Map (of Tile). Ik wil graag dat GameObject de positie bijhoudt, immers als een GameObject het weet, weet een Building of Unit het ook. Op deze manier is het GameObject verantwoordelijk van haar positie op de Map.
Tips van harte welkom


Over het game/server aspect wil ik het nog even niet hebben, maar het idee wat ik ga implementeren is als volgt: elk spel is in principe een netwerkspel, met mogelijkheden voor AI (alhoewel onze AI niet echt een AI te noemen is ). Maar dit ligt nog een beetje open.

[Michali]

Niet echt een opmerking mbt. de inhoud van je post, maar een gestippelde lijn met een lege pijl is (volgens mij) in UML een 'realisation', dus bijvoorbeeld een class die een interface implementeert. Het lijkt er echter op dat je het gebruikt voor classes die een afhankelijkheid hebben op de betreffende interface. Ik zou hiervoor gewoon een associatie gebruiken. Een beetje verwarrend, dus misschien handig om even aan te passen.

Als ik het mis heb mag iemand me corrigeren, graag zelfs.

[Verwijderd]

Daar kan je best wel eens gelijk in hebben, zal m'n boeken er eens bij pakken.

[curry684]

Verwijderd schreef op vrijdag 15 februari 2008 @ 21:02:
Units, Buildings en Resources heb ik volgens mij vrij goed ontworpen, gedrag niet in de units zelf, HAS-A relaties, geen IS-A.

Wat is er mis met IS-A relaties? Verder moeten bepaalde stukken gedrag natuurlijk wel in de units zelf, omdat het unieke properties van de units zijn. Ik denk dat je bedoelt dat je de aansturing er buiten hebt gehouden, en dat is natuurlijk wel correct (zodat je verschillende input-methods en/of AI-algoritmes er naadloos aan kunt pluggen).

Ik denk ook dat je map wat vreemd in elkaar zit, hoe heb je nu movementalgoritmes geimplementeerd als je van Tile een rich class maakt?

[Verwijderd]

Ik denk dat je bedoelt dat je de aansturing er buiten hebt gehouden, en dat is natuurlijk wel correct (zodat je verschillende input-methods en/of AI-algoritmes er naadloos aan kunt pluggen).

Daar doelde ik inderdaad op ja


Ik zit te denken aan het volgende, met betrekking tot de map:

De map is eigenlijk een 2dimensionaal assenstelsel, met op elk punt (x, y) een tile (eigenlijk ís elk punt (x, y) een tile), zo'n tile kan een GameObject bevatten (wat dus units, buildings of resources zijn) en heeft dus een referentie naar GameObject (nu weet een tile dus wat er op staat, maar verder niets van de map). Een tile heeft dan ook methodes voor het plaatsen en verwijderen van objecten (bewegen is, in deze opzet, ook niets anders dan van tile verwijderen en op een andere tile plaatsen).

Het selecteren van een, bijvoorbeeld, een unit wordt afgehandeld door de Player klasse. Men klikt, er wordt bepaald waar er geklikt wordt, stel dat er op de map, op een tile geklikt wordt, word aan de tile gevraagd wat er op staat en is dat een unit van de player zelf wordt deze geselecteerd (meerdere units kan ook door verslepen). Vervolgens wijs je een andere tile aan en kun je de unit daar naartoe sturen.

Het path wordt bepaald door de Map klasse (de heeft een datastructuur met alle tiles van de map en kan dus aan elk tile vragen of ze traversable is), die aan de unit een path meegeeft. Dit is uitgerekend met A* dus zal objecten ontwijken. Mocht er een andere unit in de weg lopen, wordt de weg naar het eindpunt opnieuw berekend.

[Verwijderd]

Na enig aankloten wil ik uiteindelijk dit ontwerp voor de unit structuur gaan gebruiken:

Het is verre van compleet, maar het geeft in ieder geval mijn idee vrij goed weer (mijn UML skills hebben nog wat werk nodig, dus niet alle lijntjes en multipliciteiten zullen goed kloppen, daar ben ik van op de hoogte, maar heb momenteel geen zin om een UML boek door te nemen aangezien ik nog verschillende andere boeken heb liggen welke voorrang hebben).

C#:

public static void Main(string[] args)
{
    Player sebas = new Player("sebas");

    sebas.AddGameObjectToPlayer(new Farmer(new AttackDisabled()));
    sebas.IterateGameObjects();

    Player henk = new Player("Henk");
    henk.AddGameObjectToPlayer(new Swordsman(new AttackWithSword()));
    henk.AddGameObjectToPlayer(new Spearman(new AttackWithSpear()));
    henk.IterateGameObjects();

    Console.ReadKey();
}

Ik heb wel besloten de grafische code te herschrijven naar DirectX code, op het moment is er nog Irrlicht gebruikt als middleware, maar ik vind het een beetje een houtje touwtje ding en heb erg dikke directx tutorials (Riemers). Dankzij een combinatie van beiden kan ik redelijk eenvoudig mijn Tile systeem omzetten. Waar ik me dus de komende weken/dagen mee bezig zal gaan houden.

GameTicker zorgt elke x miliseconden voor een event, op basis van dit event worden, bijvoorbeeld resources toegevoegd of een aanval uitgevoerd.

Edit:
Het hele unit systeem heb ik even apart geschoven en teruggebracht tot een gameobject. De verdere specialisatie is in dit stadium niet nodig.
Eerst ben ik het fenomeen gamestates aan het introduceren, wat in ons oude spel eh... niet bestond Dat levert geen problemen op en werkt gewoon prima.

Ik heb nu een vrij eenvoudige 2d map, die in een Form van boven zichtbaar is, elke tile bestaat uit 4 vertices (Vector4(x,y,z,h)) die door een trianglefan beschouwd wordt als 2 triangles.
Waar ik eigenlijk niet echt bij stil heb gestaan, nog, is de manier waarop ik door middel van toveren met camera's deze map kan renderen als vogelvlucht perspectief.
Is dit uberhaupt mogelijk?

[ Voor 38% gewijzigd door Verwijderd op 25-02-2008 16:06 ]

[AtleX]

Waarom die AttackWith* objecten? Waarom geen Weapon waarvan de verschillende wapens (Sword, Spear) overerven? Dan kan je het later eventueel eenvoudiger uitbreiden naar iets waarbij een speler meerdere wapens kan hebben. Bij een speler zonder wapen (Farmer) kan je dan de attackBehaviour (die je hernoemd naar weapon) op null laten staan.

[ Voor 4% gewijzigd door AtleX op 02-03-2008 19:46 ]

[Laurens-R]

Ik mis nog een game-state object... ik zie wel een klasse 'game' maar ik zie daar alleen een map object en nog iets anders in.

Hoe houd je de state van je game bij? Je hebt bijvoorbeeld je type units gespecificeerd, maar hoe houd je de instanties daarvan bij en in welke staat ze zijn? Denk hierbij ook aan de state van de game wereld, etc, etc,

[ Voor 9% gewijzigd door Laurens-R op 02-03-2008 20:13 ]

[Verwijderd]

Ik mis nog een game-state object... ik zie wel een klasse 'game' maar ik zie daar alleen een map object en nog iets anders in.

Die state had ik nog niet verwerkt in dit diagram en aangezien ik een paar dagen weg ben geweest heb ik het er van het weekend ook niet meer in kunnen bouwen. Morgenavond ga ik weer een uurtje aan het diagram verder en verwerk ik de state er in (was overigens wel aan het experimenteren met een bepaalde opzet in een los project, maar die is nog underway). Game state is iets wat zeker niet vergeten gaat worden.

Hoe houd je de state van je game bij? Je hebt bijvoorbeeld je type units gespecificeerd, maar hoe houd je de instanties daarvan bij en in welke staat ze zijn? Denk hierbij ook aan de state van de game wereld, etc, etc,

De instanties van Units worden bijgehouden in een (UI/AI)Player object middels een datastructuur, dit is momenteel nog een ArrayList, maar dat ga ik pas optimaliseren als ik m'n eerste milestone heb gehaald (een game met beperkte hoeveelheid units, buildings en resources, die de mogelijkheid biedt tegen een AI te spelen, net zover als het oude project ongeveer was).

De state van units moet ook nog gemodelleerd worden, een unit kan zich in een aantal toestanden bevinden, maar hiervoor geldt hetzelfde als voor de gamestate, het zit er nog niet in

Waarom die AttackWith* objecten? Waarom geen Weapon waarvan de verschillende wapens (Sword, Spear) overerven? Dan kan je het later eventueel eenvoudiger uitbreiden naar iets waarbij een speler meerdere wapens kan hebben. Bij een speler zonder wapen (Farmer) kan je dan de attackBehaviour (die je hernoemd naar weapon) op null laten staan.

Het is in principe zo opgezet dat een unit maar 1 wapen tegelijk kan dragen, maar op deze manier is het wel mogelijk om van wapen te wisselen (strategy). In principe doe je hetzelfde, maar met een iets ander naampje, of zie ik dat verkeerd?