Structuur van een spel

[TvdW]

Beste Tweakers,

Voor een projectje ben ik bezig met het ontwerpen van de structuur van de 3d-engine. Werken met 3d heb ik eerder gedaan, maar omdat dit een echte engine moet worden, zit ik te denken over de structuur ervan.

Mijn huidige opzet :
3 lagen:
1. grafische engine
2. game engine
3. het spel

de grafische engine :

code:

world
 |
entity ---------------------------
 |              |                |
form         action           status

form = de mesh, enz
action = het deel dat de "form" aanstuurt zodat er een animatie van komt
status = het deel dat aan de "action" doorgeeft welke animatie er gebruikt moet worden, hoe lang, enz

kan overweg met non-render entities: ja (form = een licht met kleur intensity enz, action = schijn, status = enabled)

Iemand die mij hier nog een advies kan geven, voor ik begin met het coden van deze 3d-engine (die tevens gekoppeld wordt met OpenGL+DirectX)? Zie ik misschien iets heel erg over het hoofd?

[epTa]

Behalve dat het verschrikkelijk veel werk is?
En dat je beter een bestaande gratis engine kan nemen, die je koppelt aan bijv. een PhysX installatie en daarbij menu maakt.

En je wilt OpenGL + DirectX? Dat maakt het aan de ene kant misschien overzichtelijker omdat je alles heel goed moet scheiden, maar het is alweer zoveel meer codeer werk.

