[alg] Wat heb je nodig voor spelontwikkeling?

[kmf]

Ik had vandaag een vurige discussie met een projectlid voor school. We zijn bezig om een spelontwikkelingsmodule in te voeren op onze school (informatica).

Nou hebben we eigenlijk beiden een andere achtergrond. Ik ben meer gericht op de programmeerkant, hij meer op bedrijfskundige kant.

Na een hoop websites te hebben doorgebladerd en door een stapel boeken te hebben gesurfd vind ik zelf dat er eigenlijk 3 soorten catogorieen bestaan om computerspellen te ontwikkelen. En van deze drie zal er eigenlijk onderwijs gegeven moeten worden.

Ik vind dat, om een spel te ontwikkelen men de keuze heeft tussen, programmeertalen, ontwikkeltools en engines.

Programmeertalen spreken voor zich.

Ontwikkeltools zijn voor mij nog een beetje vaag. Deze worden her en der genoemd. Ik interpreteer het als een middel om zonder enige programmeerkennis een spel te ontwikkelen. Schijnbaar bestaan er pakketten die gewoon met drag&drop een "spel" uitspugen. (kent iemand hier een van?)

Engines vind ik ook heel vaag beschreven eigenlijk. Of nog erger. Ik heb nergens een duidelijke definitie kunnen vinden. Ook niet in die 5 kilo 3d-gamesboek die ik heb geleend.

Wat ik ervan begrijp zal een Engine een combinatie tussen programmeertaal en tools moeten zijn. Veelal worden deze voor 3d-spellen gebruikt. Engines in de meest ruwe zin van het woord (wederom, volgens mijn interpretatie), zijn eigenlijk een hoop standaardprogrammeercodes en hulpmiddelen (geen tools, maar hulpmiddelen) die bijeengeraapt zijn om een (3d) spel zo makkelijk mogelijk te ontwikkelen.
Makkelijk wilt niet zeggen drag&drop en voila een spel, maar de repeterende dingen te verminderen.


Tot nu toe is nog niet duidelijk wat ik met deze post wil, maar dat komt nu.

Zijn jullie met me eens dat enkel deze 3 catogorieen bestaan voor spelontwikkeling?

En weten jullie een duidelijk definitie van een tool en een engine?

En hebben jullie een paar voorbeelden van tools en engines?

[OZ-Gump]

* OZ-Gump dacht altijd dat een engine het hart van een spel was?

Mij hebben ze altijd uitgelegd dat een (3D)engine een soort core is waar je van alles omheen kunt bouwen. Zo zijn er diverse spellen gebaseerd op de Quake-engine. En dat wil alleen maar zeggen dat bijvoorbeeld functies om 3D-tekeningen te maken in die engine zitten. Je moet hem echter nog wel vertellen wat hij waar moet tekenen. De engine zorgt er dan voor dat het gebeurt. Een engine is dus, voor zover ik weet, niet iets waar je in, maar waar je mee programmeert.

Wat de tools betreft worden m.i. softwaretools bedoeld, waar je bijvoorbeeld 3D-tekeningen in kunt maken die je kunt aanbieden aan de engine. Je hebt Photoshop, waarmee je een bestandje hebt waar windows een plaatje van kan maken, en zo heb je game-tools, die ervoor zorgen dat engines er een 3D-omgeving van maken.

En dat alles komt uiteindelijk samen in het programmeerwerk.
Een pakketje waar je drag & drop een (goeie) game uit tovert lijkt me heel interessant, maar niet makkelijk vindbaar.

Vergeet natuurlijk ook niet dingen als graphics, sound, spellijn, playabillity (?) oftewel: allerlei (creatieve) processen waar diverse tools voor nodig zijn. Die processen zorgen er uiteindelijk wel voor of je game kans maakt of niet...

[ Voor 1% gewijzigd door OZ-Gump op 17-02-2003 14:08 . Reden: mini-typo ]

[Verwijderd]

Op www.gamedev.net kun je veel info vinden. Over elk onderwerp is wel wat informatie verzameld, zeker het kijken waard!

[OZ-Gump]

Om nog even aan de laatste paar vragen te kunnen voldoen: kijk eens op de site van flipcode voor engines en tools. Hier vind je ook heel veel info en tutorials...

[Verwijderd]

Praat ook eens met mensen die actief zijn in de modification scenes. Zij weten er ook veel van.

[kmf]

Verwijderd schreef op 17 februari 2003 @ 14:10:
Op www.gamedev.net kun je veel info vinden. Over elk onderwerp is wel wat informatie verzameld, zeker het kijken waard!

Ironische is, is dat gamedev me juist op deze 3 catogorieen had gebracht, maar ze brachten het zo vaagjes dat het juist onduidelijker werd.

[kmf]

OZ-Gump schreef op 17 februari 2003 @ 14:07:
* OZ-Gump dacht altijd dat een engine het hart van een spel was?

Mij hebben ze altijd uitgelegd dat een (3D)engine een soort core is waar je van alles omheen kunt bouwen. Zo zijn er diverse spellen gebaseerd op de Quake-engine. En dat wil alleen maar zeggen dat bijvoorbeeld functies om 3D-tekeningen te maken in die engine zitten. Je moet hem echter nog wel vertellen wat hij waar moet tekenen. De engine zorgt er dan voor dat het gebeurt. Een engine is dus, voor zover ik weet, niet iets waar je in, maar waar je mee programmeert.

Ik had ook altijd gedacht dat een engine te vergelijken is als een kernel. Maar een boek deed die gedachte weer teniet doen. Hierin wordt engines weer beschouwd als een soort van pakket dat een mix is tussen een IDE en 3d-max

Wat de tools betreft worden m.i. softwaretools bedoeld, waar je bijvoorbeeld 3D-tekeningen in kunt maken die je kunt aanbieden aan de engine. Je hebt Photoshop, waarmee je een bestandje hebt waar windows een plaatje van kan maken, en zo heb je game-tools, die ervoor zorgen dat engines er een 3D-omgeving van maken.

Ik denk dat grafische tools als 3d-max, photoshop. Of componeerpakketten voor muziek juist niet hetgene is wat de gamedev-mensen bedoelen met "Game Development Toolkits". Op het manier waarop zij het beschrijven is het enige wat ik me daarbij voor kan stellen een soort van opgewaardeerde mapeditor waar je behalve landschap ook een model/bot kan plaatsen met drag&drop/point&click.

[.oisyn]

[spam] post een dergelijk topic ook eens op het forum van gameskool [/spam]

een engine kun je zien als een library waarvan jouw spel gebruik maakt. De rest zul je er nog steeds omheen moeten programmeren. Ik zie het dan ook totaal niet als aparte categorie.

Ontwikkeltools zijn niet die sleep en pleur gamemaak programma's, maar meer benodigdheden bij de ontwikkeling van spellen. Denk hierbij aan grafische tools zoals 3d studio max om modellen en plaatjes mee te maken, of level-editors om maps mee te maken, enzovoorts.
De sleep en pleur gamemaak programma's zijn over het algemeen voor de beginnende gamedevvers om een idee te krijgen van hoe alles nou in elkaar steekt, en het lijkt me voor de scope van je opleiding (informatica) niet echt van belang

[kmf]

.oisyn schreef op 17 February 2003 @ 14:54:
[spam] post een dergelijk topic ook eens op het forum van gameskool [/spam]

een engine kun je zien als een library waarvan jouw spel gebruik maakt. De rest zul je er nog steeds omheen moeten programmeren. Ik zie het dan ook totaal niet als aparte categorie.

OK. dus dat kan ik dan definieren als een mooie naam voor die stapel standaardprogrammeercodes die je in de jaren dat je hebt geprogrammeerd, bijeen had verzameld. Zoals collision detection codes e.d.

Ontwikkeltools zijn niet die sleep en pleur gamemaak programma's, maar meer benodigdheden bij de ontwikkeling van spellen. Denk hierbij aan grafische tools zoals 3d studio max om modellen en plaatjes mee te maken, of level-editors om maps mee te maken, enzovoorts.
De sleep en pleur gamemaak programma's zijn over het algemeen voor de beginnende gamedevvers om een idee te krijgen van hoe alles nou in elkaar steekt, en het lijkt me voor de scope van je opleiding (informatica) niet echt van belang

Aangezien wij een een supermodule/project willen introduceren dat een groot gedeelte van de de opleiding, of helemaal vanaf het propadeusejaar (waarbij wordt aangenomen dat de nieuwe studenten helemaal geen programmeerbasiskennis beschikken) tot en met het afstuderen zal het niet zo slecht zijn als er even superkort aandacht wordt besteed aan sleep en pleur dingen. Die mogelijkheid moeten we iig meenemen denk ik.

Dusse.. heb je een paar namen voor ons ?

[Zoijar]

Een "engine" bestaat meestal uit een of meer van de volgende modules: grafisch/3d (meestal inclusief physics), netwerk, geluid, AI, gui. Voor tools kan je dan denken aan een map-editor (3ds max is veel te complex vaak), gui designer, AI-scripter.

[.oisyn]

[nohtml]

athlonkmf schreef op 17 February 2003 @ 15:04:

[...]


OK. dus dat kan ik dan definieren als een mooie naam voor die stapel standaardprogrammeercodes die je in de jaren dat je hebt geprogrammeerd, bijeen had verzameld. Zoals collision detection codes e.d.

engine is een vaag begrip. Je kunt ook niet echt zeggen: dit is een engine, en dat niet. Maar meestal wordt het gezien als een losstaand onderdeel waar het algemene spel gebruik van maakt. Zoals een 3d engine wat het tekenen van de omgeving regelt, een physics engine die zorgt voor collision detection en toepassing van natuurkunde (krachten enzo), een sound engine die zorgt dat het geluid er goed gepositioneerd uitkomt, enzovoorts.

Dusse.. heb je een paar namen voor ons ?

even uit mijn hoofd: gamemaker, dev studio ofzoiets (Weet de exacte naam niet), ...
Verder heb je nog programmeertalen als blitzbasic en dark basic, waar je in principe wel echt in moet programmeren maar echt allerlei functies zijn al voorgedefinieerd dus het is vrij makkelijk om snel iets op het beeld te tonen

[Xanthus]

athlonkmf schreef op 17 February 2003 @ 15:04:
Dusse.. heb je een paar namen voor ons ?

Drag&drop: rpg maker 2000
Beetje midden tussen engine en drag&drop: Sphere

[MisterData]

Denk voor een mapeditor bijvoorbeeld aan die van Half-Life (Worldcraft, is zo te vinden als je even g00gled)...

[Alarmnummer]

Volgens mij is een beginnend informaticus veel meer gebaat bij het echt leren proggen dan het knoeien met zo`n project. Gewoon traditioneel programmeer les geven, waar alles over de 'klassieke' zaken wordt ingestampt. Ze missen vaak een goeie basis (vooral hogeschool leeuwarden volgens mij.. ).

[ Voor 8% gewijzigd door Alarmnummer op 17-02-2003 16:13 ]

[kmf]

Alarmnummer schreef op 17 February 2003 @ 16:12:
Volgens mij is een beginnend informaticus veel meer gebaat bij het echt leren proggen dan het knoeien met zo`n project. Gewoon traditioneel programmeer les geven, waar alles over de 'klassieke' zaken wordt ingestampt. Ze missen vaak een goeie basis (vooral hogeschool leeuwarden volgens mij.. ).

Persoonlijk vind ik dat je leren en leren hebt.

Zelfs programmeren kan je zo leuk maken als je wilt. Ik had met pointers leren werken stomme vluchtige "database"-progjes te maken e.d. In principe leer je het wel, maar het is simpelweg niet leuk want je hebt er niks aan.

Zelfde geld ook voor de standaard "palindroom"progjes... Geschikt om te leren, maar niet leuk en dus zullen mensen niet zoveel inzet tonen.

Dat was een van de redenen waarom dit project is gestart. Om te kijken of we het allemaal leuker kunnen brengen. En ik moet toegeven, toen ik even een paar tutorials ging volgen om een heel standaard point&shoot progje te schrijven was ik veel intensiever mee bezig dan al m'n programmeervakken bij elkaar.

Ik ging zelf op zoek naar informatie over het werken met sprites bv. zodat het geheel wat grafisch aantrekkelijker werd. En had in 2 dagen meer "geleerd" dan 2 modules programmeren van 10 weken en ik vond het nog leuk ook.


Globale idee voor de nieuwe "supermodule: spelontwikkeling" zal waarschijnlijk bestaan uit veel kleine modules die wel heel vele met elkaar te maken zullen hebben.

Basisprogrammeren, if then else if etc.
Grafisch ontwerp (schetsen met de hand en werken met grafische pakketten)
AI

En elk module zal een klein stukkie spel worden. Belangrijkste is dat de studenten daadwerkelijk een leuk stukje resultaat zien.

[ Voor 14% gewijzigd door kmf op 17-02-2003 16:37 ]

[Alarmnummer]

Zo lang het leren maar niet voorbij gestreeft wordt door het belangrijke onderdelen van een spel zelf zoals graphics/geluid ed. En ik weet verder ook niet wat voor vak je geeft, maar meer en betere oo analyse zou zeker geen kwaad kunnen. Misschien zouden design patterns ook leuk zijn, maar dat is zeker niets iets voor de beginners.

[.oisyn]

Alarmnummer schreef op 17 February 2003 @ 16:12:
Volgens mij is een beginnend informaticus veel meer gebaat bij het echt leren proggen dan het knoeien met zo`n project. Gewoon traditioneel programmeer les geven, waar alles over de 'klassieke' zaken wordt ingestampt. Ze missen vaak een goeie basis (vooral hogeschool leeuwarden volgens mij.. ).

hangt natuurlijk ook een beetje van de opleiding af, maar wat hogere informatica opleidingen betreft heb je imho wel gelijk

Maar er zijn ook scholen waarbij de nadruk minder op het programmeren zelf wordt gelegd. De Design for Virtual Theatre and Games (DVTG) opleiding op de Hogeschool voor de Kunsten in Utrecht is hier een mooi voorbeeld van. Ok, zoals de naam het al zegt is het een hogeschool voor de kunsten, maar je kunt je op deze opleiding ook specializeren in de programmeerskant, en dan is het dus eigenlijk een informatica-opleiding, met de nadruk op gamedevelopment

En die mensen gaan ook voor een baan in de gamedevelopment, niet zozeer gewone software development, en daar zijn de algemenere technieken toch minder belangrijk en komt het meer aan op ervaring en kennis van algoritmische technieken

[slm]

Volgens mij bestaan er 2 manieren om een spel te maken:
1. Ontwikkeltool (drag & drop zooi)
2. Raw programming (eventueel gebruik makend van bestaande codes of modules)

Voor beide manieren heb je weer hulpmiddelen:
- grafische progs
- 3d progs
- maptools
- notepad
- pen en papier
etc etc

Als je zelf gaat programmeren, heb je de volgende keuzes:
1. Welke programmeertaal je gaat gebruiken
2. of je gebruik gaat maken van bestaande engines (3D-engines, mapgenerating-engines, gameplay-engines) of liever gezegd: bestaande, vaststaande en vrijwel onwijzigbare modules.
3. Daarnaast (niet in plaats van) heb je de keuze om gebruik te maken van bestaande programmeercode (eventueel in module of OOP-vorm), die je wel naar je eigen hand kan zetten.

Kunnen jullie trouwens niet iets nuttigs maken gedurende het studiejaar? Bruikbare Open Source software bijvoorbeeld? Waar ik me namelijk zelf wezenloos aan heb geërgerd tijdens mijn studie is dat alle moeite en inzet ten spijt, het uiteindelijke resultaat behoorlijk nutteloos was (omdat het bijvoorbeeld al bestond).

Een open source intelligent vertaal programma bijvoorbeeld
One vacant sordine sagacious translatable platform for instance

[kmf]

slm schreef op 17 februari 2003 @ 20:34:
Volgens mij bestaan er 2 manieren om een spel te maken:
1. Ontwikkeltool (drag & drop zooi)
2. Raw programming (eventueel gebruik makend van bestaande codes of modules)

Voor beide manieren heb je weer hulpmiddelen:
- grafische progs
- 3d progs
- maptools
- notepad
- pen en papier
etc etc


Als je zelf gaat programmeren, heb je de volgende keuzes:
1. Welke programmeertaal je gaat gebruiken
2. of je gebruik gaat maken van bestaande engines (3D-engines, mapgenerating-engines, gameplay-engines) of liever gezegd: bestaande, vaststaande en vrijwel onwijzigbare modules.
3. Daarnaast (niet in plaats van) heb je de keuze om gebruik te maken van bestaande programmeercode (eventueel in module of OOP-vorm), die je wel naar je eigen hand kan zetten.

Ik ben het hier ook wel mee eens. Tis alleen dat "engines" zo'n vaag begrip was (ik lees hier nu al 2-3 interpretaties van dit woord) dat het net zo goed een 3e "manier" is al naar gelang de interpretatie.

Kunnen jullie trouwens niet iets nuttigs maken gedurende het studiejaar? Bruikbare Open Source software bijvoorbeeld? Waar ik me namelijk zelf wezenloos aan heb geërgerd tijdens mijn studie is dat alle moeite en inzet ten spijt, het uiteindelijke resultaat behoorlijk nutteloos was (omdat het bijvoorbeeld al bestond).

Een open source intelligent vertaal programma bijvoorbeeld
One vacant sordine sagacious translatable platform for instance

we willen dat scholiertjes van de Havo of hoger wat meer "plezier" hebben in het programmeren, daarom is deze onderzoeksproject gestart.
Het plezier zit em erin dat een student een paar basisprincipes van spelontwikkeling leert en dan vervolgens misschien een EIGEN spel kan maken. Misschien een puzzelspel, misschien een shooter, misschien een platform.

Als je eenmaal weet hoe je input/output met muis en/of toetsenbord kan proggen, en je weet enkele simpele algoritmes en je weet wat over sprites en collision detection, dan kan een klas van 20 studenten 20 verschillende spellen maken.

Dat maakt het geheel wat aantrekkelijker. Als je iets maakt dat van jezelf is en niet weer een standaard dingetje dat je nooit gebruikt.

"Iets nuttigs" laten maken is een leuk afstudeerprojectje of zo. Maar niet echt iets wat je zomaar kan implementeren in een lesprogramma.
1: zal jij iets gebruiken dat een prognOOb in elkaar had getikt?
2: een ietsie meer ervaren progger heeft slechts een uur nodig om datzelfde te bereiken als wat een beginnend student 1 week voor nodig heeft.
3: Wil jij nou echt 4x3x40=480 (4blokken in een jaar, elk blok met gemiddeld 40studenten per klas en 2-3 klassen) niet afgemaakte kleine progjes op sourceforge.net zien


Plan is verlopig als volgt: een student leert wat basisprincipes, kan als snel een werkend demotje tevoorschijn tonen dat grafisch gewoon suckt en waarschijnlijk ontiegelijk traag is.
In de loop van het leerproces zal hij/zij een eigen volwaardig spel gemaakt moeten hebben. Levels, een verhaal, grafisch mooi vormgegeven, slimme tegenstanders, goede gameplay, geoptimaliseerde code, etc, etc.

En het verschil tussen dit en de standaard programmeerles, is dat de student nu WILT leren programmeren, grafisch ontwerpen, inzien van belang van OOP, optimaliseren, AI om zijn/haar spel beter te maken. Tenminste... dat is de gedachte derachter.

[Verwijderd]

Grappig toch hoe vaak je ziet dat er op scholen plannen worden bedacht door mensen die niet weten waar ze het over hebben..
No offense, maar je gaat dus iets opzetten om mensen te leren waar je zelf eigenlijk niet zoveel vanaf weet ?
(Niet bedoeld als belediging maar dat blijkt imho. uit de posts)

>In de loop van het leerproces zal hij/zij een eigen volwaardig spel gemaakt moeten
>hebben. Levels, een verhaal, grafisch mooi vormgegeven, slimme tegenstanders, goede
>gameplay, geoptimaliseerde code, etc, etc.

Nou, da's een mooie doelstelling, leuk om te weten dat de leerlingen daar een spel gaan maken met mooe gfx, goeie AI, zinnige levels, snelle code etc..
Doen wij hier toch iets verkeerd denk ik, wij doen daar (professioneel) met 25 man een paar jaar over :-)

Nogmaals, no offense maar het klinkt allemaal weinig doordacht..
Mik eens op iets eenvoudigers - laat ze networked tetris maken ofzo voordat je ze met levels, AI, optimizing etc. gaat laten klooien.. Dikke kans dat 90% van de studenten *dat* niet eens voor elkaar krijgt.

[slm]

athlonkmf schreef op 18 februari 2003 @ 00:19:
"Iets nuttigs" laten maken is een leuk afstudeerprojectje of zo. Maar niet echt iets wat je zomaar kan implementeren in een lesprogramma.
1: zal jij iets gebruiken dat een prognOOb in elkaar had getikt?
2: een ietsie meer ervaren progger heeft slechts een uur nodig om datzelfde te bereiken als wat een beginnend student 1 week voor nodig heeft.
3: Wil jij nou echt 4x3x40=480 (4blokken in een jaar, elk blok met gemiddeld 40studenten per klas en 2-3 klassen) niet afgemaakte kleine progjes op sourceforge.net zien


Plan is verlopig als volgt: een student leert wat basisprincipes, kan als snel een werkend demotje tevoorschijn tonen dat grafisch gewoon suckt en waarschijnlijk ontiegelijk traag is.
In de loop van het leerproces zal hij/zij een eigen volwaardig spel gemaakt moeten hebben. Levels, een verhaal, grafisch mooi vormgegeven, slimme tegenstanders, goede gameplay, geoptimaliseerde code, etc, etc.

En het verschil tussen dit en de standaard programmeerles, is dat de student nu WILT leren programmeren, grafisch ontwerpen, inzien van belang van OOP, optimaliseren, AI om zijn/haar spel beter te maken. Tenminste... dat is de gedachte derachter.

Mwah. Source code is source code en open source is open source. De hele bedoeling van open source is dat het door anderen mogelijk kan worden verbeterd, dus of het nu door een n00b wordt gemaakt of niet, als het werkt, werkt het en als het niet mooi is geprogd dan kan dat altijd worden verbeterd.

Iig wist ik niet dat je het over HAVO niveau programmeren had. Ik dacht dat je het misschien over HIO of BI niveau had. Wij hadden op de HEAO zoiets als een Geïntegreerd Project d.w.z. met meerdere disciplines 1 project voltooien. Dat is een uitstekende broedplaats om met iets zinnigs te komen. En al zijn het vrij simpele zaken, open source is er nooit genoeg. Toch?

[BaRF]

nog 2 voorbeelden van drag&drop&play=

Klik & Play, heb ik hier liggen en is al een oudje, maar het was indertijd een geweldige manier om snel spelletjes te maken! varierend van mario wannabeŽs tot puzzelgames.

GameFactory, ook eens geprobeerd maar na een agressieve bui weer uninstalled de voorbeeld games die er bij zaten waren veelbelovend, maar ze waren niet súper leuk.

Het is gewoon net als schilderen: met de kant en klare kleurtjes kun je grappige dingen maken, maar als je écht mooie resultaten wilt, moet je toch echt gaan mengen en zelf kleuren verzinnen

[kmf]

Verwijderd schreef op 18 February 2003 @ 10:29:
Grappig toch hoe vaak je ziet dat er op scholen plannen worden bedacht door mensen die niet weten waar ze het over hebben..
No offense, maar je gaat dus iets opzetten om mensen te leren waar je zelf eigenlijk niet zoveel vanaf weet ?
(Niet bedoeld als belediging maar dat blijkt imho. uit de posts)

Nou, da's een mooie doelstelling, leuk om te weten dat de leerlingen daar een spel gaan maken met mooe gfx, goeie AI, zinnige levels, snelle code etc..
Doen wij hier toch iets verkeerd denk ik, wij doen daar (professioneel) met 25 man een paar jaar over :-)

Nogmaals, no offense maar het klinkt allemaal weinig doordacht..
Mik eens op iets eenvoudigers - laat ze networked tetris maken ofzo voordat je ze met levels, AI, optimizing etc. gaat laten klooien.. Dikke kans dat 90% van de studenten *dat* niet eens voor elkaar krijgt.

Daarom is het allemaal nog in onderzoekfase. Wat is mogelijk, wat is niet mogelijk. Wij begrijpen ook wel dat een klas hbo-studentjes niet een concurrent van Warcraft3 zullen produceren, maar een redelijk spel zal toch wel moeten lukken.

En de vraag is ook nog maar, kijken wij naar het leerproces, of kijken we naar het eindresultaat? Het lijkt mij geen probleem als een studentje een waardeloze AI maakt, maar als ie maar begrijpt waar zijn knelpunten liggen, dan kan die daar verder op borduren en weet de school ook waar ze moeten begeleiden.

Het is tevens ook nog onduidelijk of we het allemaal door 1 studierichting laten doen of juist door meerderen tegelijkertijd. We hebben bijvoorbeeld een technische (programmeer)kant op onze school, maar ook een vormgevingskant. Misschien dat we ze laten samenwerken met elkaar.

Maar zoals ik al zei. ALLE mogelijkheden moeten onderzocht worden. Dit. onderzoeksproject duurt ongeveer 3 maanden. En we beginnen bij het begin: inventariseren wat voor mogelijkheden er bestaan om spellen te ontwikkelen.


Oh, en nog iets. Je kan ook niet aannemen dat elk onderzoek wordt gestart door mensen die er alles over een onderwerp weten. Als dat zo is, is een onderzoek ook niet noodzakelijk. Niet?

[ Voor 5% gewijzigd door kmf op 18-02-2003 14:12 ]

[kmf]

slm schreef op 18 februari 2003 @ 10:49:
[...]


Mwah. Source code is source code en open source is open source. De hele bedoeling van open source is dat het door anderen mogelijk kan worden verbeterd, dus of het nu door een n00b wordt gemaakt of niet, als het werkt, werkt het en als het niet mooi is geprogd dan kan dat altijd worden verbeterd.

Iig wist ik niet dat je het over HAVO niveau programmeren had. Ik dacht dat je het misschien over HIO of BI niveau had. Wij hadden op de HEAO zoiets als een Geïntegreerd Project d.w.z. met meerdere disciplines 1 project voltooien. Dat is een uitstekende broedplaats om met iets zinnigs te komen. En al zijn het vrij simpele zaken, open source is er nooit genoeg. Toch?

Het gaat idd om HBO-informatica studenten.

Maar we weten nog niet zeker in welk jaar we dit gaan invoeren (onderzoeken dit nu). Het kan zijn dat we pas na de propadeuse jaar dit implementeren in een van de studierichtingen (dan hebben de studenten al basis van programmeren onder de knie).
Maar het kan ook zijn dat we dit direct vanaf het propadeusejaar laten beginnen, en dan nemen we aan dat ze allemaal geen programmeerervaring hebben en nog op havo-niveau/MBO-niveau zitten

[Verwijderd]

Kijk eens op deze pagina (http://www.cs.uu.nl/docs/vakken/gds/). Dat is een vak dat op de Universiteit Utrecht wordt gegeven wat over Game Design gaat. Hier worden ook een aantal programma's genoemd die handig zijn voor het maken van 3D games (Virtool, Jamagic, etc.) Ik denk dat dit wel ongeveer de strekking is dat je moet hebben aangezien je studenten niet een volledige game wil laten schrijven in een hogere programmeertaal zoals C++. Het zou een beetje buiten het doel (elementen leren mbt games) gaan vallen naar mijn idee.

[.oisyn]

Verwijderd schreef op 18 February 2003 @ 14:11:
aangezien je studenten niet een volledige game wil laten schrijven in een hogere programmeertaal zoals C++. Het zou een beetje buiten het doel (elementen leren mbt games) gaan vallen naar mijn idee.

C++ is nou juist de lagere programmeertaal... Een gamescripttaal is een voorbeeld van een 'hogere' programmeertaal

[kmf]

Verwijderd schreef op 18 February 2003 @ 14:11:
Kijk eens op deze pagina (http://www.cs.uu.nl/docs/vakken/gds/). Dat is een vak dat op de Universiteit Utrecht wordt gegeven wat over Game Design gaat. Hier worden ook een aantal programma's genoemd die handig zijn voor het maken van 3D games (Virtool, Jamagic, etc.) Ik denk dat dit wel ongeveer de strekking is dat je moet hebben aangezien je studenten niet een volledige game wil laten schrijven in een hogere programmeertaal zoals C++. Het zou een beetje buiten het doel (elementen leren mbt games) gaan vallen naar mijn idee.

Hartstikke bedankt! Dat is een zeer nuttige link.

Ik zal er voorlopig niet naar kijken though, dit om te voorkomen dat ons onderzoek wordt beinvloedt daardoor. Als je weet dat iets soortgelijks reeds bestaat, dan ga je onbewust ook enigszins daarnaartoe denken. Het werkt de innovativiteit tegen zeg maar.

Maar ik zal dat zeker bookmarken.

[unclero]

Alarmnummer schreef op 17 februari 2003 @ 16:12:
Volgens mij is een beginnend informaticus veel meer gebaat bij het echt leren proggen dan het knoeien met zo`n project. Gewoon traditioneel programmeer les geven, waar alles over de 'klassieke' zaken wordt ingestampt. Ze missen vaak een goeie basis (vooral hogeschool leeuwarden volgens mij.. ).

Ben ik het helemaal mee eens. (behalve dat over leeuwarden, want daar kan ik niet over meepraten)
Als je wilt rennen moet je eerst leren staan oid.

Ik bedoel, alleen al een gamepje als character based Worm schrijven is al veel werk zeker als je ook nog verschillende maps gebruikt en collision detection.

[Kakaroto]

een paar progjes om een mooi grafisch game/programma te maken:

-3Dmax studio
-final render
-C+/++

Voor 3dshooters heb je nog meer nodig, maar dan moet je google gebruiken

[Verwijderd]

offtopic:

Ik vind eigenlijk dat "Games Programmeren" , in z'n geheel niet op een Informatica opleiding thuishoort. Het vak Informatica, gaat zoals de naam al zegt over Informatie Voorziening binnen organisaties etc. (op allerlei vlak). Omdat men toevallig met de PC's die hiervoor als hardware worden ingezet ook Spelletjes kan spelen, is eigenlijk meer toeval.
Als een opleiding z'n leerlingen niet voldoende kan motiveren met de normale vakken die met IT te maken hebben, doen ze naar mijn mening toch echt wat verkeerd, of hebben ze de verkeerde leerlingen te pakken.

[.oisyn]

Verwijderd schreef op 18 February 2003 @ 14:27:
offtopic:

Ik vind eigenlijk dat "Games Programmeren" , in z'n geheel niet op een Informatica opleiding thuishoort. Het vak Informatica, gaat zoals de naam al zegt over Informatie Voorziening binnen organisaties etc. (op allerlei vlak). Omdat men toevallig met de PC's die hiervoor als hardware worden ingezet ook Spelletjes kan spelen, is eigenlijk meer toeval.
Als een opleiding z'n leerlingen niet voldoende kan motiveren met de normale vakken die met IT te maken hebben, doen ze naar mijn mening toch echt wat verkeerd, of hebben ze de verkeerde leerlingen te pakken.

niet mee eens, als je kijkt naar de complexiteit van bepaalde aspecten, zoals computer graphics, physics en A.I., dan zijn dat gewoon hele opleidingen apart. En dat gaat echt wel een stukje verder dan zo'n algemene informatica opleiding hoor. Gamedev scholen beginnen nu zo langzamerhand uit de grond te komen in nederland (en andere landen), game development wordt eindelijk ook eens serieus genomen.

Natuurlijk, de hele informatica-opleiding toespitsen op gamedevelopment zou niet goed zijn, maar vakken als computer graphics en kunstmatige intelligentie worden nu ook al gegeven binnen een informatica-opleiding. Waarom zou iets als gamedesign of gamedevelopment als vak daar niet tussen passen?

En als je vindt dat de programmeerkant van gamedevelopment niets te maken heeft met informatica dan heb je het niet begrepen, en heb je er ook geen idee van wat erbij komt kijken om een complex recreatief stukje software te ontwikkelen

[Verwijderd]

.oisyn schreef op 18 February 2003 @ 14:33:

[...]


En als je vindt dat de programmeerkant van gamedevelopment niets te maken heeft met informatica dan heb je het niet begrepen, en heb je er ook geen idee van wat erbij komt kijken om een complex recreatief stukje software te ontwikkelen

Zekers, het ontwikkelen van een Formule 1 auto is ook zeer complex, toch zie ik ze dat niet op een monteursopleiding krijgen .

Ik zeg zekers niet dat het ontwikkelen van Games niet complex is, of zomaar iets simpels is. Absoluut niet. Echter ben ik wel van mening dat het twee zeer gescheiden werelden zijn, die toevallig gebruik maken vandezelfde hardware, en games ondanks dat er bepaalde technieken worden gebruikt (ai, etc.) niks met Informatica (lees automatisering) te maken hebben. Wel ben ik van menig dat menig 'normaal programmeur' nog wel een en ander kan leren van gameprogrammeurs mbt. tot het optimaliseren van code etc.

Hernoem het vak dan desnooods tot Computerkunde of iets dergelijks., in ieder geval uit de VanDale:

in·for·´ma·ti·ca (de ~)

1 leer van het verzamelen en de verwerking van gegevens m.b.v. computers

[ Voor 13% gewijzigd door Verwijderd op 18-02-2003 14:47 ]

[kmf]

Verwijderd schreef op 18 februari 2003 @ 14:41:
[...]


Zekers, het ontwikkelen van een Formule 1 auto is ook zeer complex, toch zie ik ze dat niet op een monteursopleiding krijgen .

Ik zeg zekers niet dat het ontwikkelen van Games niet complex is, of zomaar iets simpels is. Absoluut niet. Echter ben ik wel van mening dat het twee zeer gescheiden werelden zijn, die toevallig gebruik maken vandezelfde hardware, en games ondanks dat er bepaalde technieken worden gebruikt (ai, etc.) niks met Informatica (lees automatisering) te maken hebben. Wel ben ik van menig dat menig 'normaal programmeur' nog wel een en ander kan leren van gameprogrammeurs mbt. tot het optimaliseren van code etc.

Hernoem het vak dan desnooods tot Computerkunde of iets dergelijks., in ieder geval uit de VanDale:

[...]

Informatica is een breed gebied. Je hebt informatievoorziening, beheersing van IT maar ook ontwikkeling van IT. Een game ontwikkelen kan tot het laatste behoren.

Het is nu ook maar de vraag of een spel ontwikkelen het doel is of de hulpmiddel. Willen wij wel een spelontwikkelaar uitspugen na een opleiding? Of willen we het proces van "een spel ontwikkelen" gebruiken om de daarbij bbehorende processen te leren aan studenten?

Dat wordt nu ook min of meer gegeven, alleen staat het nu helemaal los van elkaar. AI, programmeren, plannen, grafisch vormgeven, werken met databases, koffiezetten, whatever. Maar door het in een vorm te gieten als een spelontwikkelingsproces en dit te verspreiden over een langer periode, kan je de losse modules die wij geven aan elkaar plakken en doet een student die module ook echt ERGENS voor.

Hoe vaak hoor ik in de kantine niet een student zeggen: "ja ik had die vak gehaald, maar weet absoluut niet meer waar het over ging. Had het een dag van tevoren geleerd". Dit project zal moeten zorgen dat zij het geleerde ook echt onthouden en gebruiken en toepassen.

Enne... ga jij in een monteursopleiding liever een carborateur in elkaar zetten of een hotrod (ook al werkt ie niet goed)

[ Voor 4% gewijzigd door kmf op 18-02-2003 14:56 ]

[Verwijderd]

.oisyn schreef op 18 februari 2003 @ 14:13:

[...]


C++ is nou juist de lagere programmeertaal... Een gamescripttaal is een voorbeeld van een 'hogere' programmeertaal

Ten opzichte van Assembly is C++ toch best wel hoog Maar inderdaad een gamescripttaal wordt tegenwoordig als 'hogere' programmeertaal beschouwd.

[Verwijderd]

Wat heb je nodig voor spelontwikkeling:

1. Creatieve mensen
2. Iemand op de mensen behorend bij punt 1 onder controle te houden

Verder verwijs ik je uiteraard net als .oisyn door naar GameSkool

[.oisyn]

Verwijderd schreef op 18 februari 2003 @ 14:41:
[...]


Zekers, het ontwikkelen van een Formule 1 auto is ook zeer complex, toch zie ik ze dat niet op een monteursopleiding krijgen .

ik bedoelde niet dat ik dacht dat jij het niet complex vond, ik bedoelde dat het bij complexe games zeker wel informatica, en dus informatie voorzieningen is

Neem bijvoorbeeld een 3d scenegraph, een bepaalde datastructuur die uit een database komt, en om een scene te renderen moet je een bepaalde query doen op die datastructuur, die alleen teruggeeft wat je daadwerkelijk nodig hebt (dus wat getekend moet worden). Is dat werkelijk zo anders dan een database applicatie in de informatie voorziening? Hell, het is gewoon informatie voorziening. Ordening van datastructuren (informatie dus) en het verwerken van grote lappen data. Dat heeft alles met informatievoorziening te maken

Games worden niet meer door 2 mensen in hun garage geprogrammeerd, daar komt heel wat planning en ontwerp bij kijken, net als bij normale applicaties in de informatie voorziening. Waarom is het dan anders? Het is software development in de volle betekenis van het woord. En waar wordt dat geleerd? Juist, op een informatica opleiding

Wel ben ik van menig dat menig 'normaal programmeur' nog wel een en ander kan leren van gameprogrammeurs mbt. tot het optimaliseren van code etc.

mwoa, imho leef je 10 jaar terug. Elk bitje wordt niet meer omgedraaid om het zo snel mogelijk te maken hoor. Dat is mierenneukerij, bovendien niet meer nuttig en al helemaal ondoenbaar met de grote lappen code die geproduceerd worden. Natuurlijk moet het zo snel mogelijk, maar je zult je algoritme aan moeten passen om iets sneller te krijgen ipv die 3 assembler instructies van volgorde verwisselen zodat ze gepipelined kunnen worden en je er 3 clock cycles extra uit perst

[slm]

.oisyn schreef op 18 February 2003 @ 14:57:
mwoa, imho leef je 10 jaar terug. Elk bitje wordt niet meer omgedraaid om het zo snel mogelijk te maken hoor. Dat is mierenneukerij, bovendien niet meer nuttig en al helemaal ondoenbaar met de grote lappen code die geproduceerd worden. Natuurlijk moet het zo snel mogelijk, maar je zult je algoritme aan moeten passen om iets sneller te krijgen ipv die 3 assembler instructies van volgorde verwisselen zodat ze gepipelined kunnen worden en je er 3 clock cycles extra uit perst

offtopic:
en dát is dus precies waar het de laatste 10 jaren is misgegaan in programinderland.... -_-;

je ziet nu dat je voor een stom wordprocessing progje inmiddels al een mega pc nodig hebt omdat het anders niet zo lekker draait. "Mwah dat geheugen dat gelekt wordt, wie let daar nou op? Dan moet je d'r maar wat meer embeetjes indoen hè." Ik denk niet dat het verstandig is deze Windows-mentaliteit te prediken op een school.... Je ziet dan namelijk games of andere programma's op de markt komen met een kwaliteit die men vroeger (hoor mij nou) niet eens als béta durfde aan te bieden.

[.oisyn]

slm schreef op 18 February 2003 @ 16:48:
[...]


offtopic:
en dát is dus precies waar het de laatste 10 jaren is misgegaan in programinderland.... -_-;

ik begrijp wat je bedoelt en ben het met je eens dat veel apps van tegenwoordig enorm brak in elkaar gezet zijn, met de "je pc is toch wel snel genoeg" gedachte in het achterhoofd. Maar dat was niet wat ik bedoelde

games en veel professionele/industriele bewerkingsprogramma's (nee, MS office hoort daar niet tussen ) zitten nog altijd prima in elkaar. Toch zijn ze vrij complex. In deze programma's wordt weinig assembly gebruikt, omdat het gewoon te complex in elkaar zit en dus enorm slecht onderhoud baar is. Natuurlijk is het enorm belangrijk dat bijvoorbeeld een photoshop filter snel werkt, maar door de complexiteit ervan is het veel belangrijker het algoritme zelf goed uit te denken in plaats van alles maar te implementeren in assembly zodat je er wat extra cycles uit kunt persen. Dat zou ook niet zinnig zijn: die extra cycles op een gigahertz draaiende CPU merk je niet. Die factor 5 versnelling omdat je een ander (beter) algoritme gebruikt merk je wel

Maar ja, er wordt natuurlijk ook heel wat in elkaar geprutst, en dat is een direct gevolg van de snelheid boost die de processoren gehad hebben. Je hebt nou eenmaal enorm veel cpu-kracht tot je beschikking, dus het is voor relatief simpele programma's zoals word processors niet echt belangrijk je bezig te houden met allerlei optimalisaties, zodat je het developmenttraject kunt verkorten, en dus geld kunt besparen. Tot overmaat van ramp voor de mensen met de wat langzamere pc's natuurlijk

Goed, ik ben het met je eens dat ze op school eens wat meer aandacht zouden moeten besteden aan bepaalde algemene optimalisatie technieken (zoals bijvoorbeeld het aantal geheugen allocaties klein houden en dergelijke), maar aan de andere kant is het gros wat afstudeert wel een stel prutsers die dat soort dingen dus echt niet zullen snappen, dus de vraag is of je je daar als docent wel mee bezig wilt houden

[Verwijderd]

slm - maar 10 jaar geleden kon je een spel nog 1 je eentje in 8 maanden maken.

Met de grootte van de projecten van tegenwoordig is dat allemaal wat anders geworden.
*Natuurlijk* wordt er alles aan gedaan om het zo snel mogelijk te krijgen en om geen memoryleaks te hebben.
En (Oisyn) als je voor een console progt zul je redelijk vaak toch "je instructies van volgorde moeten verwisselen", naar pipeline-stalls en cache-trashing kijken etc.


Maar er is een verschil tussen 20000 regels code optimizen of 950K regels code


Dus : optimize alleen de dingen die er toe doen.
En in 90% van de gevallen is dat inderdaad eerder het algorithme dan de individuele instructies.

Slm : dat je wordprocessor zo traag is komt voornamelijk doordat je nu in een multitasking operating system een wordprocessor draait waarvan iedereen verwacht dat ie ook wel even spellings- en grammatica-checking on-the-fly doet etc.

Als jij vind dat je dat niet nodig hebt zijn er genoeg "low-profile" word-processors die sneller werken dan WP5.1 vroeger

Het ligt er dus maar aan wat je wilt - grafische geilheid en veel features (ten koste van snelheid) of snelheid vice versa.