Ik ga mischien een hoop mensen hun dromen aan stukken schieten maar ik moet het zeggen. Veel mensen onderschatten het werk dat in een game kruipt. In modernere games kruipt al makkelijk 20 tot 30 man-jaar.
Nog enkele tips en opmerkingen.
- Meer dan 40% van de afgewerkte games die ontwikkeld worden floppen. 30% haalt zijn ontwikkeling er goed uit, en nog een 30% maakt echt gigantisch veel winst. Dat zijn dan de kaskrakers zoals halflife, quake, UT, ... Die eerste 40% zijn meestal beginnende bedrijfjes. Veel meer games worden begonnen maar nooit afgemaakt. Waar echt geld mee te verdienen is is de console markt. De PC markt is momenteel bedroevend vanuit ontwikkelaars standpunt bekeken. Er wordt momenteel geschat dat elk voor elk game dat verkocht wordt er ongeveer 10 kopies worden gemaakt. Bij game consoles ligt dit aantal veel lager.
- Kijk vooruit, volg revolutionaire en nieuwe dingen die tegen de tijd dat je game uitzijn wel eens common goods zouden kunntn zijn op de voet.
- Games ontwikkelen kost immens veel geld, en het moet op zeer korte termijn (tussen de 4 en 8 weken) al hun ontwikkelingskosten van 2 of 3 jaar eruit halen. Zelf een bedrijfje oprichten is bijna onmogelijk. Grote firma's zoals ea willen slechts enkel ergens geld in pompen als het idee hun aanstaat, en als je dan nog liefst al "iets" kan tonen.
- Zonder doorzettingsvermogen kom je nergens. Games worden steeds ingewikkelder, dank zij de verhuis van meer en meer features naar de hardware, waarvoor allemaal een api bestaat.
- "Basiskennis" van C(++) is niet voldoende. Je moet behoorlijk wat ervaring ermee hebben.
- Begin niet van "en nu gaan we een game maken". Probeer eerst kleine dingen apart. Er zijn ongetwijfeld enorm veel dingen die je nodig moet hebben waarvan je geen flauw benul hebt. Ga eerst wat op onderzoek uit. Als je een 3d-engine ala quake of ut wil maken kan bvb een geinterpreteerde script taal handig zijn. Om dit dan te versnellen in uitvoeren compileer je dan zoiets best naar een soort bytecode. Nog zoiets is multithreading. Zonder dat geraak je tegenwoordig ook niet ver. Hiervan is intertask communication dan het moeilijkste. Ook met file formaten moet je lieft al wat geprutst hebben. Probeer bvb eens van een texture uit een quake .pak bestand te plukken.
- Je mag geen schrik hebben van alles weg te gooien als je niet echt tevreden bent over wat je ziet. Als je een nieuw idee hebt (of ergens tegenkomt), en je denkt dat dat veel flexibeler, sneller en comfortabeler draait, aarzel dan niet. Ik ken genoeg projecten die verprutst zijn door het systeem "laten we dat er ff vlug iets aan toevoegen". Je moet enig benul hebben van modulaire softwaredesign.
- Neem voor te beginnen niet te veel hooi op je vork. Probeer niet alles zelf te doen, en als je dat dan toch doet, verwacht dan niet dat het er meteen uitziet als de quake 3 engine. o.a textures en 3d models maken is een job apart.
- Veel (vooral beginnende) mensen willen meteen resultaat zien van wat ze aan het programmeren zijn. Verwacht niet dat je op 1 maand (full time werken) een game engine hebt draaien. Reken eerder een half jaar codem eer je iets pre-alpha hebt.
- Maak een goede planning voor je begint te coden. Analyses mogen dan op school (of waar dan ook) saai lijken, voor een groot project als een game heb je er wel een nodig. Dit moet niet supergedetailleerd zijn, maar het moet wel duidelijk zijn wat er moet gebeuren en in welke volgorde alles gedaan gaat worden. Voordat je aan je analyse begint moet je trouwens eerst een projectomschrijving maken van wat je precies allemaal wilt, en heel goed afwegen wat je nu eigenlijk echt nuttig is, en of dit wel mogelijk is.
- Maak niet de fout van meteen met de graphics te beginnen, een game is veel meer dan dat. De graphics (= renderer) laat je voor redelijk op het einde. Begin niet met een super high-end renderer te maken die tegen de tijd dat je game uitkomt verouderd is. Begin met een ruwe renderer, en een deftig test systeem, dat niet meteen graphics nodig heeft.
- Je zal waarschijnlijk ook ingewikkeldere practische versies van wiskundige algorithmes nodig hebben zoals CRC32, encryptie, compressie, 3d matrix transformaties, ...
Zie dat je die +-begrijpt.
- probeer wat met communicatie (liefst over IP/udp) te prutsen. Een modern game zonder mp optie staat nergens.
- Kies een goede programmeertaal. De meeste games zijn nog steeds in plain C geschreven, zoals de q3 engine oa. C++ begint zijn opmars te maken (zoals in de UT engine), maar dan moet je al behoorlijk wat kaas van oop gegeten hebben. Kies geen dingen zoals VB of Delphi om je dingen in te ontwikkelen, die doen teveel dingen achter je gat en zijn te traag voor een full-blown game engine, en de specificaties van de taal kunnen op 123 veranderd worden omdat ze enkel van 1 softwarefirma afhankelijk zijn (kijk maar naar vb.net). C#, Java en VB.NET zijn al helemaal af te raden, die kunnen enkel nog geinterpreteerd worden, en dit gaat zwaar ten koste van fps. Veel alternatieven zijn er eigenlijk niet voor C en C++.
- Leer ordelijk coden en zet commentaar bij ingewikkelde stukken code van wat en hoe je iets probeert te doen. Dat maakt achteraf het debuggen iets simpeler. Voorzie ook een debug logging mechanisme. Dit is een voorbeeldje van code dat je niet wil tegenkomen in een groot project:
code:
1
2
3
4
5
6
7
| int functie_5(char* test, int a) {
int i; int c
for (i = strlen(test); i; i--) {
printf("%c", test[i]);
if (i == 3)
printf("BOE")
; return 1; } |
Lach er niet mee, maar zo'n dingen kom ik dagelijks tegen. Zie dat alles een deftige en duidelijke naam heeft. Heb geen schrik om een functienaam van 10 characters te maken, als dat duidelijker is, en die globaal beschikbaar moet zijn. voor locale functies kan je al iets "cryptischere" namen gebruiken, maar dit is echter wel afgeraden als het redelijk ingewikkelde functies zijn.
- Je hebt best ook al wat ervaring en inzicht met optimalisaties. Sommige implementaties kunnen doen wat je wil doen, maar mischien kan het wel 100x sneller. Ga ook geen dingen optimaliseren die maar 2 of 3 keer gebruikt worden. Voorzie een timing mechanisme dat timed hoeveel tijd elke functie neemt om uit te voeren, en een count bijhoudt van hoeveel keer die uitgevoerd wordt.
Ik wil hier niemand echt mee ontmoedigen, maar dit is slechts een fractie van de dingen waar je rekening mee moet houden. Ik ken genoeg projecten die met zulke problemen te kampen hebben/hadden. De meest gemaakte fout daar is de 'start coding now, we'll define the project later' methode gebruiken voor grotere projecten. Ik hoop dat dit van enige hulp kon zijn, en dat de mensen niet meteen de hoop opgeven.
I heard if you play the XP CD backwards, you get a satanic message. Thats nothing compared to what happens if you play it forward, then it installs Windows XP born2oc.be - Facts Of Life
:strip_icc():strip_exif()/u/6652/avatar10170_4.jpg?f=community){kind=avatar}
)
)) /u/2046/pooh2.png?f=community)
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
/u/23440/c.png?f=community)
:strip_icc():strip_exif()/u/26392/3wideavatar1.jpg?f=community){kind=avatar}
:strip_icc():strip_exif()/u/26703/241202.jpg?f=community)
(solly). En je leert zo mooi mogelijk programmeren en dat vink dus nix, ik snap het doel wel. Maar voor games heb je snelheid en efficientie nodig. Dus ja dan maar VC++ en zo weinig mogelijk voor gedefinieerde zooi gebruiken, scheelt soms snelheid en zeker controle.
:strip_icc():strip_exif()/u/21865/shoe_60x60.jpg?f=community)
/u/21424/icoon.png?f=community)
* dus ik weet dat het veel moeite gaat kosten .. maar dan nog .. 't lijkt me fantastisch
:strip_icc():strip_exif()/u/19278/mzi.zvvwxczh.60x60-75.jpg?f=community)
ik hou het meestal op kleinere gamepjes zoals board games of space invaders / breakout etc natuurlijk freeware :strip_icc():strip_exif()/u/14853/bluepiSW.jpg?f=community)
:strip_exif()/u/13818/episodebutler_60x60.gif?f=community)
/u/16515/crop618754fce4d81_cropped.png?f=community)