Beste wat je denk ik nu kan doen is je schematje veel meer uitwerken. Hoe de lagen verbonden zijn, wat waarbij hoort door een heel eenvoudig te bedenken wat allemaal komt kijken bij "start het spel - menu - scene (waarin animatie of iets vallend (physics)". Daarin kijk je wat allemaal aan bod komt en dat verdeel je dan onder in een van die lagen. Maak een mooi groot overzicht, liefst op papier (copy's) dan kan je het zeg maar schetsen.

Succes ermee!
probeer steeds verder te definieren, zo kom je een heel eind denk ik.

[TvdW]

Die laag waar jij het over hebt is de game-laag. Deze bepaalt de menus, deze bepaalt de physics, deze bepaalt de collisions, enz.

en ja, opengl+directx is inderdaad veel codewerk, maar directx vinden gamertjes op windows fijn en opengl vinden gamers op linux fijn. (en ja, ik weet ook wel dat opengl er ook is voor windows)

en ja, ik weet dat het maken van een spel veel werk is, en gelukkig ben ik ook niet in mijn eentje (maar wel als programmeur)

Tom
PS: Ik zal even kijken naar bestaande engines.

[ Voor 4% gewijzigd door TvdW op 28-03-2009 20:41 ]

[TvdW]

Ok, dit is mijn herziene plan :

Nog steeds de 3 lagen
1. grafische engine (Ogre3d gaat het worden)
2. game engine
3. het spel zelf

de game engine, in onderdelen (oo dus) :
- input (gebaseerd op de ogre mKeyboard klasse. handelt voornamelijk de binds af)
- display (grafische engine dus)
- audio
- networking

het spel zelf
- het verwerken van de input
- het spelen van het spel

Tom

[RobIII]

Ik zou zeggen: begin er gewoon eens aan en laat even je ervaringen horen

With all due respect; ik denk dat je er een klein beetje (understatement) te simpel over denkt. De 'makkelijkheid' waarmee je switcht tussen "OpenGL + DirectX" naar "Ogre3d" in nog geen twee uur illustreert dat al een beetje. In die tijd heb jij nooit een weloverwogen besluit tussen de vele verschillende engines kunnen maken en daarbij is wat je nu omschrijft dusdanig breed dat het niets nieuws is; zo'n beetje iedere game heeft die 3 onderdelen zoals je ze nu, overigens wel héél makkelijk omschreven, neerlegt. Ik zie niet wat hier vernieuwend of discussiewaardig aan is?

[ Voor 85% gewijzigd door RobIII op 29-03-2009 00:05 ]

[TvdW]

RobIII schreef op zaterdag 28 maart 2009 @ 23:58:
Ik zou zeggen: begin er gewoon eens aan en laat even je ervaringen horen

With all due respect; ik denk dat je er een klein beetje (understatement) te simpel over denkt. De 'makkelijkheid' waarmee je switcht tussen "OpenGL + DirectX" naar "Ogre3d" in nog geen twee uur illustreert dat al een beetje. In die tijd heb jij nooit een weloverwogen besluit tussen verschillende engines kunnen maken en daarbij is wat je nu omschrijft dusdanig breed dat het niets nieuws is; zo'n beetje iedere game heeft die 3 onderdelen zoals je ze nu, overigens wel héél makkelijk omschreven, neerlegt. Ik zie niet wat hier vernieuwend of discussiewaardig aan is?

Ik denk dat je daar wel iets fout hebt. Ik ben inmiddels al redelijk wat jaren bezig met het schrijven van games. Ik ben ooit begonnen (jaar of 3 geleden) met een 3d spel (is nooit afgerond). Voor dit spel had ik destijds een engine nodig. Bij het kiezen waren er 3 die ik op oog had: Crystal Space, Ogre 3D en Truevision 3d. Truevision 3d heb ik destijds gekozen omdat ik eerst maar eens wou kijken hoe dat 3d eigenlijk werkte. In de tussentijd heb ik mij meer gefocust op browsergames, maar ik heb nu weer een projectje met een 3d engine nodig.

Vandaag kwamen die keuzes dus weer tevoorschijn: Ogre 3D, Crystal Space of zelf implementeren. Na (lang) twijfelen heb ik uiteindelijk besloten om zelf iets te implementeren, maar epTa had gelijk: waarom zelf doen als er genoeg open-source engines beschikbaar zijn?

Dus ik heb gekeken naar Ogre 3D en Crystal Space, aangezien dat wel de 2 grootsten zijn (open-source dan). Uiteindelijk ben ik tot de conclusie gekomen dat Ogre 3D een betere keuze is omdat je daar gewoon een laag "overheen" maakt, terwijl je bij Crystal Space "erin" duikt.

Tom

[ Voor 3% gewijzigd door TvdW op 29-03-2009 00:05 . Reden: kleine toevoegingen ]

[RobIII]

TvdW schreef op zondag 29 maart 2009 @ 00:04:
[...]

Ik denk dat je daar wel iets fout hebt. Ik ben inmiddels al redelijk wat jaren bezig met het schrijven van games. Ik ben ooit begonnen (jaar of 3 geleden) met een 3d spel (is nooit afgerond).

Gewoon uit nieuwschierigheid: waar is het gestrand toen?

TvdW schreef op zondag 29 maart 2009 @ 00:04:

Dus ik heb gekeken naar Ogre 3D en Crystal Space, aangezien dat wel de 2 grootsten zijn (open-source dan). Uiteindelijk ben ik tot de conclusie gekomen dat Ogre 3D een betere keuze is omdat je daar gewoon een laag "overheen" maakt, terwijl je bij Crystal Space "erin" duikt.

Dus je kiest op basis van "grootte" en niet op basis van de featureset die je nodig hebt? En, niet dat ik pretendeer iets van 3d engines af te weten, waarom is "overheen" dan beter dan "erin"? En kun je dan uitleggen wat je bedoelt met "overheen" en "erin"? Want dat zijn concepten die ik nooit hoor

Persoonlijk kies ik liever voor iets wat voldoet aan mijn (specifieke) eisen dan dat ik ga voor wat de grijze massa (klaarblijkelijk) kiest.

[ Voor 55% gewijzigd door RobIII op 29-03-2009 00:11 ]

[TvdW]

RobIII schreef op zondag 29 maart 2009 @ 00:06:
[...]

Gewoon uit nieuwschierigheid: waar is het gestrand toen?

ik had destijds erg weinig tijd en de structuur van de code was erg slecht.

RobIII schreef op zondag 29 maart 2009 @ 00:06:
Dus je kiest op basis van "grootte" en niet op basis van de featureset die je nodig hebt? En, niet dat ik pretendeer iets van 3d engines af te weten, waarom is "overheen" dan beter dan "erin"? En kun je dat uitleggen?

jazeker ook wel: ik kijk naar de screenshots van de 3d engine (uiteindelijk gaat het om het resultaat, niet om HOE het gebeurt, dus ik let niet op de exacte details van de engines, al vind ik dingen als renderen naar textures, multitexturing enz wel fijn)

en "overheen" is meestal beter omdat je dan niet eerst andermans code door moet lezen voor je kan beginnen met programmeren: bij Crystal Space is er een "start project" en vanuit dat punt werk je verder.

[ Voor 61% gewijzigd door TvdW op 29-03-2009 00:11 ]

[RobIII]

TvdW schreef op zondag 29 maart 2009 @ 00:07:
jazeker ook wel: ik kijk naar de screenshots van de 3d engine (uiteindelijk gaat het om het resultaat, niet om HOE het gebeurt, dus ik let niet op de exacte details van de engines, al vind ik dingen als renderen naar textures, multitexturing enz wel fijn)

Dus als er toevallig geen goede screenshots genomen zijn (of screens die jou niet specifiek 'bevallen') laat je , ongeacht de specs en features van de engine, die betreffende engine varen?

TvdW schreef op zondag 29 maart 2009 @ 00:07:
en "overheen" is meestal beter omdat je dan niet eerst andermans code door moet lezen voor je kan beginnen met programmeren: bij Crystal Space is er een "start project" en vanuit dat punt werk je verder.

Ik snap het nog steeds niet. Kun je het nog eens uitleggen in programmeurstermen? Ik kan me nog steeds niet voorstellen met wat "overheen" en "erin" programmeren in houdt

[ Voor 6% gewijzigd door RobIII op 29-03-2009 00:14 ]

[TvdW]

RobIII schreef op zondag 29 maart 2009 @ 00:13:
Dus als er geen goede screenshots genomen zijn laat je (of screens die jou niet specifiek 'bevallen'), ongeacht de specs van de engine, die betreffende engine varen?

klopt: als er geen screenshots beschikbaar zijn die mooi genoeg zijn, zal er geen goede community (of team) achter zitten en sla ik de engine over. en uiteindelijk beoordeel ik natuurlijk niet op de screens maar op de demos. (fps, hoe goed het eruit ziet, enz)

RobIII schreef op zondag 29 maart 2009 @ 00:13:
Ik snap het nog steeds niet. Kun je het nog eens uitleggen in programmeurstermen?

het verschil tussen "wrappen" en "de klasse veranderen"

Tom

[MachoM]

Ik denk dat de meesten hier niet helemaal snappen wat je bedoelt met de termen erin en eromheen? Daar struikelt rob lijkt me ook over.

Bedoel je nu met "erin" een complete game engine api, ipv (er "omheen") alleen een grafische api?

Als je iets simpels wil proberen kijk dan bvb eens naar microsofts XNA, daar kun je redelijk rap wat mee in elkaar sleutelen.

[TvdW]

MachoM schreef op zondag 29 maart 2009 @ 00:19:
Bedoel je nu met "erin" een complete game engine api, ipv (er "omheen") alleen een grafische api?

zo kan je het noemen ja, maar bij Crystal Space (dus "erin") moet je de bestaande code wijzigen om een spel te maken, terwijl bij Ogre 3D je een game-engine "om" de grafische engine bouwt.

MachoM schreef op zondag 29 maart 2009 @ 00:19:
Als je iets simpels wil proberen kijk dan bvb eens naar microsofts XNA, daar kun je redelijk rap wat mee in elkaar sleutelen.

op linux zeker

[RobIII]

TvdW schreef op zondag 29 maart 2009 @ 00:15:

het verschil tussen "wrappen" en "de klasse veranderen"

En waarom is het ene beter/slechter dan het andere? En heb je het dan over feitelijke klasses veranderen of over hiërarchische structuren handhaven en dus gewoon een fatsoenlijke OOP opzet gebruiken?

MachoM schreef op zondag 29 maart 2009 @ 00:19:
Ik denk dat de meesten hier niet helemaal snappen wat je bedoelt met de termen erin en eromheen? Daar struikelt rob lijkt me ook over.

Niet alleen daarover

TvdW schreef op zondag 29 maart 2009 @ 00:15:
[...]

klopt: als er geen screenshots beschikbaar zijn die mooi genoeg zijn, zal er geen goede community (of team) achter zitten en sla ik de engine over. en uiteindelijk beoordeel ik natuurlijk niet op de screens maar op de demos. (fps, hoe goed het eruit ziet, enz)

En, wat nou als je eens begint met keiharde eisen waar een engine aan moet voldoen? In plaats van vage en subjectieve zaken als "FPS", "hoe goet het er uit ziet" "enz".

[ Voor 67% gewijzigd door RobIII op 29-03-2009 00:31 ]

[MachoM]

Als je het op linux wil runnen is dat natuurlijk geen optie, maar dat soort details had je ons natuurlijk ook niet gemeld.

[TvdW]

RobIII schreef op zondag 29 maart 2009 @ 00:29:
[...]

En waarom is het ene beter/slechter dan het andere? En heb je het dan over feitelijke klasses veranderen of over hiërarchische structuren handhaven en dus gewoon een fatsoenlijke OOP opzet gebruiken?

wat je bij Crystal Space doet: je pakt hun game-engine (met een main()) en dan werk je vanuit die opzet verder: je creeert een spelklasse, wrapt alle crystal functies, enz. Dit geeft je uiteindelijk gewoon een enorm verlies van mogelijkheden.

Tom

[edit]

MachoM schreef op zondag 29 maart 2009 @ 00:29:
Als je het op linux wil runnen is dat natuurlijk geen optie, maar dat soort details had je ons natuurlijk ook niet gemeld.

jawel

[ Voor 18% gewijzigd door TvdW op 29-03-2009 00:32 ]

[RobIII]

TvdW schreef op zondag 29 maart 2009 @ 00:31:
[...]

wat je bij Crystal Space doet: je pakt hun game-engine (met een main()) en dan werk je vanuit die opzet verder:

Euh; ieder programma heeft toch een main()?? (Ja, wijsneuzen, soms heet het dan geen main() maar je hebt altijd een entrypoint )

TvdW schreef op zondag 29 maart 2009 @ 00:31:
je creeert een spelklasse

Want dat hoeft anders niet

TvdW schreef op zondag 29 maart 2009 @ 00:31:
wrapt alle crystal functies

Want dat hoeft anders niet En wat versta je nou specifiek onder wrappen in deze context?

TvdW schreef op zondag 29 maart 2009 @ 00:31:
Dit geeft je uiteindelijk gewoon een enorm verlies van mogelijkheden.

Want

Again; ik ben geen 3d engine kenner of 3d guru, dus please enlighten me.

TvdW schreef op zondag 29 maart 2009 @ 00:31:


jawel

Niet in de topicstart en enkel een keer hier geroepen, waar ik geen harde eis in lees.

Maar again: begin gewoon eens? Dan kun je straks misschien wat makkelijker concrete vragen stellen in plaats van de, nogal vaag afgekaderde, vragen die je nu stelt.

[ Voor 20% gewijzigd door RobIII op 29-03-2009 00:37 ]

[TvdW]

RobIII schreef op zondag 29 maart 2009 @ 00:33:
[...]

Euh; ieder programma heeft toch een main()?? (Ja, wijsneuzen, soms heet het dan geen main() maar je hebt altijd een entrypoint )

ja, maar wat ik bedoelde is dat main() al gebruikt wordt door crystal space dus dat je zelf je eigen main() niet kan bepalen.

RobIII schreef op zondag 29 maart 2009 @ 00:33:
[...]

Want dat hoeft anders niet

jawel, maar simpeler

RobIII schreef op zondag 29 maart 2009 @ 00:33:
[...]

Want dat hoeft anders niet


[...]

jawel, maar simpeler (x2)

RobIII schreef op zondag 29 maart 2009 @ 00:33:
Want

waar je in je eigen code alles kan doen, moet je er bij Crystal Space op vertrouwen dat het op het goede moment uitgevoerd wordt *denk ik*

Tom

[edit]

Maar again: begin gewoon eens? Dan kun je straks misschien wat makkelijker concrete vragen stellen in plaats van de, nogal vaag afgekaderde, vragen die je nu stelt.

ben inmiddels al begonnen

[ Voor 9% gewijzigd door TvdW op 29-03-2009 00:38 ]

[RobIII]

Ik ben je kwijt hoor Ik snap geen drol meer van wat je nou bedoelt. Ik kan enkel nog eens mezelf herhalen:

RobIII schreef op zondag 29 maart 2009 @ 00:33:
Maar again: begin gewoon eens? Dan kun je straks misschien wat makkelijker concrete vragen stellen in plaats van de, nogal vaag afgekaderde, vragen die je nu stelt.

En laat het ons dan gerust even weten als je ergens tegen aan loopt

[edit]

TvdW schreef op zondag 29 maart 2009 @ 00:37:
ben inmiddels al begonnen

Zow! Doe je snel dan! Succes

[ Voor 15% gewijzigd door RobIII op 29-03-2009 00:39 ]

[Verwijderd]

De title zegt: structuur van een spel
maar je opent vervolgens met: het ontwerpen van de structuur van een 3d engine.

Dat zijn uiteraard 2 hele verschillende dingen. Welke bedoel je nou?

Als het je om de structuur van een spel gaat dan is een goede start om gewoon eens bij anderen te kijken, bijv naar de structuur van: Pong, Pacman of Snake. Die zijn vrij simpel en krijg je beetje een idee welke onderdelen er in een spel zitten.

[RobIII]

Verwijderd schreef op zondag 29 maart 2009 @ 00:40:
De title zegt: structuur van een spel
maar je opent vervolgens met: het ontwerpen van de structuur van een 3d engine.

Dat zijn uiteraard 2 hele verschillende dingen. Welke bedoel je nou?

Als het je om de structuur van een spel gaat dan is een goede start om gewoon eens bij anderen te kijken, bijv naar de structuur van: Pong, Pacman of Snake. Die zijn vrij simpel en krijg je beetje een idee welke onderdelen er in een spel zitten.

Nah joh! Hij is al begonnen. Eerst devven; structuur en/of ontwerp komt later wel! Eerst maar eens zorgen dat die entities, forms, actions en statussen er zijn. *klop* *klop* *klop* *klop* *klop*

[ Voor 14% gewijzigd door RobIII op 29-03-2009 00:46 ]

[TvdW]

RobIII schreef op zondag 29 maart 2009 @ 00:44:
[...]

Nah joh! Hij is al begonnen. Eerst devven; structuur en/of ontwerp komt later wel!

eigenlijk ben ik begonnen met kijken hoe Ogre werkt. Dan begin ik ergens volgende week met het schetsen van de structuur en dan begin ik waarschijnlijk over zo'n 10 dagen met programmeren.

[Verwijderd]

RobIII schreef op zondag 29 maart 2009 @ 00:44:
[...]

Nah joh! Hij is al begonnen. Eerst devven; structuur en/of ontwerp komt later wel! Eerst maar eens zorgen dat die entities, forms, actions en statussen er zijn. *klop* *klop* *klop* *klop* *klop*
[afbeelding]

Een goede voorbereiding bespaart uiteindelijk veel tijd toch

[Verwijderd]

RobIII schreef op zondag 29 maart 2009 @ 00:44:
Nah joh! Hij is al begonnen. Eerst devven; structuur en/of ontwerp komt later wel! Eerst maar eens zorgen dat die entities, forms, actions en statussen er zijn. *klop* *klop* *klop* *klop* *klop*
[afbeelding]

Zoals je eigenlijk had kunnen lezen was hij de codeklopper van het groepje

en ja, ik weet dat het maken van een spel veel werk is, en gelukkig ben ik ook niet in mijn eentje (maar wel als programmeur)

Ik had dan ook niet anders verwacht uiteraard raad ik het niet af eens héél goed je "structuur" te bekijken/ontwerpen/herontwerpen/te overwegen en opnieuw te ontwerpen voordat je je onnodig voorbereid op WALLOFTEXT work-arrounds (al helemaal omdat 3D geen appeltje/eitje is... naar horen)

Dit neemt niet weg dat ik erg benieuwd naar het resultaat en de documentatie

[RobIII]

Verwijderd schreef op zondag 29 maart 2009 @ 03:08:
[...]


Zoals je eigenlijk had kunnen lezen was hij de codeklopper van het groepje

Ik nam aan (juist vanwege dit topic) dat hij ook het ontwerp deed/doet Als 'ie enkel "codeklopper" is zie ik het nut van dit topic al helemaal niet en moet 'ie gewoon kloppen wat 'm opgedragen wordt

[TvdW]

RobIII schreef op zondag 29 maart 2009 @ 03:20:
[...]

Ik nam aan (juist vanwege dit topic) dat hij ook het ontwerp deed/doet Als 'ie enkel "codeklopper" is zie ik het nut van dit topic al helemaal niet en moet 'ie gewoon kloppen wat 'm opgedragen wordt

Lead Engineer

ik denk dat die naam mijn functie het beste beschrijft. ik doe al het interne ontwerpen plus code. de grafische artiesten doen het "externe" ontwerp (hoe het eruit ziet) en de level designer maakt de maps.

[epTa]

We zijn weer wat verder, behalve dan een lange vragensessie hierboven

Ogre is redelijk gemakkelijk mee te werken en de projecten die ermee gemaakt zijn vind ik wel mooi, goede keuze wat mij betreft.

Wat wil je qua audio doen? Wat qua physics? Networking (hier heb ik geen kaas van gegeten)?

Schrijf eens op wat voor game het wordt, wat er in gebeurd, hoe de 3d bestanden (3ds? .x?) worden aangeleverd, grafische zaken, wat je allemaal wilt ingame, doel van game, interface (grofweg) het hele idee wat je in je hoofd hebt, samen met hoe je team meot kunnen samenwerken met jou.

Probeer dan met alle componenten die je nu gekozen hebt de meest simpele game te maken, zoals ik al eerder beschreef. Zo krijg je bijvoorbeeld goed ervaring hoe Ogre werkt, hoe bv OpenAL flac bestanden laat horen en hoe bollen de lucht uit komen vallen met PhysX. En dan iets van networking, simpel misschien message vanaf andere pc laten zien ingame.

Maak dan een heel mooi schema van hoe het testje met alle componenten werkt en wat de knelpunten daar zijn en wat benodigd is. Dat vergelijk je dan met wat je wil maken, dus moet je tussenstappen maken in het schema, inputs toevoegen etc etc.

Samenvatting (mijn posts zijn altijd zo onduidelijk )

+ Laat alles zo simpel mogelijk werken met de componenten die je kiest te gebruiken. Ogre scene laten doen, menu, geluid, networking, zoveel mogelijk dat je later veel uitgebreider wil gaan gebruiken. Zo leer je heel veel van de componenten, je leert hoe waar de knelpunten zitten en leert ook limieten van wat er kan.
Maak hier ook een schema van, lekker groot.
+ Inventariseer wat jouw team wil en wat ze van jou verwachten, waar ze mee willen werken en wat/hoe ze iets kunnen aanleveren. Vraag ook om gewoon wat samples, zelf gemaakte scene, geluidje ideetje toepassen als test in het voorgaande punt houdt de motivatie bij je team hoog ^^
+ Ook weer samen met je team, blauwdruk maken van wat de game wordt. Je hebt nog niets verteld daarover en je hoeft ook niet je idee uit de doeken te doen en storyline, die mogen geheim blijven , maar je maakt een engine voor een specifiek spel. Dus stel doelen op, wat moet het kunnen, denk aan wat ingame gebeurd, wat is daarvoor op programmeer niveau nodig? Wil je nog een blur of je hele scherm, beetje ruis? Dat is een extra layer na het renderen van voorgaande.

++
Pak het schema van het simpele testje en vegroot deze en ga erin schetsen waar al je eisen moeten komen, zoals je die geleerd hebt uit voorgaande stappen. Lekker schetsen, kloten is het woord nu
Zijn verschillende manieren om dezelfde output te krijgen. Behandel eerst alles individueel, dit kan je het best onder verdelen in meerdere schema's, elk schema wordt dan een class. Dus voor het geluid, voor het beeld, heel simpel nog. Lekker modulair, je main is niets anders dan het verbinden van die schema's.
Probeer uiteindelijk alles te integreren door op te schrijven wat er volgens jou moet gebeuren vanaf het moment dat je de game start, menu, klikt, geluid hoort, laden, tonen van scene, online interactie en het afsluiten. Natuurlijk is dat laatste eigenlijk het einde van alles, maar begin grof en werk het uit. Hou het modulair en verlies nooit het eindplaatje uit het oog.

Wederom succes!

[Verwijderd]

Gewoon beginnen, vastlopen, overnieuw beginnen, opnieuw vastlopen, met hernieuwde inzichten terug naar de tekentafel, en overnieuw gaan kloppen =)

Ooit ben ik net zo begonnen als jij beschrijft, gaan kloppen, iets werkends gemaakt, niet vooruit te branden was door o.a. ongestructureerde code, falend design, maar vooral een gebrek aan ervaring.

Met dit nieuwe inzicht opnieuw begonnen, vervolgens eindelijk een gevoel gekregen bij de sheer scale van een dergelijk project (onmogelijk om alleen aan te beginnen). Zwaar gedemotiveerd heb ik het project een tijd laten rusten (ook door gebrek aan tijd).

Inmiddels weer met nieuwe interesse wat dingen aan het proberen, maar nu op veel kleinere schaal. Dat moet wel, als je op wil vallen. Je kan qua features niet opboxen tegen de grote jongens (devteams van +100 man), maar met een origineel idee kom je veel verder, en heb je - denk ik - ook een grotere kans om ooit in die industrie serieus mee te kunnen draaien.

Maargoed. Erop gokkend dat je minstens net zo eigenwijs bent als ik, ga je er toch aan beginnen =P succes!

EDIT: @epTa: Je samenvatting is langer dan de rest van je post

[ Voor 3% gewijzigd door Verwijderd op 06-04-2009 23:30 ]

[.oisyn]

Verwijderd schreef op maandag 06 april 2009 @ 23:23:
(devteams van +100 man)

