[C++] OOP aan een game beginnen

[Gideonnn]

Omdat ik tijdens mijn aankomende studie (informatica) een minor in c++ of game development wil doen ben ik me aan het voorbereiden. Ik heb net een drie jarige MBO studie (applicatie ontwikkelaar) afgerond dus ik ben al wel bekend met programmeren.

Tot nu toe heb ik redelijk wat gemaakt op de OOP manier, maar nu ik begonnen ben aan een simpele game kan ik het me zó moeilijk voorstellen hoe ik te werk moet gaan.

Dus nu mijn vraag, waar moet ik beginnen? Als ik zoek op games incl source dan kan ik vrij weinig vinden. Ook ben ik nu een boek aan het lezen maar ik kom eigenlijk alleen maar simpele voorbeeldjes tegen.


Edit:
Ik ben op het moment een extreem versimpelde versie van Geometry Wars aan het maken. Op het moment is moven en schieten werkend. Ook is collision enzo geen probleem.

Hoe ik OOP geleerd heb is het 3 tier systeem, één laag voor data, één voor logica en één voor weergeven. Dat is alleen niet zo van toepassing in games (lijkt mij), Ik kwam als aller eerst een probleem tegen tijdens het moven van mijn player, ik had dit zoveel mogelijk in mijn player class gedaan. Toen werd mij aangeraden door iemand op mijn stage bedrijf dat dat niet slim was. Maar is een class om te moven gebruikelijk, of gewoon direct in main?

[ Voor 32% gewijzigd door Gideonnn op 19-06-2013 21:09 ]

[Verwijderd]

Ik denk dat het ook een beetje ligt aan wat je wilt gaan gebruiken om het spel mee te maken? (OpenGL, DirectX, etc.)

Wanneer je dat weet kun je wel een aantal gerichte tutorials vinden rond dit onderwerp denk ik zo?

[Janoz]

Wat is er aan de game dan zo anders dan al die eerdere applicaties die je 'op de OOP manier' gemaakt hebt? Het helpt wanneer je iets meer verteld over wat voor soort game je uberhaupt wilt maken en waarom je vindt dat je game zo anders is dan andere software.

[Daos]

Waarom C++? Puzzelspelletjes voor je Android-telefoon gaan in een soort aangepaste Java. Voor Windows kan je makkelijker iets maken in C#/XNA. Voor websites in Flash.

[ Voor 11% gewijzigd door Daos op 19-06-2013 21:02 ]

[Robbiedobbie]

Zelf vind ik deze website erg interessant om te lezen voor allemaal design problemen bij games:
http://fabiensanglard.net/

[Umbrah]

http://www.altdevblogaday...-processing-architecture/

Goed artikel, programmeren is in principe programmeren, taal/framework is wel relevant, maar in mijn optiek is programmeren slechts 20% van de taak. Als ik jou was zal ik eens kijken naar je architectuur. Je design. Dat soort vraagstukken, ,en dan je pas zorgen gaan maken over hetgeen wat bij ELKE, maar dan ook ELKE game hetzelfde is:

Fetch (inpute), Execute (process), Draw (update)

Pas als de rest goed is, je ontwerp, je doel, je verhaal; zeg maar: je project, dan zorgen maken over de hulpmiddelen (frameworks/talen), en daarna pas: het werkelijke programmeren. C++ is immers ook maar een taal. Je kan er desnoods zelfs Java Frameworks, Python Frameworks, Dalvik Frameworks of .Net frameworks mee aansturen.

Waarom overigens niet programmeren in LOLCODE?

[ Voor 27% gewijzigd door Umbrah op 19-06-2013 20:57 ]

[Zoijar]

Misschien kan je beter eerst eens kijken naar dingen zoals unity3d.

[Gideonnn]

Ik heb inderdaad heel weinig verteld over wat ik aan het maken ben, ik zal even mijn originele post editten.

[ZpAz]

Ook ben ik nu een boek aan het lezen maar ik kom eigenlijk alleen maar simpele voorbeeldjes tegen.

Klinkt misschien cru, maar daar zul je het eerst mee moeten doen. Wanneer je die "simpele voorbeeltjes" zelf goed kan maken zou je na kunnen denken over de "grotere" spellen.

[Gideonnn]

ZpAz schreef op woensdag 19 juni 2013 @ 21:08:
[...]


