Archief - Scheiding Model - 'View'

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

ultddave

Legacy Member
Beste,

Ik heb een vraag aangaande gamedevelopment.
Op school heb ik geleerd dat we voor gewone desktop applications, (eg een boekhoudprogramma) best de model/logic van de visuele representatie scheiden (idem bij websites etc). Dat is logisch en niet zo moeilijk.

Maar hoe zit dat met games (die gebruik maken van OpenGL bijvoorbeeld)?
Stel bijvoorbeeld een shooter of een bordspel.

Daarin kunnen we veel klassen definiëren voor onze model. maar om het simpel te houden, veronderstellen we enkel de klasse van een vijand.

Code:
Class Enemy
{
    id : int
    position : Point(int, int) 
    weapons : Array<Weapon>
    hitpoints : int
    ...    
}

Die vijand heeft uiteraard ook een 3D model. Is het dan de bedoeling om dit in de model/logic bij te houden?

Code:
Class Enemy
{
    id : int
    position : Point(int, int) 
    weapons : Array<Weapon>
    hitpoints : int
    ...
    model : String /* (de filename van de model) */
}

Zelfde scenario bij bijvoorbeeld een bordspel zoals schaken.

Daarin kan je bijvoorbeeld de volgende klasse definiëren (we laten overerving even buiten beschouwing).

Code:
Class King
{
     id : int
     position : Point(int, int)
     ...
     picture : String /* filename van de 2D afbeelding */
}

Is dit een goede manier? Of hoe wordt dit meestal gedaan?

Op internet zijn er veel tutorials te vinden, maar sommige lijken outdated en van andere is het dan weer moeilijk om te weten of het "de juiste aanpak" is.

Dank bij voorbaat.

Mvg,
Dave

KiPpIe

Legacy Member
Het is niet omdat er een beschrijving van iets visueel in uw klasse zit dat het daarom niet meer "gescheiden" is, he.
Het is data die bij de logische eenheid hoort, dus steek het in uw klasse (model).

Bij een spel kunt ge de view dan best aanzien als de rendering engine, die de visuele representatie van uw eenheiden/models gaat doen.

Nepherte

Legacy Member
Het representatie-gedeelte in uw model bijhouden is geen goed idee. Stel dat je meerdere representaties hebt van uw model (bv. meerdere themes voor uw schaakstukken), ga je ze dan allemaal bijhouden in uw model...? Het lijkt mij logischer dat de representatie bijhoudt wat het aan het voorstellen is.

Daedie

Legacy Member
Uw case is eigenlijk net een goed voorbeeld van hoe het niet moet :p. Het idee van model - view (- controller) is net om ervoor te zorgen dat uw model helemaal geen kennis hoeft te hebben van de representatie. Het model moet eigenlijk maar net genoeg informatie bevatten om de logic te laten functioneren (en die string draagt daar niet aan bij).

Voor game design is het veel moeilijker om uw architectuur in dit soort model te gieten omdat de representatie vaak wel invloed heeft op uw logic. De vormgeving van uw enemy bepaalt bijvoorbeeld ook zijn bounding box wat belangrijk kan zijn voor interactie tussen entity's (collision), dat maakt die lijn tussen model en view troebel.

Hier kunt ge lezen over een toepassing van MVC voor game design.

Ik kan u ook aanraden om wat opzoekwerk te doen over het Entity/Component model, wat veel typischer toegepast wordt binnen het domein van game engine architectuur. En ook geschikter is naar mijn mening. Ook hier heeft gamasutra interessante artikels over.

Uw schaaktoepassing is dan wel weer gemakkelijker, omdat de representatie helemaal geen invloed heeft op het spelverloop. Hier zou ge bijvoorbeeld MVC kunnen toepassen door een interface te voorzien naar uw gamelogic waarmee ge de input (zetten doen) en output (welke piece staat waar) voorziet. Uw view kan deze interface gebruiken om een visuele representatie te maken van uw speelveld. Als uw view voor ieder type schaakstuk een resource (picture) heeft ingeladen en van ieder vakje uit uw speel veld kan opvragen welk type schaakstuk erop staat is het triviaal om het speelveld te tekenen (op welke manier dan ook).

ultddave