Nou is 100+ een beetje overdreven (30 tot 60 is gebruikelijker), maar de ervaring van de lead programmers telt natuurlijk nog veel zwaarder dan het verschil in mensen

[R4gnax]

epTa schreef op zondag 29 maart 2009 @ 15:48:
Ogre is redelijk gemakkelijk mee te werken en de projecten die ermee gemaakt zijn vind ik wel mooi, goede keuze wat mij betreft.

Wat wil je qua audio doen? Wat qua physics? Networking (hier heb ik geen kaas van gegeten)?

Schrijf eens op wat voor game het wordt, wat er in gebeurd, hoe de 3d bestanden (3ds? .x?) worden aangeleverd, grafische zaken, wat je allemaal wilt ingame, doel van game, interface (grofweg) het hele idee wat je in je hoofd hebt, samen met hoe je team meot kunnen samenwerken met jou.

Probeer dan met alle componenten die je nu gekozen hebt de meest simpele game te maken, zoals ik al eerder beschreef. Zo krijg je bijvoorbeeld goed ervaring hoe Ogre werkt, hoe bv OpenAL flac bestanden laat horen en hoe bollen de lucht uit komen vallen met PhysX. En dan iets van networking, simpel misschien message vanaf andere pc laten zien ingame.

Maak dan een heel mooi schema van hoe het testje met alle componenten werkt en wat de knelpunten daar zijn en wat benodigd is. Dat vergelijk je dan met wat je wil maken, dus moet je tussenstappen maken in het schema, inputs toevoegen etc etc.

Het is relatief makkelijk om met Ogre iets te bouwen, dat klopt. Maar om iets goeds; onderhoudbaar, schaalbaar, etc. met Ogre te bouwen, dat is een aanzienlijk groter karwei en vereist dat je significant anders te werk gaat dan het simpele 'erf een klasse van ExampleApplication' waar de Ogre tutorials op gestoeld zijn. Vanuit dat oogpunt heeft het weinig nut om vooraf test-cases te schrijven, gezien die toch niet gaan behelzen hoe je in het uiteindelijke project te werk zult moeten gaan.

Er zijn hele fora discussies en diverse al-dan-niet volledige Wiki artikelen gewijd aan het uitzoeken hoe Ogre voor een 'real life' project gebruikt zou moeten worden. Allemaal research en ervaringen van personen die al een tijdje met die engine werken. Daar zou TvdW naar kunnen kijken.

De jongens die aan de Open Dark Engine werken hebben mijns inziens ook één v/d betere werkende structuren in hun overkoepelende game engine. Zeker een goed idee om daar ook eens naar te kijken, al was het maar voor het key binding systeem wat ze om de OIS input library opgezet hebben. Dat is heel goed geregeld en wordt ook in de Ogre forums vaak aangehaald als een goed design.