Klinkt misschien cru, maar daar zul je het eerst mee moeten doen. Wanneer je die "simpele voorbeeltjes" zelf goed kan maken zou je na kunnen denken over de "grotere" spellen.

Ze helpen wel wat, maar ik kan het eigenlijk allemaal al. In mijn opleiding stond C# centraal, is iets meer high level, maar het idee is hetzelfde. Ik heb ook heel basic C++ gehad, maar dat ging meer over het pointer/adressen idee dan echt iets maken.

Alvast bedankt voor de suggesties, heb ik wat te doen vanavond!


@Umbrah Het klopt wel, maar ik heb bijvoorbeeld XNA gedaan, maar dat is niet zo interessant omdat dat wel lukt allemaal. Het gaat me juist om het C++ deel, omdat je meer low level kan gaan is het erg interessant. Maar ik heb wat pointers (no pun!) nodig om hier OOP mee aan de slag te gaan.

Ik merk dat ik heel erg graag dingen weg wil stoppen en in wil delen, maar dan te erg.

[ Voor 23% gewijzigd door Gideonnn op 19-06-2013 21:14 ]

[Umbrah]

Het is maar een taal, welk framework probeer je aan te spreken? C++ is net zo leveled als C# als je het wilt; mijn opmerking over LOLCODE slaat niet zomaar op niks! Probeer je met GCC te compilen richting SDIO? (Y)ASM te callen? Of probeer je de W32 API aan te spreken/DX/OGL? C++ en C# zijn beiden 3rd gen languages... en je kunt er in principe hetzelfde mee. De compiler en het framework maken alles uit.

Dus nogmaals: waarin probeer je te programmeren? C++ en XNA? Ik geloof niet in talen C# en LOLCODE kunnen net zo goed pointers hebben.

code:

HAI
BTW This is a BrainFuck interpreter written in LOLCode
BTW It accepts as input a BF program, followed by a "!", followed  by any input to the BF program.
BTW Since BrainFuck is turing-complete, this proves that LOLCode is too

I HAS A INSTRUCTIONS    BTW Array for BF instructions
I HAS A IPTR            BTW Pointer to first empty element in INSTRUCTIONS
LOL IPTR R 0
I HAS A LOOPZ            BTW Array of loop start/end addresses
I HAS A LOOPSTACKZ        BTW Loop stack for building the above two
I HAS A LSPTR            BTW Pointer to first empty element of LOOPSTACKZ
LOL LSPTR R 0

BTW Read in BF instructions, terminated with "!"
IM IN YR CODE
  GIMMEH LETTAR IPTR IN MAH INSTRUCTIONS
  
  IZ IPTR IN MAH INSTRUCTIONS LIEK "["?
    LOL LSPTR IN MAH LOOPSTACKZ R IPTR
    UPZ LSPTR!!
  KTHX
  
  IZ IPTR IN MAH INSTRUCTIONS LIEK "]"?
    I HAS A STARTPTR
    NERFZ LSPTR!!
    LOL STARTPTR R LSPTR IN MAH LOOPSTACKZ
    LOL STARTPTR IN MAH LOOPZ R IPTR
    LOL IPTR IN MAH LOOPZ R STARTPTR
  KTHX

  IZ IPTR IN MAH INSTRUCTIONS LIEK "!"?
    GTFO
  NOWAI
    UPZ IPTR!!
  KTHX    
KTHX

BTW Variables for BF's tape
I HAS A LTAPE
I HAS A RTAPE
I HAS A LPTR
LOL LPTR R 0
I HAS A RPTR
LOL RPTR R 0
I HAS A CELL
LOL CELL R 0

BTW Reset instruction pointer to start
LOL IPTR R 0

BTW Start interpreting
IM IN YR LOOP
  I HAS A THING
  LOL THING R IPTR IN MAH INSTRUCTIONS
  
  BTW Move tape head right
  IZ THING LIEK ">"?
    LOL LPTR IN MAH LTAPE R CELL
    UPZ LPTR!!
    IZ RPTR LIEK 0?
      LOL CELL R 0
    NOWAI
      NERFZ RPTR!!
      LOL CELL R RPTR IN MAH RTAPE
    KTHX
  KTHX
  
  BTW Move tape head left
  IZ THING LIEK "<"?
    LOL RPTR IN MAH RTAPE R CELL
    UPZ RPTR!!
    IZ LPTR LIEK 0?
      LOL CELL R 0
    NOWAI
      NERFZ LPTR!!
      LOL CELL R LPTR IN MAH LTAPE
    KTHX
  KTHX
  
  BTW Increment
  IZ THING LIEK "+"?
    UPZ CELL!!
  KTHX
  
  BTW Decrement
  IZ THING LIEK "-"?
    NERFZ CELL!!
  KTHX
  
  BTW Output produces numbers instead of ASCII characters
  IZ THING LIEK "."?
    VISIBLE CELL!
    VISIBLE " "!
  KTHX
  
  BTW Input doesn't work because we can't convert characters to integers
  BTW Oh well, it doesn't stop it being turing complete
  
  BTW Start of loop
  IZ THING LIEK "[" AND CELL LIEK 0?
    LOL IPTR R IPTR IN MAH LOOPZ
  KTHX
  
  BTW End of loop
  IZ THING LIEK "]" AND CELL NOT LIEK 0?
    LOL IPTR R IPTR IN MAH LOOPZ
  KTHX
  
  BTW End of program!
  IZ THING LIEK "!"?
    GTFO
  KTHX
  
  UPZ IPTR!!
KTHX
KTHXBYE

edit:
Vervloek dit forum met geen code-highlighting voor Lolcode!

[ Voor 75% gewijzigd door Umbrah op 19-06-2013 21:51 ]

[Gideonnn]

Umbrah schreef op woensdag 19 juni 2013 @ 21:45:
Het is maar een taal, welk framework probeer je aan te spreken? C++ is net zo leveled als C# als je het wilt; mijn opmerking over LOLCODE slaat niet zomaar op niks! Probeer je met GCC te compilen richting SDIO? (Y)ASM te callen? Of probeer je de W32 API aan te spreken/DX/OGL? C++ en C# zijn beiden 3rd gen languages... en je kunt er in principe hetzelfde mee. De compiler en het framework maken alles uit.

Dus nogmaals: waarin probeer je te programmeren? C++ en XNA? Ik geloof niet in talen C# en LOLCODE kunnen net zo goed pointers hebben.

*knip*

edit:
Vervloek dit forum met geen code-highlighting voor Lolcode!

Haha, lolcode ziet er heel grappig uit. Ik was er net een mini tutorial over aan het kijken. Het ligt misschien ook niet aan de taal, maar ik wil C++ graag als minor gaan doen, daarom zou ik graag wat extra met die taal omgaan. Omdat ik naar de gaming kant neig is dat op dit moment mijn hobby project.

Ik probeer te werken met SFML 2.0 en straks met Box2D (zit er al in maar doe ik nog niks mee).

[NC83]

Heb je gamedev.net al geprobeerd. Codesampler.com is ook een goeie als je D3D of OpenGL wil leren, hou er wel rekening mee dat codesampler oud is en dus geen nieuwe API's als D3D11 en OpenGL 3 of 4 tutorials heeft. Rastertek heeft een goeie tutorial voor directx 11.

Riemers is ook een goeie om naar te kijken alhoewel dit dan weer wel C# en XNA is maar het geeft je een idee hoe hij zijn game structureert.

Als je goed in engels bent is thenewboston ook een optie maar van deze gast moet je niet alles opnemen omdat hij dingen soms fout doet om de tutorial simpel te houden. Voornaamste problemen zijn geen virtual destructor bij gebruik van virtual functions en inheritance.

Het belangrijkste is dat je code niet schoon hoeft te zijn als de game maar werkt, het zal je namelijk meer voldoening en leer mogelijkheden geven om een project af te maken. Nadat je project af is kun je eens gaan kijken naar hoe je dingen zo refactoren om een schonere codebase te krijgen.

I know clean code is everything in the workplace, but getting the job done is more important.

[ Voor 14% gewijzigd door NC83 op 19-06-2013 23:44 ]

[ThomasG]

Als ik je een tip mag geven: Als je niet of nauwelijks kennis hebt van C++, niet beginnen met het ontwikkelen van een game in C++. Zelfs niet als hobby. Zorg eerst dat je de taal goed onder de knie hebt. Het is een groot verschil ten opzichte van C# of Java, vooral op gebied van memory management. Als je geen inzicht hebt ontwikkeld op het gebied van pointers en references, wat je bij talen als C# of Java niet hebt, is een memory leak op de heap zo gemaakt.

Zelfs al compiled je code, en werkt het prima, is er een grote kans dat er alsnog een memory leak in zit. Deze is alleen nog niet aan het licht gekomen, omdat je het geheugen nog niet nodig had voor iets anders, of omdat je stukje code nog geen exceptions gaf. Of omdat je vtable niet klopt. En zo zijn er nog tal van problemen te bedenken.

Zorg er eerst voor dat je deze dingen onder de knie hebt. Dat bespaart je later een hoop ellende. Je kunt dit combineren met het toepassen van 'OOP' in C++. Als je een game wilt programmeren, kun je beter een andere taal kiezen als je C++ niet gevorderd beheerst.

[Gideonnn]

Bedankt voor de links NC83, ik ga eens een kijkje nemen.

@ThomasG Ik kan wel programmeren en ik ben inderdaad een beginner in C++, maar hoe kan ik het leren zonder het aan te raken? Ik heb al een aantal games gemaakt in C#, het gaat ook niet om de games zelf, het gaat om het OOP toepassen in games. De techniek van de games zelfs, waaronder bijvoorbeeld vector rekenen kom ik tegen en dat gaat allemaal prima.

Het probleem is dat ik bijvoorbeeld movement van een object IN het object zelf doe. Zoals eerder gezegd is me dit sterk afgeraden omdat ik later in de problemen ga komen of limitaties tegen kom. Als ik bijvoorbeeld code van andere mensen zie krijg ik van die "Hé dat is een goed idee!" momenten en daar leer ik van en kan ik deeltjes van mijn code op baseren.

[Radiant]

ThomasG's punt is dat niet alleen de taal anders is maar memory management in C++ ook totaal anders is, het is namelijk geen managed taal (zoals C#) dus je hebt (standaard) geen garbage collector, automatische reference counters, enzovoort, dat moet je allemaal zelf doen (objecten verwijderen als je ze niet meer nodig hebt i.p.v. dat ze "magisch" verdwijnen zodra alle verwijzingen naar dat object weg zijn). Ook kan je pointers hebben naar objecten die helemaal niet (meer) bestaan, enzovoort.
Dat hoeft geen probleem te zijn, maar moet je je wel even over inlezen of mee experimenteren en dan is een game misschien een vrij groot project om jezelf zomaar mee in het diepe te werpen.

[Zoijar]

Radiant schreef op donderdag 20 juni 2013 @ 10:17:
ThomasG's punt is dat niet alleen de taal anders is maar memory management in C++ ook totaal anders is, het is namelijk geen managed taal (zoals C#) dus je hebt (standaard) geen garbage collector, automatische reference counters, enzovoort, dat moet je allemaal zelf doen (objecten verwijderen als je ze niet meer nodig hebt i.p.v. dat ze "magisch" verdwijnen zodra alle verwijzingen naar dat object weg zijn). Ook kan je pointers hebben naar objecten die helemaal niet (meer) bestaan, enzovoort.
Dat hoeft geen probleem te zijn, maar moet je je wel even over inlezen of mee experimenteren en dan is een game misschien een vrij groot project om jezelf zomaar mee in het diepe te werpen.

Ja, ach daar heb je shared_ptr etc voor. Dat is echt niet meer zo'n probleem bij modern C++.

[EddoH]

Zoijar schreef op donderdag 20 juni 2013 @ 10:25:
[...]

Ja, ach daar heb je shared_ptr etc voor. Dat is echt niet meer zo'n probleem bij modern C++.

Totdat je even een 'raw' pointer nodig hebt voor een 3rd party API en je shared_ptr out of scope raakt

On topic: Er zijn vanwege de populariteit van Android genoeg tutorials te vinden over game development in Android, die je stap voor stap op weg helpen. De moeilijkheid van deze tutorials is vaak redelijk laag, en de OO principes en technieken kun je 1 op 1 overnemen in C++.

[Verwijderd]

ThomasG schreef op donderdag 20 juni 2013 @ 01:30:
Als ik je een tip mag geven: Als je niet of nauwelijks kennis hebt van C++, niet beginnen met het ontwikkelen van een game in C++. Zelfs niet als hobby. Zorg eerst dat je de taal goed onder de knie hebt. Het is een groot verschil ten opzichte van C# of Java, vooral op gebied van memory management. Als je geen inzicht hebt ontwikkeld op het gebied van pointers en references, wat je bij talen als C# of Java niet hebt, is een memory leak op de heap zo gemaakt.

Zelfs al compiled je code, en werkt het prima, is er een grote kans dat er alsnog een memory leak in zit. Deze is alleen nog niet aan het licht gekomen, omdat je het geheugen nog niet nodig had voor iets anders, of omdat je stukje code nog geen exceptions gaf. Of omdat je vtable niet klopt. En zo zijn er nog tal van problemen te bedenken.

Zorg er eerst voor dat je deze dingen onder de knie hebt. Dat bespaart je later een hoop ellende. Je kunt dit combineren met het toepassen van 'OOP' in C++. Als je een game wilt programmeren, kun je beter een andere taal kiezen als je C++ niet gevorderd beheerst.

Wat maakt het uit dat er een memory leak in zit?

Heel vroegah, toen ik begon met assembly, snapte ik er ook geen zak van. Wat gaan we dan doen? Iets leuks programmeren. Wat is leuk? Een game die je aan je medestudenten kan showen bijvoorbeeld.

De eerste poging ging natuurlijk nergens over (een lights out game. Wel afgemaakt, niet trots op). Na een poging of 8 kwam er zowaar iets uit wat ook nog eens leuks was om te spelen: een vrij complete port van een bekende DOS game.

TS wil duidelijk geen game maken om uit te geven, maar om van te leren. Als je games maken leuker vind dan yet-another-tool, waarom dan niet? Dat er dan een memory leak in zit, lekker boeiend. Falen is ook een vorm van leren.

[Gideonnn]

Radiant schreef op donderdag 20 juni 2013 @ 10:17:
ThomasG's punt is dat niet alleen de taal anders is maar memory management in C++ ook totaal anders is, het is namelijk geen managed taal (zoals C#) dus je hebt (standaard) geen garbage collector, automatische reference counters, enzovoort, dat moet je allemaal zelf doen (objecten verwijderen als je ze niet meer nodig hebt i.p.v. dat ze "magisch" verdwijnen zodra alle verwijzingen naar dat object weg zijn). Ook kan je pointers hebben naar objecten die helemaal niet (meer) bestaan, enzovoort.
Dat hoeft geen probleem te zijn, maar moet je je wel even over inlezen of mee experimenteren en dan is een game misschien een vrij groot project om jezelf zomaar mee in het diepe te werpen.

Dat is nou precies waarom ik me meer C++ wil verdiepen, omdat ik die dingen wil kunnen. Ik wil niet zeggen dat ik na een MBO studie een expert ben in C#, maar dat gaat allemaal prima, het is juist die 'moeilijkheden' die me aanspreken.

Wat Darkstone beschrijft is precies wat ik wil bereiken, een game maken om te leren wat het is om een game te maken.

[Janoz]

Het probleem met C++ en games maken tegelijk leren is het probleem van het Japanse scheikunde boek. Als iets niet duidelijk is of niet werkt heb je geen idee of het aan je Japans, of aan je scheikunde kennis ligt.

[Verwijderd]

Leer dan eerst met C++ werken alvorens je een game leert maken

No offense, maar zowat om de twee maanden verschijnt hier wel een post in de trend van "ik heb geen programmeerervaring en ik wil een game in c++ maken, maar weet niet waarom".
Nu zit jij ongetwijfeld op een stuk hoger niveau dan dat, maar het sentiment is wel hetzelfde: Leer eerst staan alvorens je probeert te sprinten.
Voor het OOP principe hoef je niet C++ te gebruiken, dat weet je zelf best ook. Met C# kan je alles in Unity3D en er is ook XNA, of je begint gewoon volledig from scratch.

Tenzij je complexere API's gaat aanspreken (voor 3D rendering bijvoorbeeld) gaat je spel in c++ er overigens niet veel anders uitzien dan in c#. Je haalt je enkel een hoop kopzorgen over memory management op de nek

[Gideonnn]

Verwijderd schreef op donderdag 20 juni 2013 @ 14:01:
Leer dan eerst met C++ werken alvorens je een game leert maken

No offense, maar zowat om de twee maanden verschijnt hier wel een post in de trend van "ik heb geen programmeerervaring en ik wil een game in c++ maken, maar weet niet waarom".
Nu zit jij ongetwijfeld op een stuk hoger niveau dan dat, maar het sentiment is wel hetzelfde: Leer eerst staan alvorens je probeert te sprinten.
Voor het OOP principe hoef je niet C++ te gebruiken, dat weet je zelf best ook. Met C# kan je alles in Unity3D en er is ook XNA, of je begint gewoon volledig from scratch.

Tenzij je complexere API's gaat aanspreken (voor 3D rendering bijvoorbeeld) gaat je spel in c++ er overigens niet veel anders uitzien dan in c#. Je haalt je enkel een hoop kopzorgen over memory management op de nek

Waarom is een (desktop/console) programma anders dan een game? Ik snap wel dat een game (veelal) meer berekeningen bevat, maar die zijn helemaal het probleem niet. Het gaat me meer om het design erachter, de opbouw van het programma uit classes etc.

Ik weet wat OOP inhoud, naar mijn mening kan ik daar ook redelijk goed mee omgaan, maar nadat ik een game begin te maken stuit ik gewoon op problemen. Deze problemen komen niet door C++ maar daar de achterliggende opbouw.

[ThomasG]

Gideonnn schreef op donderdag 20 juni 2013 @ 14:28:
[...]


Waarom is een (desktop/console) programma anders dan een game? Ik snap wel dat een game (veelal) meer berekeningen bevat, maar die zijn helemaal het probleem niet. Het gaat me meer om het design erachter, de opbouw van het programma uit classes etc.

Ik weet wat OOP inhoud, naar mijn mening kan ik daar ook redelijk goed mee omgaan, maar nadat ik een game begin te maken stuit ik gewoon op problemen. Deze problemen komen niet door C++ maar daar de achterliggende opbouw.

Een game is anders dan een desktop of console applicatie, omdat de complexiteit in de meeste gevallen veel groter is. Je krijgt bij een game, vooral in C++, zo'n beetje met alle technieken binnen de taal te maken. Het is daarom beter is deze eerst onder te knie te krijgen, voordat je ze allemaal gaat toepassen. Als daar dan ook nog bij komt dat je het principe van een game niet snapt, is het gewoon geen goed idee. Ik kan nu al voorspellen dat je tegen een hoop problemen gaat aanlopen.

Ik denk dat jij C++ onderschat. Het is een hele krachtige taal, maar ook een relatief "moeilijke" taal, in de zin van, dat je alles zelf moet doen, en vooral goed in de gaten moet houden.

Vooral als je van een managed taal komt als C#. Er zijn heel veel dingen die in C# relatief eenvoudig te realiseren zijn, maar in C++ veel kennis vereisen om ze goed toe te passen, vooral het 'OOP' gedeelte. Anders werkt het niet zoals je zou willen, of gewoon helemaal niet. Zo heb je in C++ geen interfaces of abstract classes, maar wel multiple inheritence, waardoor je o.a. je vtable goed in de gaten moet houden. Anders kan bijvoorbeeld het simpel casten naar een 'interface', je applicatie al om zeep helpen, omdat het niet doet wat je zou willen. En je geen idee hebt waar je probleem zit.

[MSalters]

Gideonnn schreef op woensdag 19 juni 2013 @ 20:36:
Hoe ik OOP geleerd heb is het 3 tier systeem, één laag voor data, één voor logica en één voor weergeven. Dat is alleen niet zo van toepassing in games (lijkt mij)

Klopt. Het is ook geen OOP wat je beschrijft. Het staat zelfs haaks op OOP, kun je zeggen. In OOP is er een fusie van data en logica in een class.

Ik kwam als aller eerst een probleem tegen tijdens het moven van mijn player, ik had dit zoveel mogelijk in mijn player class gedaan. Toen werd mij aangeraden door iemand op mijn stage bedrijf dat dat niet slim was. Maar is een class om te moven gebruikelijk, of gewoon direct in main?

De vraag is natuurlijk waarom de speler beweegt. In OOP is het gebruikelijk om classes te ontwerpen via een Class Responsibility & Collaboration card. Wat is de taak van een class, en met welke andere classes moet daarvoor worden samengewerkt? Op die manier kun je een overzicht op hoog nivo maken voordat je je in de details verliest.

[Robbiedobbie]

MSalters schreef op donderdag 20 juni 2013 @ 16:45:
[...]

Klopt. Het is ook geen OOP wat je beschrijft. Het staat zelfs haaks op OOP, kun je zeggen. In OOP is er een fusie van data en logica in een class.

Waarom zou dit haaks op OOP staan? Volgens mij beschrijft hij gewoon een MVC pattern welk een veelgebruikt design pattern is, en welk naar mijn weten gewoon als behorend bij OOP gerekend wordt.

[NC83]

ThomasG schreef op donderdag 20 juni 2013 @ 14:45:
[...]
Een game is anders dan een desktop of console applicatie, omdat de complexiteit in de meeste gevallen veel groter is. Je krijgt bij een game, vooral in C++, zo'n beetje met alle technieken binnen de taal te maken. Het is daarom beter is deze eerst onder te knie te krijgen, voordat je ze allemaal gaat toepassen. Als daar dan ook nog bij komt dat je het principe van een game niet snapt, is het gewoon geen goed idee. Ik kan nu al voorspellen dat je tegen een hoop problemen gaat aanlopen.

Ik denk dat jij C++ onderschat. Het is een hele krachtige taal, maar ook een relatief "moeilijke" taal, in de zin van, dat je alles zelf moet doen, en vooral goed in de gaten moet houden.

Vooral als je van een managed taal komt als C#. Er zijn heel veel dingen die in C# relatief eenvoudig te realiseren zijn, maar in C++ veel kennis vereisen om ze goed toe te passen, vooral het 'OOP' gedeelte. Anders werkt het niet zoals je zou willen, of gewoon helemaal niet. Zo heb je in C++ geen interfaces of abstract classes, maar wel multiple inheritence, waardoor je o.a. je vtable goed in de gaten moet houden. Anders kan bijvoorbeeld het simpel casten naar een 'interface', je applicatie al om zeep helpen, omdat het niet doet wat je zou willen. En je geen idee hebt waar je probleem zit.

Je hebt wel degelijk interface en abstracte klassen in C++, een abstracte klasse in C++ is gedefinieert als een klasse die een pure virtual method bevat. Van dit soort klasses kun je geen instanties maken, vaak worden ook dit soort klasses als interface gebruikt, waardoor de derived klasse een implementatie van de pure virtual methods moet geven, anders is de derived class ook gewoon een abstract class.

Er zijn regels voor het gebruik van multiple inheritance in C++ voor normaal gebruik en die komen eerlijk gezegd neer op hoe inheritance in C# en Java is geimplementeerd. Je inherit van maar een concrete classes maar je kan wel meerder interfaces inheriten.

Het punt waarom jij waarschijnlijk zegt dat C++ geen interfaces heeft is omdat een abstract class ook daadwerkelijke implementaties kan bevatten voor bepaalde methodes van de interface en zelfs member variables mag hebben, itt C# en Java interfaces.

[farlane]

Robbiedobbie schreef op donderdag 20 juni 2013 @ 17:43:
Waarom zou dit haaks op OOP staan? Volgens mij beschrijft hij gewoon een MVC pattern welk een veelgebruikt design pattern is, en welk naar mijn weten gewoon als behorend bij OOP gerekend wordt.

Omdat OOP de data en de bewerkingen op die data groepeert in een class. Dat wat beschreven wordt doet precies het tegenovergestelde.

Verder : Ga lekker een game in C++ in elkaar prutsen, doe het fout en leer er van. Als je dit maar vaak genoeg herhaalt ben jij op een gegeven moment die ene die zo verdomt veel van *programmeren* weet.
( C# heb je dan binnen 3 dagen onder de knie )

[epic007]

+1

Kijk inderdaad vooral goed naar frameworks als Unity3D en XNA. Deze mensen hebben goed nagedacht over de OOP structuur en je kan er veel van leren.


XNA classes:

[Zoijar]

XNA is toch end of life? Zou ik links laten liggen. Als je C++ wilt: Ogre.

[ Voor 51% gewijzigd door Zoijar op 21-06-2013 10:55 ]

[Tarilo]

Zoijar schreef op vrijdag 21 juni 2013 @ 10:54:
XNA is toch end of life? Zou ik links laten liggen. Als je C++ wilt: Ogre.

Het ging hem ook over de klasse structuur, zoals hij bovenaan de post zegt.