Legacy Member
Het representatie-gedeelte in uw model bijhouden is geen goed idee. Stel dat je meerdere representaties hebt van uw model (bv. meerdere themes voor uw schaakstukken), ga je ze dan allemaal bijhouden in uw model...?
Goed punt. ;)

Daedie zei:
Uw case is eigenlijk net een goed voorbeeld van hoe het niet moet :p.
Hehe :P. Vandaar dat ik het wilde vragen. ^^

Daedie zei:
Het idee van model - view (- controller) is net om ervoor te zorgen dat uw model helemaal geen kennis hoeft te hebben van de representatie. Het model moet eigenlijk maar net genoeg informatie bevatten om de logic te laten functioneren (en die string draagt daar niet aan bij).
True. ;)

Daedie zei:
Voor game design is het veel moeilijker om uw architectuur in dit soort model te gieten omdat de representatie vaak wel invloed heeft op uw logic.
Inderdaad, vandaar dat ik er problemen mee had.

De vormgeving van uw enemy bepaalt bijvoorbeeld ook zijn bounding box wat belangrijk kan zijn voor interactie tussen entity's (collision), dat maakt die lijn tussen model en view troebel.
Inderdaad.

Daedie zei:
Hier kunt ge lezen over een toepassing van MVC voor game design.
Erg bedankt, heb het toegevoegd aan mijn favorieten, zal het binnekort eens allemaal doorlezen ;).

Daedie zei:
Ik kan u ook aanraden om wat opzoekwerk te doen over het Entity/Component model, wat veel typischer toegepast wordt binnen het domein van game engine architectuur. En ook geschikter is naar mijn mening. Ook hier heeft gamasutra interessante artikels over.
Ok, thanks :D.

Daedie zei:
Uw schaaktoepassing is dan wel weer gemakkelijker, omdat de representatie helemaal geen invloed heeft op het spelverloop. Hier zou ge bijvoorbeeld MVC kunnen toepassen door een interface te voorzien naar uw gamelogic waarmee ge de input (zetten doen) en output (welke piece staat waar) voorziet. Uw view kan deze interface gebruiken om een visuele representatie te maken van uw speelveld. Als uw view voor ieder type schaakstuk een resource (picture) heeft ingeladen en van ieder vakje uit uw speel veld kan opvragen welk type schaakstuk erop staat is het triviaal om het speelveld te tekenen (op welke manier dan ook).
True, nice ;). Ja ik was van plan om eerst een "mini-game" te maken, 2D, zoiets zoals schaken, dammen of eventueel iets zoals Sudoku. En dan iets meer geavanceerd proberen te ontwikkelen.

In ieder geval, erg bedankt voor jullie feedback ;).

Mvg,
Dave

NeverwinterX

Legacy Member
Let wel op dat als het hier gaat over een echte AAA 3D game waar performance belangrijk is, dat men vaak zijn voeten veegt (in gradaties) aan model-view of zelfs aan OO principes om het laatste beetje performance eruit te persen.

kwitters

Legacy Member
Daedie zei:
Voor game design is het veel moeilijker om uw architectuur in dit soort model te gieten omdat de representatie vaak wel invloed heeft op uw logic. De vormgeving van uw enemy bepaalt bijvoorbeeld ook zijn bounding box wat belangrijk kan zijn voor interactie tussen entity's (collision), dat maakt die lijn tussen model en view troebel.

Die lijn is inderdaad soms troebel. Bij bounding boxes en collisions valt het nog mee, omdat de physics engine volledig in het model zit.

Bij 2D games is het soms iets moeilijker, bv als je pixel-perfect collision detection doet. Maar in dat geval is er ook een oplossing :). Je kan je sprite of 3D model als 'resource' beschouwen, en zowel je model en view hebben een referentie naar deze resource. Op deze manier kan je model er toch gebruik van maken, en blijft het onafhankelijk van je view. Je view object bevat meestal ook meer functionaliteit dan je graphics resource.

Zoals ik in de post hierboven al heb aangehaald, gaat MVC eigelijk ook goed samen met een component based engine. In dat geval heb je 3 types van componenten: models, views en controllers. Alle componenten voor de render engine zijn bv toch views, etc.

ultddave

Legacy Member
@Kwitters; Erg bedankt, beide links even toegevoegd aan mijn favorieten. Na de herexamens zal ik ze eens doorlezen :D.

Mvg,
Dave
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan