![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
[Project] Oh Oh Schaak! Deel 1
Hallo iedereen,
Vandaag iets heel nieuws. Een blog over de initialisatie van een nieuw project voor MicroSE. Namelijk het "OO-Schaak" project. Dit gaat mijn eerste serieuze game worden. En gaat geheel Object Oriented worden.
Een korte beschrijving van het schaakspel. Het wordt door twee spelers gespeeld op een speelbord met 64 witte of zwarte vlakken. Op dit bord staan 32 stukken (16 per speler: 8 pionnen, 2 torens, 2 lopers, 2 paarden, een koningin en een koning). Elk verschillend stuk heeft zijn eigen unieke zetten. Het spel is afgelopen wanneer een speler de koning van zijn tegenstander kan slaan zonder dat hij daar iets tegen kan doen.
Ook zijn er speciale voorwaarden waarop een spel beslist wordt, maar dit volgt later.
Nu gaan we even kijken wat allemaal entiteiten gaan worden in het nieuwe systeem:
Spel, Speler, Stuk, Pion, Toren, Paard, Loper, Koning, Koningin en Zet.
Veld of Vlak lijkt me geen entiteit gezien elk stuk weet op welke coördinaat hij staat.
Zo kom ik tot de volgende UML diagram (eigenschappen / methodes zijn nog niet ingevuld)
Nu gaan we de attributen toekennen. We beginnen met Spel. Deze heeft een bepaalde spelstand (0 bezig, 1 wit gewonnen, 2 zwart gewonnen en 3 remise) dus een integer / enum. Verder heeft deze niet direct eigen attributen.
Daarna hebben we speler. Deze heeft als attribute welke spelkleur hij heeft (1 wit, 2 zwart), wat zijn naam is en wat zijn ELO rating is.
Vervolgens hebben we Zet. Deze kent een Van en Naar coördinaat als ook het gezette stuk als welk stuk er geslagen kan worden / is. En of de uitkomst van de zet Schaak is.
Nu bemerk ik dat Coördinaat als een Entiteit nodig is. Deze geven we een X (int) en een Y (int), zo hebben we dus bv { X = '4', Y = '5' } (D5)
Vervolgens hebben we Stuk. Deze weet welke kleur hij heeft (1 wit, 2 zwart) verder weet deze op welk coördinaat hij staat en welke zetten hij kan doen.
Als we aan Stuk een enum toevoegen met welk soort hij is is de generalisatie eronder geheel overbodig. Het is niet nodig dat een stuk weet of hij aangevallen wordt. Wel willen we weten of een stuk in zijn beginstand staat. (voor rokeren bv) en willen we weten of "en passant"-slaan mogelijk is.
Dit levert uiteindelijk de volgende UML op. (ineens een stukje kleiner
)
Dingen als schaakklok, schaakregels, etc zitten er nog niet in.. Die komen de volgende keer.
Laat hieronder weten wat jullie van dit ontwerp vinden
Maar gedraag je!
Vandaag iets heel nieuws. Een blog over de initialisatie van een nieuw project voor MicroSE. Namelijk het "OO-Schaak" project. Dit gaat mijn eerste serieuze game worden. En gaat geheel Object Oriented worden.
Een korte beschrijving van het schaakspel. Het wordt door twee spelers gespeeld op een speelbord met 64 witte of zwarte vlakken. Op dit bord staan 32 stukken (16 per speler: 8 pionnen, 2 torens, 2 lopers, 2 paarden, een koningin en een koning). Elk verschillend stuk heeft zijn eigen unieke zetten. Het spel is afgelopen wanneer een speler de koning van zijn tegenstander kan slaan zonder dat hij daar iets tegen kan doen.
Ook zijn er speciale voorwaarden waarop een spel beslist wordt, maar dit volgt later.
Nu gaan we even kijken wat allemaal entiteiten gaan worden in het nieuwe systeem:
Spel, Speler, Stuk, Pion, Toren, Paard, Loper, Koning, Koningin en Zet.
Veld of Vlak lijkt me geen entiteit gezien elk stuk weet op welke coördinaat hij staat.
Zo kom ik tot de volgende UML diagram (eigenschappen / methodes zijn nog niet ingevuld)
Nu gaan we de attributen toekennen. We beginnen met Spel. Deze heeft een bepaalde spelstand (0 bezig, 1 wit gewonnen, 2 zwart gewonnen en 3 remise) dus een integer / enum. Verder heeft deze niet direct eigen attributen.
Daarna hebben we speler. Deze heeft als attribute welke spelkleur hij heeft (1 wit, 2 zwart), wat zijn naam is en wat zijn ELO rating is.
Vervolgens hebben we Zet. Deze kent een Van en Naar coördinaat als ook het gezette stuk als welk stuk er geslagen kan worden / is. En of de uitkomst van de zet Schaak is.
Nu bemerk ik dat Coördinaat als een Entiteit nodig is. Deze geven we een X (int) en een Y (int), zo hebben we dus bv { X = '4', Y = '5' } (D5)
Vervolgens hebben we Stuk. Deze weet welke kleur hij heeft (1 wit, 2 zwart) verder weet deze op welk coördinaat hij staat en welke zetten hij kan doen.
Als we aan Stuk een enum toevoegen met welk soort hij is is de generalisatie eronder geheel overbodig. Het is niet nodig dat een stuk weet of hij aangevallen wordt. Wel willen we weten of een stuk in zijn beginstand staat. (voor rokeren bv) en willen we weten of "en passant"-slaan mogelijk is.
Dit levert uiteindelijk de volgende UML op. (ineens een stukje kleiner
)Dingen als schaakklok, schaakregels, etc zitten er nog niet in.. Die komen de volgende keer.
Laat hieronder weten wat jullie van dit ontwerp vinden
Maar gedraag je!
06-'12 De maand juni
05-'12 Mei-update MicroSE: MicroSE JumpIt 0.0.7.6
Reacties
Door
t-town,
maandag 21 mei 2012 22:57
Waarom werk je met een int voor de spelkleur bij Speler? Het lijkt me beter een enumeration of eventueel een boolean te gebruiken. Hoe ga je bepalen welke zetten een stuk kan doen? Hier is overerving toch wel de ideale aanpak, lijkt me.
Door
JaHetIsChris,
maandag 21 mei 2012 22:58
Ik zou enum gebruiken voor je spelkleur ja
Door
Gropah,
maandag 21 mei 2012 23:01
En dan komt natuurlijk ook de vraag: welke taal?
Door
edeboeck,
maandag 21 mei 2012 23:03
Sander,
ik zou de associatie tussen Spel en Zet eerder als volgt definiëren: Spel 1--1..* Zet
(ok, ik weet dat dat er verder niet zo gek veel toe doet en dat je kan argumenteren dat dat bijvoorbeeld 1--4..* moet zijn ... ik weet niet wat het minimum aantal zetten is). Of ga je uit van een opgave nog voor een zet gedaan is?
Stuk zou ik wel degelijk als abstracte klasse houden en werken met zijn childclasses... met een methode "VerplaatsRadius" (of zoiets) zou je dan de mogelijke doelcoördinaten kunnen opvragen (handig als je de speler hierover ondersteuning wilt geven).
Bedoel je met "en passant" slaan de beweging van de pion? Is dit dan echt nodig? Wat ik bedoel is: stel dat een stuk, naast bovenvermelde "VerplaatsRadius", ook een "SlaRadius" heeft... op die manier is dat "en passant" overbodig... wat volgens mij ook uit de logica van het spel lijkt: het is geen doel op zich om te weten of een stuk "en passant" kan slaan... wel of stuk X stuk Y kan slaan of niet.
Just my 2 cents...
ik zou de associatie tussen Spel en Zet eerder als volgt definiëren: Spel 1--1..* Zet
(ok, ik weet dat dat er verder niet zo gek veel toe doet en dat je kan argumenteren dat dat bijvoorbeeld 1--4..* moet zijn ... ik weet niet wat het minimum aantal zetten is). Of ga je uit van een opgave nog voor een zet gedaan is?
Stuk zou ik wel degelijk als abstracte klasse houden en werken met zijn childclasses... met een methode "VerplaatsRadius" (of zoiets) zou je dan de mogelijke doelcoördinaten kunnen opvragen (handig als je de speler hierover ondersteuning wilt geven).
Bedoel je met "en passant" slaan de beweging van de pion? Is dit dan echt nodig? Wat ik bedoel is: stel dat een stuk, naast bovenvermelde "VerplaatsRadius", ook een "SlaRadius" heeft... op die manier is dat "en passant" overbodig... wat volgens mij ook uit de logica van het spel lijkt: het is geen doel op zich om te weten of een stuk "en passant" kan slaan... wel of stuk X stuk Y kan slaan of niet.
Just my 2 cents...
Door
RobIII,
maandag 21 mei 2012 23:13
Die intelligentie (logica) stop je niet in een stuk maar in Spel of (AI)Speler. Je gaat geheid in de knoei komen als je straks een spel gestart bent en de stukken moeten allemaal op eigen houtje 't spel gaan "aftasten" naar wat wel/niet aan zetten mogelijk is (en wat de consequenties daarvan zijn!). Daarbij kan spel prima bijhouden (als je dat überhaupt al wil; de lijst met zetten even afscannen is in no-time gedaan) of een stuk nog in beginstand staat of niet e.d.Vervolgens hebben we Stuk. Deze weet ... welke zetten hij kan doen
...
Wel willen we weten of een stuk in zijn beginstand staat. (voor rokeren bv) en willen we weten of "en passant"-slaan mogelijk is.
Zie 't zo: wie speelt 't spel in een daadwerkelijk (irl) potje? De stukken? Of de ("AI") speler?
Voor "Zet" is de bool "Schaak" niet boeiend; dat bepaalt "Spel" wel; "Zet" is niets meer dan een dom object om in een lijst te proppen met "coördinaten" zoals jij dat noemt.
edit:
Mja, misschien is 't wel leuk om per zet te weten of de stand toen schaak was of niet come to think of it, maar (ook) dat lijkt me nu nog helemaal niet relevant
Mja, misschien is 't wel leuk om per zet te weten of de stand toen schaak was of niet come to think of it, maar (ook) dat lijkt me nu nog helemaal niet relevant
Voor een eerste (5 minuten) schets is dit idee wel leuk maar je weet natuurlijk dat hier nog een he-le-boel ontbreekt. Dan zie ik even niet waarom je wel ELO er al in betrekt; hoe is dat relevant op dit niveau of in deze fase?
Ga je dit helemaal op eigen houtje uitvogelen of ga je, "standing on the shoulders of giants", eerst kijken hoe anderen het hebben aangepakt en daar je eigen versie op baseren of van afleiden of ideeën opdoen? En zo ja/nee, waarom wel/niet?
[Reactie gewijzigd op maandag 21 mei 2012 23:27]
Door
Adion,
maandag 21 mei 2012 23:16
Is Coordinaat overigens niet gewoon een eigenschap van Zet en van Stuk, eerder dan een relatie?
Dus iets als:
Zet
-start : Coordinaat
-eind :Coordinaat
Stuk
-positie : Coordinaat
Verder lijkt het me dat elke Coordinaat bij hooguit 1 Zet hoort, maar vanuit Coordinaat lijkt het zoiezo niet erg nuttig om expliciet terug te kunnen gaan naar Zet of Stuk.
Dus iets als:
Zet
-start : Coordinaat
-eind :Coordinaat
Stuk
-positie : Coordinaat
Verder lijkt het me dat elke Coordinaat bij hooguit 1 Zet hoort, maar vanuit Coordinaat lijkt het zoiezo niet erg nuttig om expliciet terug te kunnen gaan naar Zet of Stuk.
Door
CodeCaster,
maandag 21 mei 2012 23:40
Leuk plan!
Qua feedback: waarom heb je niet toch een Veld-klasse?
Daarin kun je dan het Stuk opslaan dat erop staat, net als de Coördinaat van het Veld op het bord. Vervolgens kun je een property IsBezet maken, die simpelweg (this.Stuk != null) retourneert.
Zo kan een Zet simpelweg een BeginVeld en een EindVeld hebben (en wellicht is een volgnummer ook handig).
Als dan !EindVeld.IsBezet en Zet.IsGeldig (waarin dan weer wordt uitgerekend of er überhaupt een Stuk op het BeginVeld staat, of de verplaatsing wel mag voor dat type stuk, of het EindVeld wel Stuk bevat, en van welke Speler dat Stuk dan is), wordt het Stuk van BeginVeld naar EindVeld verplaatst. Een eventueel reeds op EindVeld aanwezig Stuk kan dan mooi van het bord worden geveegd.
Of wilde je bij iedere zet door alle Stukken loopen?
Qua feedback: waarom heb je niet toch een Veld-klasse?
Daarin kun je dan het Stuk opslaan dat erop staat, net als de Coördinaat van het Veld op het bord. Vervolgens kun je een property IsBezet maken, die simpelweg (this.Stuk != null) retourneert.
Zo kan een Zet simpelweg een BeginVeld en een EindVeld hebben (en wellicht is een volgnummer ook handig).
Als dan !EindVeld.IsBezet en Zet.IsGeldig (waarin dan weer wordt uitgerekend of er überhaupt een Stuk op het BeginVeld staat, of de verplaatsing wel mag voor dat type stuk, of het EindVeld wel Stuk bevat, en van welke Speler dat Stuk dan is), wordt het Stuk van BeginVeld naar EindVeld verplaatst. Een eventueel reeds op EindVeld aanwezig Stuk kan dan mooi van het bord worden geveegd.
Of wilde je bij iedere zet door alle Stukken loopen?
[Reactie gewijzigd op maandag 21 mei 2012 23:42]
Door
sanderev66,
maandag 21 mei 2012 23:41
Visio heeft geen gfx voor "enumeration" heb ik naar gekeken. Dus is het nu nog een int maar het wordt uiteindelijk een enum.t-town schreef op maandag 21 mei 2012 @ 22:57:
Waarom werk je met een int voor de spelkleur bij Speler? Het lijkt me beter een enumeration of eventueel een boolean te gebruiken. Hoe ga je bepalen welke zetten een stuk kan doen? Hier is overerving toch wel de ideale aanpak, lijkt me.
C#Gropah schreef op maandag 21 mei 2012 @ 23:01:
En dan komt natuurlijk ook de vraag: welke taal?
Het kan vanaf het begin zijn, dus er hoeven nog geen zetten gedaan te zijn.edeboeck schreef op maandag 21 mei 2012 @ 23:03:
Sander,
ik zou de associatie tussen Spel en Zet eerder als volgt definiëren: Spel 1--1..* Zet
(ok, ik weet dat dat er verder niet zo gek veel toe doet en dat je kan argumenteren dat dat bijvoorbeeld 1--4..* moet zijn ... ik weet niet wat het minimum aantal zetten is). Of ga je uit van een opgave nog voor een zet gedaan is?
Stuk weet welke velden er toegankelijk zijn voor dat stuk.Stuk zou ik wel degelijk als abstracte klasse houden en werken met zijn childclasses... met een methode "VerplaatsRadius" (of zoiets) zou je dan de mogelijke doelcoördinaten kunnen opvragen (handig als je de speler hierover ondersteuning wilt geven).
En passant is een speciale pion slag waarbij je een pion die voorbij gaat slaat (dit dus als je tegenstander je pion probeert te ontwijken door bij een openingszet twee vakken ipv 1 vak naar voren te gaan) Dit kan alleen in de hierop volgende zet.Bedoel je met "en passant" slaan de beweging van de pion? Is dit dan echt nodig? Wat ik bedoel is: stel dat een stuk, naast bovenvermelde "VerplaatsRadius", ook een "SlaRadius" heeft... op die manier is dat "en passant" overbodig... wat volgens mij ook uit de logica van het spel lijkt: het is geen doel op zich om te weten of een stuk "en passant" kan slaan... wel of stuk X stuk Y kan slaan of niet.
True, maar ik had het nog niet over logica. Een stuk kent zijn mogelijke posities niet die hij al gehad heeft. Deze komen onder spel.RobIII schreef op maandag 21 mei 2012 @ 23:13:
[...]
Die intelligentie (logica) stop je niet in een stuk maar in Spel of (AI)Speler. Je gaat geheid in de knoei komen als je straks een spel gestart bent en de stukken moeten allemaal op eigen houtje 't spel gaan "aftasten" naar wat wel/niet aan zetten mogelijk is (en wat de consequenties daarvan zijn!). Daarbij kan spel prima bijhouden (als je dat überhaupt al wil; de lijst met zetten even afscannen is in no-time gedaan) of een stuk nog in beginstand staat of niet e.d.
Het spel lijkt mij.Zie 't zo: wie speelt 't spel in een daadwerkelijk (irl) potje? De stukken? Of de ("AI") speler?
Dat is precies wat ik ook dachtVoor "Zet" is de bool "Schaak" niet boeiend; dat bepaalt "Spel" wel; "Zet" is niets meer dan een dom object om in een lijst te proppen met "coördinaten" zoals jij dat noemt.
edit:
Mja, misschien is 't wel leuk om per zet te weten of de stand toen schaak was of niet come to think of it, maar (ook) dat lijkt me nu nog helemaal niet relevant
De bool schaak is voor een eventuele toekomstige AI.Die kan idd nog wel wegblijvenVoor een eerste (5 minuten) schets is dit idee wel leuk maar je weet natuurlijk dat hier nog een he-le-boel ontbreekt. Dan zie ik even niet waarom je wel ELO er al in betrekt; hoe is dat relevant op dit niveau of in deze fase?
Nee, ik ga mijn eigen implementatie maken om zo meer van het schrijven van een dergelijke implementatie te leren.Ga je dit helemaal op eigen houtje uitvogelen of ga je, "standing on the shoulders of giants", eerst kijken hoe anderen het hebben aangepakt en daar je eigen versie op baseren of van afleiden of ideeën opdoen? En zo ja/nee, waarom wel/niet?
Dat is idd een slim idee, je gaat al wel iets verder dan mijn eerste opzet. Maar verder goed denkwerk!CodeCaster schreef op maandag 21 mei 2012 @ 23:40:
Waarom heb je niet toch een Veld-klasse?
Daarin kun je dan het Stuk opslaan dat erop staat, net als de Coördinaat van het Veld op het bord. Vervolgens kun je een property IsBezet maken, die simpelweg (this.Stuk != null) retourneert.
Zo kan een Zet simpelweg een BeginVeld en een EindVeld hebben (en wellicht is een volgnummer ook handig).
Als dan !EindVeld.IsBezet en Zet.IsGeldig (waarin dan weer wordt uitgerekend of er überhaupt een Stuk op het BeginVeld staat, of de verplaatsing wel mag voor dat type stuk, of het EindVeld wel Stuk bevat, en van welke Speler dat Stuk dan is), wordt het Stuk van BeginVeld naar EindVeld verplaatst. Een eventueel reeds op EindVeld aanwezig Stuk kan dan mooi van het bord worden geveegd.
Of wilde je bij iedere zet door alle Stukken loopen?
Ik ga nu slapen, maar morgen zal ik jullie goede adviezen verwerken.
[Reactie gewijzigd op dinsdag 22 mei 2012 07:35]
Door
croontje,
dinsdag 22 mei 2012 01:04
Leuk idee! Dit volg ik zeker verder 
Door
sanderev66,
dinsdag 22 mei 2012 07:26
Het idee om een schaakspel te maken is gister in me opgekomen. Het leek me ook leuk om iedereen in het creatieve proces te betrekken. Dus van stap 1 tot het uiteindelijke spel, je gaat het allemaal hier lezen.
Dit past mijn inziens beter bij tweakblogs dan alleen releases posten zoals ik deed.
Misschien ga ik nog een topic in Programming maken voor een wat makkelijkere discussie.
Dit past mijn inziens beter bij tweakblogs dan alleen releases posten zoals ik deed.
Misschien ga ik nog een topic in Programming maken voor een wat makkelijkere discussie.
[Reactie gewijzigd op dinsdag 22 mei 2012 07:28]
Door
Lukosje,
dinsdag 22 mei 2012 13:25
De relatie tussen stuk en coordinaat klopt volgens mij niet helemaal? Een stuk heeft altijd 1 coordinaat (dat is correct) maar een coordinaat heeft geen of 1 stuk (dus niet altijd 1). Of interpreteer ik het nu verkeerd?
Door
SeatRider,
dinsdag 22 mei 2012 13:39
Was de eerste naam toevallig "Oh Oh Chesso"?
Door
TJHeuvel,
dinsdag 22 mei 2012 13:43
Doe je de namen van je klasses bewust in het Nederlands? Persoonlijk zou ik voor Engels gaan namelijk
Door
ZpAz,
dinsdag 22 mei 2012 14:50
Oh Oh Chesso is een stuk leuker imho
Door
sanderev66,
dinsdag 22 mei 2012 16:21
Tijdens het ontwerp is alles Nederlands, er is een vertaalslag wanneer ik ga programmeren.TJHeuvel schreef op dinsdag 22 mei 2012 @ 13:43:
Doe je de namen van je klasses bewust in het Nederlands? Persoonlijk zou ik voor Engels gaan namelijk
Wie weet
Nee, je hebt gelijk...Lukosje schreef op dinsdag 22 mei 2012 @ 13:25:
De relatie tussen stuk en coordinaat klopt volgens mij niet helemaal? Een stuk heeft altijd 1 coordinaat (dat is correct) maar een coordinaat heeft geen of 1 stuk (dus niet altijd 1). Of interpreteer ik het nu verkeerd?
[Reactie gewijzigd op dinsdag 22 mei 2012 16:22]
Door
Hmail,
dinsdag 22 mei 2012 16:50
Wat stelt de boolean enPassant voor? Dat het stuk op dit moment en passant kan slaan, of dat het een stuk is die eventueel zo zou kunnen slaan (dus een pion)?
En dan mis je nog rocheren.. Daarvoor moet je ook bijhouden of een stuk al een zet heeft gehad, en of één van de velden aangevallen staat of bezet staat.
En dan mis je nog rocheren.. Daarvoor moet je ook bijhouden of een stuk al een zet heeft gehad, en of één van de velden aangevallen staat of bezet staat.
Door
sanderev66,
dinsdag 22 mei 2012 23:59
Nou..
Ik heb een nieuw UML diagram gemaakt door jullie input mee te nemen en de eerste (mijn inziens logische) methodes toe te kennen. Ook heb ik een nieuwe klasse (Regelement) en is het me toch gelukt om enums in Visio te maken. Na goed zoeken.
Hier is model nummer 3:
http://tweakers.net/ext/f/sUO7t28VaLKMeKzyDs6xDXdP/full.png
Als jullie nog meer opmerkingen hebben... laat maar weten
Ik heb een nieuw UML diagram gemaakt door jullie input mee te nemen en de eerste (mijn inziens logische) methodes toe te kennen. Ook heb ik een nieuwe klasse (Regelement) en is het me toch gelukt om enums in Visio te maken. Na goed zoeken.
Hier is model nummer 3:
http://tweakers.net/ext/f/sUO7t28VaLKMeKzyDs6xDXdP/full.png
Als jullie nog meer opmerkingen hebben... laat maar weten
Door
dusty,
woensdag 23 mei 2012 01:04
Dan hier een vraag; Waarom ga je uit van de stukken die op een bord staan, en niet uit van een bord die stukken bevat?Nee, ik ga mijn eigen implementatie maken om zo meer van het schrijven van een dergelijke implementatie te leren.
Heb je over het verschil nagedacht? Want er zit nogal een verschil in en zal ook invloed hebben op de manier waarop je je AI zal gaan implementeren.
Door
sanderev66,
woensdag 23 mei 2012 07:30
Ik heb beide nog open. Het spelbord, oftewel Spel, kent twee tot 32 stukken. Een stuk kent 1 spel. Ik heb nog niets over de richting van de associatie bepaald.
Ik denk dat het bidirectioneel wordt. Want je wil op een bepaald moment gaan controleren of een stuk geslagen is, of niet.
En nu ik me dit bedenk moet de associatie tussen Stuk en Veld aan beide kanten 0...1 zijn. Want een geslagen stuk staat niet op een veld.
Daarbij wordt de AI waarschijnlijk een los project, misschien zelfs een competitie onder Tweakers gezien ik de game zo wil maken dat de AI als module geïnstalleerd kan worden.
Tijd voor model 4, want pionnen kunnen nog Promoveren!
http://tweakers.net/ext/f/r7BPFaiUu3EjgKF5sRghrKxZ/full.png
Ik denk dat het bidirectioneel wordt. Want je wil op een bepaald moment gaan controleren of een stuk geslagen is, of niet.
En nu ik me dit bedenk moet de associatie tussen Stuk en Veld aan beide kanten 0...1 zijn. Want een geslagen stuk staat niet op een veld.
Daarbij wordt de AI waarschijnlijk een los project, misschien zelfs een competitie onder Tweakers gezien ik de game zo wil maken dat de AI als module geïnstalleerd kan worden.
Tijd voor model 4, want pionnen kunnen nog Promoveren!
http://tweakers.net/ext/f/r7BPFaiUu3EjgKF5sRghrKxZ/full.png
[Reactie gewijzigd op woensdag 23 mei 2012 07:44]
Door
elvin,
woensdag 23 mei 2012 09:13
Werk je altijd in het Nederlands?
Door
sanderev66,
woensdag 23 mei 2012 12:10
Ontwerpfase wel ja.
Door
Mediarange3,
woensdag 23 mei 2012 17:52
Lol waarom kost dit zoveel moeite? Je hebt toch hbo gedaan? Als je werkelijk hbo hebt gedaan had je dit in het eerste blok al gehad.
En je was toch tegen OOP? Of kunnen we nu de conclusie trekken dat je geen OOP gebruikt omdat je het gewoon niet kan?
En je was toch tegen OOP? Of kunnen we nu de conclusie trekken dat je geen OOP gebruikt omdat je het gewoon niet kan?
[Reactie gewijzigd op woensdag 23 mei 2012 17:57]
Door
sanderev66,
woensdag 23 mei 2012 22:36
Bedankt mensen voor het helpen met het verbeteren van mijn klassendiiagram Dit is tot nu toe de tweede keer dat ik voor een (toekomstig) MicroSE programma vooraf een UML diagram gemaakt heb. Hij is nog niet af, zoals we in vervolg posts zullen zien, maar het begin is er.
Ik denk dat ik zo het standaard schaakspel zonder te veel poeha naar een klassendiagram omgezet heb. De volgende post zal meer over een implementatie van de schaaksport gaan. Zoals ranking, rating, extra regels en natuurlijk de schaakklok. (En ja, ik ben officieel schaaksporter)
@Mediarange3: ik maak mijn software zoals mij dat goeddunkt. Ik bepaal bij initiatie van een project welke methodes ik daarvoor ga gebruiken. Dat ik in veel MicroSE projecten geen OO gebruik betekend niets anders dan dat ik het voor dat bepaalde project niet nuttig vind. (mening, betwistbaar maar niet discutabel) bij een schaakspel vind ik dat het wel nuttig is om dit OO te doen (mening). Dus dan doe ik dit ook.
Dan heb ik 2 keuzes: alles prive houden en jullie eens per maand een download aanbieden, of jullie vanaf punt 1 in het creatieve te betrekken.
Dat laatste heb ik nog niet eerder gedaan en het leek mij een goede uitdaging om de communicatie onderling te verbeteren. Dus dank je wel om dat weer te willen verstieren!
Dit is tot nu toe de tweede keer dat ik voor een (toekomstig) MicroSE programma vooraf een UML diagram gemaakt heb. Hij is nog niet af, zoals we in vervolg posts zullen zien, maar het begin is er. Ik denk dat ik zo het standaard schaakspel zonder te veel poeha naar een klassendiagram omgezet heb. De volgende post zal meer over een implementatie van de schaaksport gaan. Zoals ranking, rating, extra regels en natuurlijk de schaakklok. (En ja, ik ben officieel schaaksporter
)@Mediarange3: ik maak mijn software zoals mij dat goeddunkt. Ik bepaal bij initiatie van een project welke methodes ik daarvoor ga gebruiken. Dat ik in veel MicroSE projecten geen OO gebruik betekend niets anders dan dat ik het voor dat bepaalde project niet nuttig vind. (mening, betwistbaar maar niet discutabel) bij een schaakspel vind ik dat het wel nuttig is om dit OO te doen (mening). Dus dan doe ik dit ook.
Dan heb ik 2 keuzes: alles prive houden en jullie eens per maand een download aanbieden, of jullie vanaf punt 1 in het creatieve te betrekken.
Dat laatste heb ik nog niet eerder gedaan en het leek mij een goede uitdaging om de communicatie onderling te verbeteren. Dus dank je wel om dat weer te willen verstieren!
offtopic:
En in het eerste blok @HBO moest ik een simpele PHP website maken met in totaal 0% aan OO.
En in het eerste blok @HBO moest ik een simpele PHP website maken met in totaal 0% aan OO.
[Reactie gewijzigd op woensdag 23 mei 2012 22:44]
Door
Hmail,
donderdag 24 mei 2012 09:09
Hoe kent het veld het stuk wat er staat? En hoe weet je wie er schaak staat? Als wit zijn loper wegzet en daardoor zwart schaak zet is dat een volledig legitieme zet, maar als hij zijn loper wegzet en daardoor schaak komt te staan is die zet niet toegestaan.
En wat bedoel je met 'extra regels'? Ik mis trouwens nog steeds rocheren.
En wat bedoel je met 'extra regels'? Ik mis trouwens nog steeds rocheren.
Door
sanderev66,
donderdag 24 mei 2012 09:51
Al dat zit in Reglement Die bepaalt per zet welke zetten er mogelijk is en controleert of een zet toegestaan is. Die kan dus zien of je mag rokeren, etc.
Die bepaalt per zet welke zetten er mogelijk is en controleert of een zet toegestaan is. Die kan dus zien of je mag rokeren, etc.
Door
Wes,
dinsdag 29 mei 2012 07:45
Een interessant project. Je klassediagram zit aardig in elkaar maar ik heb nog wel wat vragen. Ik hoop dat ik nog niet te laat ben met reageren.
- Waar zit je inputhandling?
- Waar zit je rendering/drawing?
[Reactie gewijzigd op dinsdag 29 mei 2012 07:47]
Door
sanderev66,
dinsdag 29 mei 2012 11:23
Nergens nog, daar gaat het nog niet over. Ben in zijn geheel nog niet bezig geweest met hoe het spel er uit gaat zien, en hoe het gespeeld moet wordenWezz6400 schreef op dinsdag 29 mei 2012 @ 07:45:
Een interessant project. Je klassediagram zit aardig in elkaar maar ik heb nog wel wat vragen. Ik hoop dat ik nog niet te laat ben met reageren.
- Waar zit je inputhandling?
- Waar zit je rendering/drawing?
je wil ook een history / mogelijkhedenlijst met zetten hebben.Verder vraag ik me af wat de functie van de Zet klasse is. Een zet is het verplaatsen van een stuk, dat is dus een handeling. Je verplaatst het stuk, maar het belangrijkste is dat het een nieuwe positie in het veld krijgt. Ik zou er dus een functie in veld van maken met een stuk als argument.
[Reactie gewijzigd op dinsdag 29 mei 2012 11:25]
Door
Wes,
dinsdag 29 mei 2012 19:03
Het lijkt me toch handig daar vanaf het begin aan te denken, het is een essentieel onderdeel van je spel en kan best invloed hebben op hoe je ontwerp in elkaar zit.sanderev66 schreef op dinsdag 29 mei 2012 @ 11:23:
[...]
Nergens nog, daar gaat het nog niet over. Ben in zijn geheel nog niet bezig geweest met hoe het spel er uit gaat zien, en hoe het gespeeld moet worden
History kan ik me nog iets bij voorstellen, maar met een mogelijkhedenlijst ben je me kwijt.je wil ook een history / mogelijkhedenlijst met zetten hebben.
Wat ga je daar precies mee doen?
Door
sanderev66,
dinsdag 29 mei 2012 22:26
We zitten nog vóór het beginWezz6400 schreef op dinsdag 29 mei 2012 @ 19:03:
[...]
Het lijkt me toch handig daar vanaf het begin aan te denken, het is een essentieel onderdeel van je spel en kan best invloed hebben op hoe je ontwerp in elkaar zit.
Rendering en inputhandling gaan in de de view en controller klassen verwerkt worden. Wat je nu nog gezien hebt zijn de modelklassen. I/O is daar geen onderdeel in. (Dat is dan ook de driedeling) Van de VC klassen komt hoogstens ook alleen een Visual Studio Klassendiagram en geen volledig UML diagram.Bv voor de AI die kan bepalen waar een bepaald stuk naartoe kan gaan. (Deze kan dan weer gecontroleerd worden met Reglement) ook kan het handig zijn voor de GUI om aan beginnende spelers een mogelijk pad te kunnen tonen. Deze informatie is daarom wel belangrijk om in het Model te hebben.[...]
History kan ik me nog iets bij voorstellen, maar met een mogelijkhedenlijst ben je me kwijt.
[Reactie gewijzigd op dinsdag 29 mei 2012 22:28]
Door
ThaStealth,
vrijdag 01 juni 2012 20:49
@ je laatste diagram
- Ik mis de relaties, welke classes kennen elkaar en welke niet (aka, welke class heeft de verwijzing naar de andere class)
-in de Stuk class heb je beginstand gedefinieerd, in de pion class "en passant" (dit is neem ik aan dat je de pion in het begin 2 velden vooruit mag schuiven), dit is dubbelop aangezien type == pion && beginstand == en passant toegestaan
- Je hebt weging dubbel gedefinieerd (in de subclasses als in de Stuk class)
- Veld class is overbodig als je bij het stuk de locatie implementeerd, je weet alle stukken + je weet hun coordinaten, je kan dus bepalen of een veld vol is niet vol is
- De class Spel zal de class regelement bevatten, niet andersom verwacht ik? Dan is de relatie 1 op 1, niet veel op 1
- Regelement kun je ook weglaten en aan de stukken vragen welke mogelijke zetten hun kunnen doen. Zo krijg je een stuk gestructureerdere mogelijkheden.
De hele Zet class is alleen voor het historisch bijhouden van de zetten, als je een stuk verwijderd (= in jouw schema uit de verzameling gooien) raak je de historie kwijt
- Ik mis de relaties, welke classes kennen elkaar en welke niet (aka, welke class heeft de verwijzing naar de andere class)
-in de Stuk class heb je beginstand gedefinieerd, in de pion class "en passant" (dit is neem ik aan dat je de pion in het begin 2 velden vooruit mag schuiven), dit is dubbelop aangezien type == pion && beginstand == en passant toegestaan
- Je hebt weging dubbel gedefinieerd (in de subclasses als in de Stuk class)
- Veld class is overbodig als je bij het stuk de locatie implementeerd, je weet alle stukken + je weet hun coordinaten, je kan dus bepalen of een veld vol is niet vol is
- De class Spel zal de class regelement bevatten, niet andersom verwacht ik? Dan is de relatie 1 op 1, niet veel op 1
- Regelement kun je ook weglaten en aan de stukken vragen welke mogelijke zetten hun kunnen doen. Zo krijg je een stuk gestructureerdere mogelijkheden.
De hele Zet class is alleen voor het historisch bijhouden van de zetten, als je een stuk verwijderd (= in jouw schema uit de verzameling gooien) raak je de historie kwijt
Door
sanderev66,
zaterdag 02 juni 2012 15:20
Daar zijn de lijntjes voor. Of bedoel je de richtingen van de associaties? Dat volgt pas op een véél later stadium.ThaStealth schreef op vrijdag 01 juni 2012 @ 20:49:
@ je laatste diagram
- Ik mis de relaties, welke classes kennen elkaar en welke niet (aka, welke class heeft de verwijzing naar de andere class)
Voor de 10e keer, nee.-in de Stuk class heb je beginstand gedefinieerd, in de pion class "en passant" (dit is neem ik aan dat je de pion in het begin 2 velden vooruit mag schuiven), dit is dubbelop aangezien type == pion && beginstand == en passant toegestaan
Lees dit als je wilt weten wat en passant is: http://en.wikipedia.org/wiki/En_passant
Jep.- Je hebt weging dubbel gedefinieerd (in de subclasses als in de Stuk class)
Een stuk weet op welk veld hij staat. Een zet is een verplaatsing van Veld naar Veld.- Veld class is overbodig als je bij het stuk de locatie implementeerd, je weet alle stukken + je weet hun coordinaten, je kan dus bepalen of een veld vol is niet vol is
Nee andersom. Een regelement kent meerdere spellen. Er is namelijk maar 1 schaak regelement, alle schaakspellen voldoen aan dezelfde set regels.- De class Spel zal de class regelement bevatten, niet andersom verwacht ik? Dan is de relatie 1 op 1, niet veel op 1
Bv een koning weet niet of hij een vak kruist die door een ander stuk aangevallen staat.- Regelement kun je ook weglaten en aan de stukken vragen welke mogelijke zetten hun kunnen doen. Zo krijg je een stuk gestructureerdere mogelijkheden.
Er staan heel duidelijk 2 lijntjes naar zet. Eén van Spel en één van Stuk. Dit zijn dan ook twee associaties vanuit twee verschillende klassen en een zet zal altijd in één van die twee te vinden zijn. Vanuit Stuk zijn het MOGELIJKE zetten, vanuit Spel zijn het UITGEVOERDE zetten.De hele Zet class is alleen voor het historisch bijhouden van de zetten, als je een stuk verwijderd (= in jouw schema uit de verzameling gooien) raak je de historie kwijt
Als je het schaakspel snapt, dan snap je ook mijn diagram.
Ik heb het laatste diagram vertaald en omgezet naar klassen in VS 2012 RC, hier heb ik ook een Visual Studio Class Diagram (LETOP: dit is geen UML diagram!) van gemaakt
Zie: http://tweakers.net/ext/f/wCmsTweKSYbgIrrjkk9YRjGt/full.png
[Reactie gewijzigd op zaterdag 02 juni 2012 17:17]
Reageren is niet meer mogelijk