Beginnen aan OpenGL

[Gamebuster]

Ik wil OpenGL gaan leren voor het maken van een top-down 3D game.

Ik wil kunnen werken met mooie licht-effecten, transparantie, blur, kleurenfilters, "vervorming" zoals golven van hitte of een object in het water dat vervormt door het water.

Mijn doel platformen zijn iPad, iPod, Mac OS X en Windows.

Het gaat hier om een onderwater-wereld met bestuurbare vis-achtige wezens die je van bovenaf bekijkt. Voor een voorbeeld kan je aan spore's celfase denken:


Ik heb binnen java wel een paar keer geexperimenteerd met OpenGL 1.0, maar de performance die ik haalde was slecht, waarschijnlijk omdat ik allemaal losse calls naar glVertex3f() deed en mogelijk omdat het in Java was.

Ik ken het princiepe van OpenGL 1.0 wel een beetje; ik weet hoe ik 2D vector graphics op het beeld kan toveren en weet hoe ik 2D en 3D objecten textures kan geven. Ook heb ik enkele keren geexperimenteert met licht binnen OpenGL ES 2.0 voor de iPhone/iPod/iPad.

Ik weet echter niet hoe ik efficient met OpenGL moet omgaan voor grotere projecten.

Verder ben ik een beginnend maar snel groeiend C++ en Objective-C programmeur (pas enkele weken mee bezig, maar gaat lekker naar mijn mening), voortgegroeid uit bijna 3 jaar fulltime PHP ervaring en 1 jaar fulltime Java ervaring en ben OOP-geil sinds mijn java ervaringen.

Waar kan ik het beste beginnen met OpenGL? Ik zoek een uitgebreide, duidelijke en crossplatform tutorial die op basis van voorbeelden mij het complete OpenGL pakket, inclusief zijn utilities, kan leren, waarbij ook een focus ligt op hoe je de beste performance kan behalen en niet alleen hoe je iets werkend krijgt.

Voor de geinteresseerden: Ik heb een plan van 2 jaar om een MMO-RTS game te maken voor de genoemde platformen. Ik weet het, gestoord idee zonder OpenGL of C++ ervaring, maar op deze manier heb ik ook alle andere talen geleerd: gewoon doen. Heb er verder geen werk of school naast, ik verdien mijn geld ermee dus heb fulltime tijd ervoor. Voor dit spel wordt nu gewerkt aan het financiele gedeelte.

[ Voor 10% gewijzigd door Gamebuster op 19-08-2010 19:48 ]

[alex3305]

Even zo uit mijn hoofd en met wat Google-skills:
http://gamedev.net/
http://www.google.com/search?q=iPhone+OpenGL

Hiermee denk ik dat je al een heel eind kunt komen. Daarnaast is het ook handig om GLSL te leren voor verschillende effecten.

[beany]

Voor de geinteresseerden: Ik heb een plan van 2 jaar om een MMO-RTS game te maken voor de genoemde platformen. Ik weet het, gestoord idee zonder OpenGL of C++ ervaring, maar op deze manier heb ik ook alle andere talen geleerd: gewoon doen. Heb er verder geen werk of school naast, ik verdien mijn geld ermee dus heb fulltime tijd ervoor. Voor dit spel wordt nu gewerkt aan het financiele gedeelte.

Ah, je hebt een idee voor een spel, maar je mist nog het 1 en het ander:

- De kennis om het te maken
- De financiele middelen
- Mankracht(geloof me, een levensvatbaar plan lukt niet in je 1tje. Vooral een MMO niet)

Heel veel succes!

Begrijp me niet verkeerd, ik gun het succes je echt wel. Maar er zijn vele studio's met veel meer resources. Je hebt dus enorme concurrentie. Je moet toch echt wel een brilliant plan hebben wil een investeerder je de financiele middelen verlenen. En geloof me, de vragen die je stelt in je openingspost zijn dan niet relevant meer(lees: die kennis ga je dan inhuren).


edit: ow ja, onderschat de kosten voor marketing niet!! Een soft-launch is te traag tenzij je het geinvesteerde niet perse binnen pak-em-beet 5 jaar terug wil verdienen...

[ Voor 7% gewijzigd door beany op 19-08-2010 20:47 ]

[NMe]

Ik zou het gebrek aan kennis en middelen en de benodigde tijd inderdaad niet zo onderschatten als ik jou was.

Ik heb zelf veel geleerd van het boek OpenGL Game Programming (sorry, ben mobiel aan het browsen dus even geen linkje). Het zal inmiddels enigszins achterhaald zijn en de voertaal in het boek is C++ in plaats van Objective C, maar ik denk dat het je wel kan helpen om wat best practices aan te leren.

[roy-t]

Ik kan je allemaal tips geven maar:

Voor de geinteresseerden: Ik heb een plan van 2 jaar om een MMO-RTS game te maken voor de genoemde platformen. Ik weet het, gestoord idee zonder OpenGL of C++ ervaring, maar op deze manier heb ik ook alle andere talen geleerd: gewoon doen. Heb er verder geen werk of school naast, ik verdien mijn geld ermee dus heb fulltime tijd ervoor. Voor dit spel wordt nu gewerkt aan het financiele gedeelte.

Doet me heel erge zorgen maken.

Kun je even aangeven hoe bekend je bent met de volgende (game gerelateerde) fenomenen:

-Scenegraph
-Game state management
-Vertex Shader
-Pixel Shader
-Content management
-Network connection management
-(P2P) Lock step
-Client/Server
-Client Side prediction/ Server side prediction
-Sharding

Algemeen:
-OO
-Inheritance
-Polymorphism
-Interfaces


Als je nu zou zeggen, van de bovenste categorie ken ik bijna alles bij ziele, behalve vertex shaders en pixel shaders. Dan zou het misschien een goed idee zijn om te beginnen met een grote game maken. (Alleen op grafisch gebied moet je dan nog een hoop bijleren). Als je met dingen zoals een SceneGraph of Game state management nog nooit gespeeld hebt moet je echt die MMO 2 jaar in de koelkast zetten en een baan zoeken om dan in je vrije tijd prototypes te maken om bekend te worden met deze fenomenen, zo heb je ook alvast een buffer voor wanneer je er full time aan wilt gaan werken. Het zelfde geld voor lock step en de andere netwerk gerelateerde dingen (MMOs zijn echt de meest ingewikkelde programmas om netwerk code voor te schrijven).

Heb je met van een van de dingen uit algemeen nog geen kaas gegeten dan kun je het beste de MMO nog 8 jaar in de koelkast zetten en van scratch voorzichtig beginnen.

Verder is er natuurlijk ook nog de organisatorische kant (waar ik maar niet eens over begin).


Anyway, als je er echt 10000% zeker van bent dat JIJ nu zomaar even een MMO-RTS kan maken in 2 jaar en dat je daarna 2 jaar aan gedorven inkomsten kan goedmaken dan kun je misschien even kijken naar de volgende linkjes:


Scene graphs basics http://www.gamedev.net/re...ming/features/scenegraph/
Network programming basics http://gafferongames.com/...ow-about-game-networking/
GUIs http://sol.gfxile.net/imgui/ch01.html, http://www.gamasutra.com/...overies_what_players_.php
Graphicshttp://www.wolfgang-engel.info/blogs/, http://riemers.net/ (dx)


Edit: Even als achtergrond, op dit moment ben ik al sinds de eerste release van het XNA framework (4 jaar geleden) bezig met prototypes en mini games maken (zowel 2D als 3D). Slechts sinds kort vind ik mijzelf capabel genoeg om te werken aan een echte game. Daarom werk ik sinds kort als lead-dev aan Hollandia als vervanger van de vorige ontwikkelaar, wat helaas betekende dat ik bijna alles moest herschrijven. Dit is een 2D platform adventure game waarvoor we een bestaande physics engine gebruiken (Farseer) toch moet ik mijn uiterste best doen om alles heel erg netjes in elkaar te zetten, ondanks dat 2D een stuk makkelijker werkt in je hoofd en dat we alleen maar simpele pixelshaders gebruiken en de meeste graphics gewoon mooi zijn omdat de artwork mooi is, niet door fancy effecten. Ik hoef je niet te vertellen hoeveel simpeler deze game is om te bouwen dan zelfs maar een RTS die je over het netwerk kan spelen, laat staan een MMO. Vandaar dat ik wat sceptisch voorzichtig ben, helemaal omdat je aangeeft om dit te doen als werk en er dus voor jou ontzettend veel op het spel staat.

Op het XNA forum heb ik een paar mensen (programmeurs, maar niet game programmeurs) hun baan zien stoppen om daarna een jaar aan een game te werken (die uiteindelijk niet veel voorstelde omdat ze toch een hele nieuwe tak van sport moesten leren en vaak geen geld hadden om artwork en assets te laten maken). Sommige mensen zijn daar echt helemaal kapot aan gegaan door die gok te nemen die jij nu ook overweegt.

Dus wees voorzichtig, maar laat dit praatje je niet percee tegenhouden . Heb altijd een backup plan, al is het maar een shitty betaald 32 uur baantje. Dat laat nog 136 uur per week over voor je project .

[ Voor 25% gewijzigd door roy-t op 19-08-2010 20:57 ]

[Gamebuster]

roy-t schreef op donderdag 19 augustus 2010 @ 20:48:
Ik kan je allemaal tips geven maar:
[...]
Doet me heel erge zorgen maken.

Kun je even aangeven hoe bekend je bent met de volgende (game gerelateerde) fenomenen:

Ik ben niet zo goed met termen, simpelweg omdat ik geen opleiding heb gehad en je die termen dus minder vaak tegenkomt binnen tutorials en online documentatie. Maar toch, even het lijstje afgaan:

-Scenegraph
Nooit van gehoort.

-Game state management
Nooit van gehoort, maar met een beetje Logica verwacht ik dat "Game State Management" losjes vertaald naar hoe game-state (locatie van objecten, spelers, etc) is opgeslagen in het geheugen en hoe deze eventueel opgeslagen kan worden zodat de speler zijn spel voort kan zetten, of hoe deze verzonden kan worden over het netwerk.

-Vertex Shader
-Pixel Shader
Hier heb ik wel eens van gehoort, weet ook ongeveer wat een shader zou kunnen maar ik weet alleen het verschil tussen deze 2 niet echt. Vermoedelijk is een vertex shader het "beinvloeden" van de coordinaten (soort transform/scale) en de pixelshader het beinvloeden van de uiteindelijke pixels. Maarja, dat moet ik nu nog gaan leren binnen OpenGL.

-Content management
Die term ken ik nog van webdevelopment. Of hier ook hetzelfde bedoeld wordt betwijvel ik, maar ergens zullen er wel overeenkomsten zijn.

-Network connection management
-(P2P) Lock step
-Client/Server
-Client Side prediction/ Server side prediction
Heb ervaring met networking bij de ontwikkeling van diversen ajax-based chats, de ontwikkeling van een HTTP server en het maken van een kleine P2P chat in Java om UDP hole punching te leren. Ik ben me ook bewust van problemen die kunnen ontstaan bij vertraging en de vereiste correctie daarvan. Daar zal ik echter nog wel veel naar moeten googlen.

Heb ook enkele kleine halve 2D games gemaakt, voornamelijk kleine platform games met simpele physics, puur om te experimenteren met networking, physics, besturing, etc. Heb ook diversen puzzelspelletjes gemaakt in Javascript.

-Sharding
Nooit van gehoort.

Algemeen:
-OO
Object Oriented; jaar geleden mee begonnen toen ik begon met Java. Erg prettige manier van programmeren.

-Inheritance
Extenden (uitbreiden) van bestaande classes

-Polymorphism
Het maken van een nieuwe class, gebaseerd op meerdere classes. Niet mogelijk in PHP, Objective-C of Java, is nieuw voor mij binnen C++.

-Interfaces
Een interface omschrijft waaraan een class moet voldoen, waarna je meerdere implementaties ervan kan schrijven. Gebruikte ik veel in Java. In Objective-C heten ze "protocols".

Als je nu zou zeggen, van de bovenste categorie ken ik bijna alles bij ziele, behalve vertex shaders en pixel shaders. Dan zou het misschien een goed idee zijn om te beginnen met een grote game maken. (Alleen op grafisch gebied moet je dan nog een hoop bijleren). Als je met dingen zoals een SceneGraph of Game state management nog nooit gespeeld hebt moet je echt die MMO 2 jaar in de koelkast zetten en een baan zoeken om dan in je vrije tijd prototypes te maken om bekend te worden met deze fenomenen, zo heb je ook alvast een buffer voor wanneer je er full time aan wilt gaan werken. Het zelfde geld voor lock step en de andere netwerk gerelateerde dingen (MMOs zijn echt de meest ingewikkelde programmas om netwerk code voor te schrijven).

Heb je met van een van de dingen uit algemeen nog geen kaas gegeten dan kun je het beste de MMO nog 8 jaar in de koelkast zetten en van scratch voorzichtig beginnen.

Verder is er natuurlijk ook nog de organisatorische kant (waar ik maar niet eens over begin).


Anyway, als je er echt 10000% zeker van bent dat JIJ nu zomaar even een MMO-RTS kan maken in 2 jaar en dat je daarna 2 jaar aan gedorven inkomsten kan goedmaken dan kun je misschien even kijken naar de volgende linkjes:


Scene graphs basics http://www.gamedev.net/re...ming/features/scenegraph/
Network programming basics http://gafferongames.com/...ow-about-game-networking/
GUIs http://sol.gfxile.net/imgui/ch01.html, http://www.gamasutra.com/...overies_what_players_.php
Graphicshttp://www.wolfgang-engel.info/blogs/, http://riemers.net/ (dx)


Edit: Even als achtergrond, op dit moment ben ik al sinds de eerste release van het XNA framework (4 jaar geleden) bezig met prototypes en mini games maken (zowel 2D als 3D). Slechts sinds kort vind ik mijzelf capabel genoeg om te werken aan een echte game. Daarom werk ik sinds kort als lead-dev aan Hollandia als vervanger van de vorige ontwikkelaar, wat helaas betekende dat ik bijna alles moest herschrijven. Dit is een 2D platform adventure game waarvoor we een bestaande physics engine gebruiken (Farseer) toch moet ik mijn uiterste best doen om alles heel erg netjes in elkaar te zetten, ondanks dat 2D een stuk makkelijker werkt in je hoofd en dat we alleen maar simpele pixelshaders gebruiken en de meeste graphics gewoon mooi zijn omdat de artwork mooi is, niet door fancy effecten. Ik hoef je niet te vertellen hoeveel simpeler deze game is om te bouwen dan zelfs maar een RTS die je over het netwerk kan spelen, laat staan een MMO. Vandaar dat ik wat sceptisch voorzichtig ben, helemaal omdat je aangeeft om dit te doen als werk en er dus voor jou ontzettend veel op het spel staat.

Op het XNA forum heb ik een paar mensen (programmeurs, maar niet game programmeurs) hun baan zien stoppen om daarna een jaar aan een game te werken (die uiteindelijk niet veel voorstelde omdat ze toch een hele nieuwe tak van sport moesten leren en vaak geen geld hadden om artwork en assets te laten maken). Sommige mensen zijn daar echt helemaal kapot aan gegaan door die gok te nemen die jij nu ook overweegt.

Dus wees voorzichtig, maar laat dit praatje je niet percee tegenhouden . Heb altijd een backup plan, al is het maar een shitty betaald 32 uur baantje. Dat laat nog 136 uur per week over voor je project .

Ik heb een backup: ik ken web development. Ik heb ook financiele steun vanuit meerdere kanten. Voor mij is dit niet echt een risicovol plan gezien er zoveel steun is, en dat is de rede dat ik ook dit "risico" aanga. Als dit zou mislukken is er niets aan de hand; mijn omgeving is zich ervan bewust. Ik heb het 2 jaar gegeven, maar als achteraf blijkt dat ik meer ervaring nodig heb kan ik dit zonder problemen rekken naar meer jaren. Ik verwacht echter niet dat dit nodig zal zijn, maar ik verwacht zovaak iets niet. Ik heb de mogelijkheid dit "risico" veilig aan te gaan, dus ik doe het.

Ik heb ook financiele steun voor artwork, leveldesign, audio, GUI design, etc. Als ik mijn omgeving aantoon dat het programmeer-gedeelte in orde is zijn er 10.000en beschikbaar; hoe zekerder is dat het programmeer-gedeelte in orde is, hoe meer er geregeld kan worden. Veel meer is er ook niet nodig; heb bewust gekozen voor een onderwater-thema zodat er geen 3D werelden gemaakt hoeven worden (gewoon 1 grote plas water waarin de objecten random worden neergezet wanneer een speler daar in de buurt komt). Technisch gezien zit de gehele game in mijn hoofd. Ik ben ervan overtuigd dat het allemaal gaat lukken, zo niet, dan zorg ik ervoor dat het gaat lukken. Ik heb genoeg de tijd, maar de schatting staat op 2 jaar.

Ook is dit niet de 1e game die ik zal maken; ik ga me hoofdzakelijk focussen op de ontwikkeling van een MMO framework, een 2D platform motion framework, graphics framework voor 2D vector graphics, etc. Ik zou bestaande frameworks kunnen gebruiken, maar ik wil het juist allemaal zelf maken om zo alles te leren en absolute controle te hebben over de performance.

Hoe dan ook, ik ben er geen 10000% zeker van, maar ik ga het zeker proberen en ben een snelle leerling.

Ik zal je linkjes in ieder geval allemaal 'ff doorkijken. Bedankt voor je feedback.

[Gamebuster]

beany schreef op donderdag 19 augustus 2010 @ 20:35:
[...]


Ah, je hebt een idee voor een spel, maar je mist nog het 1 en het ander:

- De kennis om het te maken
- De financiele middelen
- Mankracht(geloof me, een levensvatbaar plan lukt niet in je 1tje. Vooral een MMO niet)

Heel veel succes!

Begrijp me niet verkeerd, ik gun het succes je echt wel. Maar er zijn vele studio's met veel meer resources. Je hebt dus enorme concurrentie. Je moet toch echt wel een brilliant plan hebben wil een investeerder je de financiele middelen verlenen. En geloof me, de vragen die je stelt in je openingspost zijn dan niet relevant meer(lees: die kennis ga je dan inhuren).


edit: ow ja, onderschat de kosten voor marketing niet!! Een soft-launch is te traag tenzij je het geinvesteerde niet perse binnen pak-em-beet 5 jaar terug wil verdienen...

Dat deel is dus al geregeld. + ik zou ook mensen kunnen inhuren, maar ik heb aangegeven het zelf te willen doen zover mogelijk.

Marketing: Het is de 1e MMO-RTS en de 1e MMO-RTS voor de iPad en het is gratis via steamplay en app-store. Het verdienmodel: micro-transacties voor extra unlocks... veeel unlocks. Die unlocks ga ik echter zelf niet maken, daarvoor moeten we externe gassies regelen. Dat doen we zodra de basis van de game functioneel is.

Overigens, de gehele game gaat geen 2 jaar duren; het ontwikkelen van een functionele basis heeft 2 jaar op de planning. Art, GUI, marketing, die unlocks, "leveldesign", perfectioneren, testfases etc volgen daarop en dat kan/zal zo weer een jaar of 2 extra geven.

Enige wat ik in die 2 jaar ga maken is een soort prototype, geen in-detail-uitgewerkt spel.

[ Voor 22% gewijzigd door Gamebuster op 19-08-2010 23:08 ]

[Verwijderd]

Ik denk dat je het zwaar onderschat (of jezelf zwaar overschat). Gezien je kennisniveau gaat het je niet lukken om in twee jaar een kwalitatieve goede game op de markt te zetten.

Nog even los van het feit of het technisch wel of niet haalbaar is, is de implementatie nog het "makkelijkst". Het moeilijkste is de gameplay goed hebben. Een game moet precies in balans zijn om niet te vervelen. Dit is waar de meeste games de mist in gaan, een goed uitgebalanceerde game maken is heel moeilijk. Zelfs in de professionele industrie gaat het hier nog vaak fout.

Verder denk ik dat als je snel iets wilt leren je meerdere boeken aan moet schaffen ipv uit tutorials leren. Boeken zijn kwalitatief meestal veel beter en uitgebreider. Koop een aantal over game design, opengl, network programming etc.

[alex3305]

Gamebuster schreef op donderdag 19 augustus 2010 @ 23:03:
[...]

Marketing: Het is de 1e MMO-RTS en de 1e MMO-RTS voor de iPad en het is gratis via steamplay en app-store. Het verdienmodel: micro-transacties voor extra unlocks... veeel unlocks. Die unlocks ga ik echter zelf niet maken, daarvoor moeten we externe gassies regelen. Dat doen we zodra de basis van de game functioneel is.

[...]

Het is nu de eerste MMO RTS en eerste MMO RTS voor de iPad. Dat is dus al een risico. Daarnaast weet ik niet zeker of je zomaar in de Steam catalogus kunt komen.

[Gamebuster]

alex3305 schreef op donderdag 19 augustus 2010 @ 23:18:
[...]

Het is nu de eerste MMO RTS en eerste MMO RTS voor de iPad. Dat is dus al een risico. Daarnaast weet ik niet zeker of je zomaar in de Steam catalogus kunt komen.

Er zijn zoveel simpele spelletjes in Steam, zo moeilijk zal het dus niet zijn.

En inderdaad, nu is het nog de 1e MMO-RTS. Ik had eerder tussen haakjes "nu nog wel" erachter gezet, maar om vergeten reden had ik dat weggehaald

Ik las namelijk dat er een C&C MMO-RTS komt ergens in 2011.

[ Voor 21% gewijzigd door Gamebuster op 19-08-2010 23:21 ]

[user109731]

Onderschat ook het C++-gedeelte niet, oppakken hiervan duurt toch wel even wat langer dan een Java of PHP. Niet eens zozeer de taal, maar wel hoe je er netjes mee omgaat in een groter project, zonder terug te vallen op C-achtige constructies. Als enige programmeur loop je een risico om dingen verkeerd aan te pakken, zorg iig voor een goed (!) boek

[NMe]

Gamebuster schreef op donderdag 19 augustus 2010 @ 23:20:
[...]

Er zijn zoveel simpele spelletjes in Steam, zo moeilijk zal het dus niet zijn.

Nu doe je het weer. Ook simpele spelletjes kosten veel, heel veel tijd, geld en resources. Denk aan art designers, level designers, programmeurs, projectleiders, enz. Jij wil al dat werk op je gaan nemen terwijl je van de meeste technieken die je alleen al voor het programmeren nodig gaat hebben geen kaas gegeten hebt. Denk je niet dat het handiger is als je je eerst toelegt op het leren van de benodigde technieken en dán pas "verplichtingen" aangaat voor het eindproduct? Je zegt wel dat je financiële steun hebt maar ik kan me niet voorstellen dat er iemand gek genoeg is om jou te financieren zonder daar enigszins iets voor terug te verwachten.

[Hydra]

Joh, hij wil niet horen dat het 'onmogelijk is'. Laat hem lekker. Het is zijn tijd/geld.

[Voutloos]

Wat dat betreft zou je een briljante post van curry rechtstreeks naar dit topic kunnen kopieren: curry684 in "[vb 6.0] Achtergrond plaatje meebewegen ..." .

[Woy]

Hydra schreef op vrijdag 20 augustus 2010 @ 10:22:
Joh, hij wil niet horen dat het 'onmogelijk is'. Laat hem lekker. Het is zijn tijd/geld.

Het is natuurlijk ook niet 'onmogelijk'. Het is hooguit zeer onwaarschijnlijk!

[beany]

Gamebuster schreef op donderdag 19 augustus 2010 @ 23:20:
[...]

Er zijn zoveel simpele spelletjes in Steam, zo moeilijk zal het dus niet zijn.

Heb je al een Game Design Document ? Een GDD is namelijk het ALLER EERSTE wat er digitaal gemaakt wordt(na de brainstorm sessies dus). Dit document is het hart van je game, de basis. Met dit document ga je de boer op om financieen binnen te halen. Ook dient dit document als basis voor alle volgende documenten(art work book(welke art work moet er gemaakt worden e.d.), technicsche documentatie(graphic engine, game engine, physics, sound, menu structuren, etc, etc, etc, etc, etc, etc, etc, etc, etc, etc, etc).

Ik heb het idee dat je nu eerst begint met programmeren voordat je ook maar iets op papier hebt staan wat het moet worden, tot in detail!

En vergeet je assets/content pipeline niet. Textures, models, levels, geluiden e.d. worden in tools gemaakt en
moeten op de 1 of andere manier in je game komen. Bij een development team zijn er mensen die dedicated met deze problematiek(lees: converter/import tools schrijven) bezig zijn.

Een tip: Kijk eens naar XNA( http://creators.xna.com ). Dit framework heeft al een heleboel voor je gedaan, je kan dan dus RELATIEF snel een game maken.

Nog een tip: UDK( http://www.udk.com/ ). Zelfde als XNA, misschien zelfs nog makkelijk

En de laatste tip: Unity3D( http://unity3d.com/ ). Valt in dezelfde categorie als de vorige 2 tips.

Deze frameworks nemen een hoop programmeer werk uit handen. Je hoeft je niet druk te maken om OpenGL e.d. Is allemaal voor je geregeld en je kan met alle deze frameworks prima games maken als eenling. Neemt niet weg dat het nog een hele toer is om zelfs met deze frameworks een game helemaal af te maken.............

[whoami]

Gamebuster schreef op donderdag 19 augustus 2010 @ 22:56:
[...]


-Polymorphism
Het maken van een nieuwe class, gebaseerd op meerdere classes. Niet mogelijk in PHP, Objective-C of Java, is nieuw voor mij binnen C++.

Ahum.
Als ik jou was, zou ik deze betekenis die je er aan geeft toch nog eens herbekijken.
Of beter nog: de definitie van polymorphisme opnieuw opzoeken ...
(Zeker mogelijk in Java (my god, als ik me goed herinner zijn alle methods in Java by default 'virtual').
En in C++ is het ook mogelijk.
Polymorphisme is gewoon één van de cornerstones van OO.

Ik heb een backup: ik ken web development. Ik heb ook financiele steun vanuit meerdere kanten. Voor mij is dit niet echt een risicovol plan gezien er zoveel steun is, en dat is de rede dat ik ook dit "risico" aanga. Als dit zou mislukken is er niets aan de hand; mijn omgeving is zich ervan bewust. Ik heb het 2 jaar gegeven, maar als achteraf blijkt dat ik meer ervaring nodig heb kan ik dit zonder problemen rekken naar meer jaren. Ik verwacht echter niet dat dit nodig zal zijn, maar ik verwacht zovaak iets niet. Ik heb de mogelijkheid dit "risico" veilig aan te gaan, dus ik doe het.

Met steun veronderstel ik dat je hier 'geldelijke' steun bedoelt ?
Denken die investereerders er ook net zo over ? Dat er niets aan de hand is, als blijkt dat het je binnen 2 jaar niet lukt ? En zijn ze dan nog altijd bereid om opnieuw hun duit in het zakje te doen ?
En wat gaan ze zeggen als blijkt dat hun centen gewoon in een bodemloze put verzeild zijn geraakt ?

[chris]

Mocht je eerst prototypes willen bouwen, dan kan je eens naar Cocos2D voor de iPhone kijken. Dat werkt alleen op iOS devices, maar is wel een handige abstractie om snel een game aan de praat te krijgen.

[michiel_]

Vraag wordt vaak genoeg gesteld. Nog even wat stof om over na te denken:

- http://www.gamedev.net/co...topic.asp?topic_id=525958
- http://sol.gfxile.net/mmorpg.html

(Ik weet dat het hier om MMORPG's gaat, maar de argumenten gaan nog steeds op)

[NMe]

Hydra schreef op vrijdag 20 augustus 2010 @ 10:22:
Joh, hij wil niet horen dat het 'onmogelijk is'. Laat hem lekker. Het is zijn tijd/geld.

Ik zeg niet dat het onmogelijk is. Het is goed mogelijk, en hij zal dit ook best allemaal kunnen. Maar niet binnen het genoemde tijdsbestek en waarschijnlijk ook niet op een winstgevende manier. Iemand die niet bereid is zo'n antwoord te accepteren als een valide mening moet zijn vraag niet stellen op een forum. Overigens heb ik niet de indruk dat de topicstarter ongevoelig is voor dit soort opmerkingen, dus jouw opmerking vind ik in turn weer een beetje jammer.

[Killemov]

Kijk ook eens naar Ogre. http://www.ogre3d.org/

Hiermee heb je in ieder geval een uitgangspunt waar je wat mee kunt pielen. Er zijn genoeg voorbeelden voor te vinden. De code zelf heeft speciale aandacht gekregen om zo duidelijk mogelijk te zijn en is daarnaast zeer goed gedocumenteerd. Er zijn al een aantal tweakers mee aan de slag gegaan.

Let er wel op dat je echt heel wat op de hals haalt als je er echt iets van wilt maken. Ik kan je aanraden om eerst wat kleine dingetjes te maken, waarbij je een bestaand idee opnieuw implementeert. Ter indicatie:
Eerste leercurve ogre: 80 uur
Tetris-kloon: 20 uur
Space-invaders: 40 uur
Arkanoid: 80 uur
Pacmania: 80 uur

En dat is allemaal nog vrij simpel kwa alles. Je moet dan al een behoorlijk inzicht hebben in programmeren, dan moet je C++ kennis hebben en je moet wat resources kunnen maken met een bitmap-editor en een 3d-editor. Daar gaat echt heel veel tijd in zitten.

Als je nog in een aftastende fase zit, kun je misschien iets met de game engine die IN Blender zit.

[roy-t]

Gamebuster schreef op donderdag 19 augustus 2010 @ 23:20:
[...]

Er zijn zoveel simpele spelletjes in Steam, zo moeilijk zal het dus niet zijn.

En inderdaad, nu is het nog de 1e MMO-RTS. Ik had eerder tussen haakjes "nu nog wel" erachter gezet, maar om vergeten reden had ik dat weggehaald

Ik las namelijk dat er een C&C MMO-RTS komt ergens in 2011.

Dit onderschat je, ik heb ervaring van de eerste hand met publishen op Steam en als je geen grote publisher achter je hebt staan is het ontzettend moeilijk om daar op te komen. Vele XBLIG hebben het geprobeerd en ik geloof dat er nu slechts 2 op steam zijn gekomen.

Je denkt veel te licht over gamedevelopment en je staat er redelijk arrogant tegenover, je kunt het niet zomaar zonder ervaring evenaren of beter doen. Maar toch heb ik weer tips voor je!

Verder over je kennis niveau, die termen heb ik zo lukraak even uit de mouw geschut, maar het zijn wel termen uit elke hoek die problemen op gaat leveren. Van bijna niets (behalve de programmeer basis) weet je veel.

Ik zou zelf zeg maar uit die post concluderen dat je een goed programmeur bent die nog geen kaas heeft gegeten van game programming. Daarom raad ik je aan om in kleine stapjes te beginnen. Begin niet meteen die hard C++ en OpenGL, dan heb je niets om op terug te vallen en stop je waarschijnlijk na een maand of twee omdat je niet echt vooruit komt.

Begin met game maker (not kidding, dit is nog steeds een van de beste prototype tools). Kies daarna iets als Ogre of een high level taal in combinatie met met een high level framework (Java of C# hebben meerdere managed wrappers rond OpenGL/DirectX die ook veel andere game gerelateerde taken op zich nemen en handige utilities classes hebben die veel wiskunde van je overnemen).

Na dit ben je ongeveer een half jaar verder en heb je veel geleerd zonder dat je meteen in het diepe bent gegooid (je motivatie is nog steeds hoog, want je gaat immers vooruit en vooruit en zit niet vast). Probeer dan eens Tetris of Pacman uit te werken compleet met ALLES er op en eraan. Zorg er telkens voor dat alles heel makkelijk uit te breiden is en dat je code super netjes is.

Nadat je game klaar is ga je denken aan een twist. Breid de game uit en kijk of dat makkelijk te doen is (door zo min mogelijk de 'originele' code aan te passen). Zo leer je heel erg veel over components gewijs denken en over een goede engine op zetten.

Ga nu over naar je doel taal (C++ en OpenGL) probeer je 'tetris of pacman' met twist om te zetten naar deze talen (niet triviaal). Goed nu kun je redelijk uit de voeten komen.

Nu is het tijd om een plan voor je uiteindelijke game te bedenken stel een goed plan op en identificeer problemen (zoals bijvoorbeeld lag) maak van elk component van je grote game een prototype om te bewijzen dat je dat probleem hebt overwonnen. Knoop daarna niet alle prototypes aan elkaar maar gebruik de prototypes als een referentie om je game te bouwen.

Et voila nu zijn we 3 jaar verder .


Please please please doe zoiets, dan is er kan van slagen, misschien als je er fulltime mee bezig bent gaat het wat sneller. Btw een goede game kun je niet in je eentje maken .

[Gamebuster]

whoami schreef op vrijdag 20 augustus 2010 @ 11:01:
[...]

Ahum.
Als ik jou was, zou ik deze betekenis die je er aan geeft toch nog eens herbekijken.
Of beter nog: de definitie van polymorphisme opnieuw opzoeken ...
(Zeker mogelijk in Java (my god, als ik me goed herinner zijn alle methods in Java by default 'virtual').
En in C++ is het ook mogelijk.
Polymorphisme is gewoon één van de cornerstones van OO.

Ja, alle methods in Java zijn virtual, tenzij je een "final" keyword toevoegd.

Ik heb het 'ff opgezocht: polymorphisme is dus meerdere sub-classes kunnen maken van een class, of meerdere implementaties van een interface... of iets dergelijks. Whatever, het is maar een label

whoami schreef op vrijdag 20 augustus 2010 @ 11:01:
[...]
Met steun veronderstel ik dat je hier 'geldelijke' steun bedoelt ?
Denken die investereerders er ook net zo over ? Dat er niets aan de hand is, als blijkt dat het je binnen 2 jaar niet lukt ? En zijn ze dan nog altijd bereid om opnieuw hun duit in het zakje te doen ?
En wat gaan ze zeggen als blijkt dat hun centen gewoon in een bodemloze put verzeild zijn geraakt ?

Nee, maar het plan staat hier wat simpeler. Ze schuiven pas als ik kan aantonen dat ik het technisch gezien kan uitwerken. Zolang dat niet gedaan is leef ik voort op mijn huidige inkomsten, en dat red ik nog wel een paar jaar.

@ hierboven: je bericht wordt gewaardeerd. Het maken van kleine halve games rond delen van code die samen 1 game vormen was inderdaad wel het plan en is mijn standaard werkwijze, waarbij ik vaak per game de bestaande code herschrijf of tenminste herzie. Ik heb vele kleine halve games geschreven in javascript, php, java en een keer in C++ met directX, allemaal om de ontwikkeling van een soort centraal framework voor animatie, besturing, AI, "physics", multiplayer, etc.

Persoonlijk heb ik in optimisme de deadline voor een werkende basis 2 jaar, dus exclusief de uitwerking van de artwork, gameplay, etc. Als de basis werkt moet dat gedaan worden door anderen onder mijn toezicht/leiding. Ik ga dus geen complete game uitwerken in 2 jaar; alleen een technisch-complete game, waar nog een zooi aan gameplay, artwork, GUI en tweaking toegevoegd moet worden.

Feitelijk focus ik me gewoon op de ontwikkeling van een framework die ik ook voor totaal andere games kan gebruiken.

chris schreef op vrijdag 20 augustus 2010 @ 11:08:
Mocht je eerst prototypes willen bouwen, dan kan je eens naar Cocos2D voor de iPhone kijken. Dat werkt alleen op iOS devices, maar is wel een handige abstractie om snel een game aan de praat te krijgen.

Cocos2D ken ik, ja. Weet niet meer waarom ik daar niets verder mee had gedaan, maar ik hou over het algemeen niet zo van bestaande frameworks omdat ik het zelf wil maken en ik performance-geil ben; iedere byte die ik kan besparen wil ik besparen, iedere instructie die weg kan moet weg. Ik ben eigenwijs en denk het zelf beter te kunnen dan het gebruik van een framework. Het liefst optimaliseer ik mijn code op ASM-niveau. Ik heb ook al enkele ASM boekjes aangeschaft. Ik besteed soms uren lang aan het optimaliseren van mijn code, of het compleet herschrijven van mijn code om de code netjes, efficient en geheugen-zuinig te houden.

[ Voor 67% gewijzigd door Gamebuster op 21-08-2010 04:43 ]

[apNia]

TBH een beetje demotiverend topic. Dit soort super ambitieuze projecten zijn juist goed voor je leercurve (imho).

Maar je komt steeds tegen troep aan, en je zal veel revisions krijgen en mijn ervaring is dat alles met een stijle leercurve er voor zorgt dat je er later naar terugkijkt met een gevoel van "omg, had ik dit maar anders aangepakt". Daarom zou ik ook de 2 jaar sowieso schrappen en eventuele commerciele doelen wellicht ook.

Als je wilt leren, dan is zo'n gameproject leuk. Maar bedenk jezelf hoe je 3 jaar geleden met HTML/CSS/PHP omging en hoe dat wellicht sterk veranderd is. En dan wordt je curve hierin alleen nog maar veel, veel erger

Ik heb het zelf met Java en Actionscript 3 meegemaakt (voor m'n fulltime werk). En als ik mijn meuk bekijk van 3 jaar geleden is het echt lachen geblazen
Veel foutjes e.d. Dingen die je in de praktijk tegenkomt na veelvuldig dingen te doen. En dat maakt het commerciele eindpunt een beetje lastig.

Maar als je je er goed bij voelt, go for it. In het diepe storten is voor mij altijd het beste geweest. En ookal zal je waarschijnlijk niet uitkomen waar je gehoopt had uit te komen, je zal heel veel leren

[ Voor 18% gewijzigd door apNia op 21-08-2010 05:44 ]

[Gamebuster]

apNia schreef op zaterdag 21 augustus 2010 @ 04:44:
TBH een beetje demotiverend topic. Dit soort super ambitieuze projecten zijn juist goed voor je leercurve.

Maar je komt steeds tegen troep aan, en je zal veel revisions krijgen en mijn ervaring is dat alles met een stijle leercurve er voor zorgt dat je er later naar terugkijkt met een gevoel van "omg, had ik dit maar anders aangepakt". Daarom zou ik ook de 2 jaar sowieso schrappen en eventuele commerciele doelen wellicht ook.

Als je wilt leren, dan is zo'n gameproject leuk. Maar bedenk jezelf hoe je 3 jaar geleden met HTML/CSS/PHP omging en hoe dat wellicht sterk veranderd is. En dan wordt je curve hierin alleen nog maar veel, veel erger

Ik heb het zelf met Java en Actionscript 3 meegemaakt (voor m'n fulltime werk). En als ik mijn meuk bekijk van 3 jaar geleden is het echt lachen geblazen
Veel foutjes e.d. Dingen die je in de praktijk tegenkomt na veelvuldig dingen te doen. En dat maakt het commerciele eindpunt een beetje lastig.

Maar als je je er goed bij voelt, go for it. In het diepe storten is voor mij altijd het beste geweest. En ookal zal je waarschijnlijk niet uitkomen waar je gehoopt had uit te komen, je zal heel veel leren

Dat zal best; in die 3 jaar is mijn programmeer-style totaal veranderd, maar de uiteindelijk resultaten waren hetzelfde: werkend. Enige verschil is dat de hoeveelheid code enorm is toegenomen door OOP en MVC en veel nettere structuur heeft.

[apNia]

Dat is het enge van PHP ook, het vraagt niet heel veel polishing. Het eindresultaat is al goed als de parsingtime flink wat toeneemt, men wacht gerust een halve seconde meer
En daar zit 'm echt de valkuil van PHP bijvoorbeeld. Men neemt bij web gerust wat extra tijd in acht.

Dat is een ander verhaal als je over rendercycles praat bijvoorbeeld. Maar dat had je vast al door. Let er gewoon op dat er Godsgruwelijk veel te leren is. En dat ondanks dat je project ambitieus is je echt tegen zo veel bullshit aan gaat lopen dat je op voorhand eigenlijk al kan weten dat het niet zal worden wat je wilt. Tenzij je er 5 jaar aan wilt besteden. Maar 2 jaar is "onmogelijk"

[ Voor 8% gewijzigd door apNia op 21-08-2010 05:55 ]

[Gamebuster]

apNia schreef op zaterdag 21 augustus 2010 @ 05:52:
Dat is het enge van PHP ook, het vraagt niet heel veel polishing. Het eindresultaat is al goed als de parsingtime flink wat toeneemt, men wacht gerust een halve seconde meer
En daar zit 'm echt de valkuil van PHP bijvoorbeeld. Men neemt bij web gerust wat extra tijd in acht.

Dat is een ander verhaal als je over rendercycles praat bijvoorbeeld. Maar dat had je vast al door. Let er gewoon op dat er Godsgruwelijk veel te leren is. En dat ondanks dat je project ambitieus is je echt tegen zo veel bullshit aan gaat lopen dat je op voorhand eigenlijk al kan weten dat het niet zal worden wat je wilt. Tenzij je er 5 jaar aan wilt besteden. Maar 2 jaar is "onmogelijk"

Ik weet dat er veel is, maar ik heb wel 2 jaar fulltime. Je praat hier niet over een hobby dat ik ernaast doe, het is iets waar ik echt uren achtereen mee bezig kan zijn, dag na dag. Heb periodes dat ik opsta en direct begin en nog net de moeite neem om na 14 uur weer in bed te kruipen, om het de dag erna weer te doen. Dat gaat dan meestal een weekje of 2 totdat ik iets van een soort van prototype werkende heb. Daarna rust ik een weekje en start ik weer langzaam op.

Ik werk overal, heb altijd mijn laptop bij me en gebruik ieder moment. Met andere woorden: ik ben verder totaal levenloos

[ Voor 4% gewijzigd door Gamebuster op 21-08-2010 06:30 ]

[EddoH]

Gamebuster schreef op zaterdag 21 augustus 2010 @ 04:22:
[...]

Het liefst optimaliseer ik mijn code op ASM-niveau. Ik heb ook al enkele ASM boekjes aangeschaft. Ik besteed soms uren lang aan het optimaliseren van mijn code, of het compleet herschrijven van mijn code om de code netjes, efficient en geheugen-zuinig te houden.

Niet om je af te zeiken, maar dit vind ik toch wat moeilijk om te geloven
Je hebt niet heel veel ervaring met C++ maar je optimaliseert wel met ASM? Dan vraag ik me af of je ooit wel eens een stuk code hebt kunnen optimaliseren met ASM. In 90% van de gevallen is de compiler een stuk slimmer en/of is de snelheidswinst die je behaalt door direct ASM te gebruiken nihil. Slim programmeren en goede algoritmes maken veel meer uit.

Om op je originele bericht terug te komen: maak lekker veel 'tech' demo's.
Demo's om technieken uit te proberen, te verbeteren, en te leren. Ik zou eerst eens een jaartje lekker aanprutsen met verschillende technieken, en wellicht enkele simpel spelletjes ontwikkelen. Ik weet zeker dat je voordat je dat allemaal onder de knie hebt wel 1,5 jaar verder bent.
Daarna kan je het allemaal wat grootser aanpakken en je framework gaan ontwerpen en coden. Je kunt geen goed framework ontwikkelen tijdens je leerproces. Ook al ben je eigenwijs en denk je het beter te kunnen dan bestaande frameworks; ik garandeer je dat in het begin niet het inzicht hebt om een voor een goed onderhoudbaar, efficient, snel en makkelijk onderhoudbaar framework te maken.

Stapje voor stapje dus!

[Woy]

Gamebuster schreef op zaterdag 21 augustus 2010 @ 04:22:
[...]
Cocos2D ken ik, ja. Weet niet meer waarom ik daar niets verder mee had gedaan, maar ik hou over het algemeen niet zo van bestaande frameworks omdat ik het zelf wil maken en ik performance-geil ben; iedere byte die ik kan besparen wil ik besparen, iedere instructie die weg kan moet weg. Ik ben eigenwijs en denk het zelf beter te kunnen dan het gebruik van een framework. Het liefst optimaliseer ik mijn code op ASM-niveau. Ik heb ook al enkele ASM boekjes aangeschaft. Ik besteed soms uren lang aan het optimaliseren van mijn code, of het compleet herschrijven van mijn code om de code netjes, efficient en geheugen-zuinig te houden.

Om te leren is dat misschien een goede insteek, maar als je een commercieel product wil maken niet echt. Je voldoet er ook perfect mee aan het NIH Syndroom.

Het is ook een stuk complexer dan je denkt, want het is niet zo simpel als ze veel mogelijk instructies weghalen. Je zult een veel dieper begrip van de processor waar je op werkt moeten hebben om op dat nivo te kunnen optimaliseren. Zo moet je goed begrijpen hoe de processor pipeline werkt, branche-prediction, cache misses etc. Een compiler is een stuk beter in dat soort dingen dan je denkt, en het is vrij lastig om dat beter te kunnen, en al helemaal niet haalbaar om je hele game op die manier te optimaliseren. Meestal zal het helemaal niet nodig zijn, en als het al nodig/nuttig is dan alleen op bepaalde hot-spots van je code.

Zeker voor een "simpele" eerste game is dat echt niet het belangrijkste om te doen. Er valt veel meer winst te halen door betere algoritmes en data-structuren te gebruiken.

Ik denk persoonlijk dat je een grote fout maakt om meteen te richten op een commerciële game. Maak eerst eens gewoon wat hobby projectjes af, en als je daar een jaar of meer mee bezig ben kun je altijd nog gaan denken aan een commerciële game.

[RobIII]

apNia schreef op zaterdag 21 augustus 2010 @ 04:44:
TBH een beetje demotiverend topic.

Vind ik nou helemaal niet; eerder een realitycheck. Er worden goede onderbouwingen gegeven en het is niet alsof er alleen " Gaat je nooit lukken" gepost wordt. Ik vind dit topic naarmate het vordert steeds mooier en interessanter als leesvoer voor mensen die dezelfde ambities hebben.

[alienfruit]

Al heb ik zelf geen kaas gegeten van spelletjes maken. Maar ik moet toch zeggen dat Unity toch wel interessant is. Het bevat een goede game/3d engine, commerciële physics en lighting engine voor een spotprijs (volgens horen zeggen ) en je kan er prima je gewenste MMORG meemaken:
http://www.incgamers.com/...r-galactica-mmo-announced

[frickY]

Gamebuster schreef op donderdag 19 augustus 2010 @ 23:03:
Marketing: Het is de 1e MMO-RTS en de 1e MMO-RTS voor de iPad

Ja, dat zou het nu zijn. Maar als je denkt pas over 4 jaar te kunnen opleveren, betwijfel ik of dat nog steeds het geval is.
Sterker nog, ik vermoed dat de iPad dan al lang weer vergeten is en we een hologram-tablet hebben. Zit je dan met je 2D vectors.

[Gamebuster]

EddoH schreef op zaterdag 21 augustus 2010 @ 11:18:
[...]


Niet om je af te zeiken, maar dit vind ik toch wat moeilijk om te geloven
Je hebt niet heel veel ervaring met C++ maar je optimaliseert wel met ASM? Dan vraag ik me af of je ooit wel eens een stuk code hebt kunnen optimaliseren met ASM. In 90% van de gevallen is de compiler een stuk slimmer en/of is de snelheidswinst die je behaalt door direct ASM te gebruiken nihil. Slim programmeren en goede algoritmes maken veel meer uit.

Om op je originele bericht terug te komen: maak lekker veel 'tech' demo's.
Demo's om technieken uit te proberen, te verbeteren, en te leren. Ik zou eerst eens een jaartje lekker aanprutsen met verschillende technieken, en wellicht enkele simpel spelletjes ontwikkelen. Ik weet zeker dat je voordat je dat allemaal onder de knie hebt wel 1,5 jaar verder bent.
Daarna kan je het allemaal wat grootser aanpakken en je framework gaan ontwerpen en coden. Je kunt geen goed framework ontwikkelen tijdens je leerproces. Ook al ben je eigenwijs en denk je het beter te kunnen dan bestaande frameworks; ik garandeer je dat in het begin niet het inzicht hebt om een voor een goed onderhoudbaar, efficient, snel en makkelijk onderhoudbaar framework te maken.

Stapje voor stapje dus!

Ik zei niet dat ik optimaliseer in ASM. Ik zei dat ik boekjes had aangeschaft. Optimaliseren in ASM zie je mij voorlopig niet doen; op dit moment had ik er 1tje gewoon 'ff snel doorgelezen om een beetje inzicht te krijgen hoe CPU's hun werk doen. Later wil ik ook uitvissen hoe C/C++ regeltjes vertaald worden naar ASM om een beetje bewust te zijn wat de load achter iedere regel is.

Ik heb eerder ook altijd gekeken hoe java en php hun werk deden.

Optimaliseren in ASM zou ik in de toekomst (lees: na jaren) wel willen proberen, maar voorlopig nog niet

frickY schreef op zaterdag 21 augustus 2010 @ 12:44:
[...]

Ja, dat zou het nu zijn. Maar als je denkt pas over 4 jaar te kunnen opleveren, betwijfel ik of dat nog steeds het geval is.
Sterker nog, ik vermoed dat de iPad dan al lang weer vergeten is en we een hologram-tablet hebben. Zit je dan met je 2D vectors.

Gelukkig is de game dan ook nog voor Win en Mac.
Bovendien is je opmerking wel iets overdreven; je ziet steeds meer tablets op de markt verschijnen en die zijn na 4 jaar heus niet zomaar vergeten, om nog maar te zwijgen over het hologram-tablet

Tot slot, deze game moet het niet hebben van hoogstaande graphics maar van het MMO princiepe. Bovendien heb ik nog een stapel andere MMO ideeen, waaronder een shooter, maar geen van allen is zowel technisch gezien als financieel gezien niet haalbaar voor mij.

Ik wil mij echt gaan focussen op MMO games. Ik vind dat er te weinig goede MMO games zijn buiten het MMO-RPG genre, waarbij je vaak nog maandelijks moet betalen ook. Mijn "levensdoel" is het maken van een goed MMO framework waarbij de meeste data en load via P2P gedeeld wordt met 1 of enkele centrale trackers, net zoals dat gedaan wordt bij torrent downloaden. Het zoeken van de meest efficiente verbinding tussen 2 peers wordt dynamisch geregeld door de clients zelf, inclusief het uberhaupt maken van een verbinding wanneer de 2 spelers bij elkaar in de buurt komen.

Heb een aardig plannetje uitgeschreven voor het uitwerken van een MMO netwerk dat helemaal via P2P werkt waarbij in theorie slechts 1 centrale server voor nodig is, die eenmalig de client kan doorverwijzen naar een andere client die beheer heeft over enkele andere clients.

Technisch gezien zit het helemaal in mijn hoofd, maar in praktijk zal ik zien hoe goed het daadwerkelijk zal worden, los van de vraag hoe ik mijn netwerk kan testen terwijl ik "slechts" in bezit ben van zo'n 8 computers. (nettops, servers en laptops meegerekend) Massaal virtual-PC draaien is een leuke simulatie, maar een echte testomgeving...

Daarom wil ik eerst een simpele kleine 2d platform top-down shooter maken met het MMO framework, om zo deze te kunnen testen en door te ontwikkelen. Indien deze stabiel blijkt te zijn ga ik het opvoeren naar mijn MMO-RTS, die eigenlijk logisch gezien niet veel meer tijd kost dan de 2d shooter. Deze fase heb ik 2 jarige planning gegeven. Hierna moet de MMO-RTS uitgewerkt grafisch gezien uitgewerkt worden door extern "personeel" en moet de gameplay geoptimaliseerd worden terwijl er massa's testers komen die het spel fijn mogen testen. Ken genoeg vrijwilligers die het graag zouden willen testen. Hoe lang dit kan/zal duren heb ik niet echt in de planning staan; zie ik dan wel. Verwacht niet dat het langer dan een jaar zal duren.

Woy schreef op zaterdag 21 augustus 2010 @ 12:18:
[...]

Om te leren is dat misschien een goede insteek, maar als je een commercieel product wil maken niet echt. Je voldoet er ook perfect mee aan het NIH Syndroom.

Moest lachen

Woy schreef op zaterdag 21 augustus 2010 @ 12:18:
[...]
Het is ook een stuk complexer dan je denkt, want het is niet zo simpel als ze veel mogelijk instructies weghalen. Je zult een veel dieper begrip van de processor waar je op werkt moeten hebben om op dat nivo te kunnen optimaliseren. Zo moet je goed begrijpen hoe de processor pipeline werkt, branche-prediction, cache misses etc. Een compiler is een stuk beter in dat soort dingen dan je denkt, en het is vrij lastig om dat beter te kunnen, en al helemaal niet haalbaar om je hele game op die manier te optimaliseren. Meestal zal het helemaal niet nodig zijn, en als het al nodig/nuttig is dan alleen op bepaalde hot-spots van je code.

Zeker voor een "simpele" eerste game is dat echt niet het belangrijkste om te doen. Er valt veel meer winst te halen door betere algoritmes en data-structuren te gebruiken.

Ik denk persoonlijk dat je een grote fout maakt om meteen te richten op een commerciële game. Maak eerst eens gewoon wat hobby projectjes af, en als je daar een jaar of meer mee bezig ben kun je altijd nog gaan denken aan een commerciële game.

Ik richt me niet echt op een volledig commerciele game. Het begint een commercieel smaakje te krijgen; meer een hobby-project die ik toch al zou doen maar toevallig nu ook geld zou kunnen verdienen als alles goed gaat. Bovendien heb ik al 3 jaar lang hobby projecten gemaakt (ook "halve" games), alleen voornamelijk in javascript, php en java.

[ Voor 58% gewijzigd door Gamebuster op 21-08-2010 13:22 ]

[Verwijderd]

Ik zou zelf eerst een plan schrijven en deze laten lezen door mensen met ervaring. Hun kunnen dan aangeven of dingen reeël zijn en of je punten bent vergeten. Hieruit komt dan uiteindelijk een duidelijke planning die je kunt gebruiken om jezelf te testen.

Je kunt dan een aantal belangrijke onderdelen uitontwikkelen en kijken hoelang je hier mee bezig bent in vergelijking met je planning. Als je dan bv. 4 maanden bezig bent met een onderdeel waar je 1 maand voor had geraamd dan kun je terug naar de tekentafel of het project schrappen.

Mijn punt is, probeer het als je de luxe hebt maar hou jezelf niet voor de gek. Maak een planning met doelen en deadlines. Als je deze niet kunt waarmaken denk dan nog eens goed na of je wel moet doorgaan.

[ Voor 16% gewijzigd door Verwijderd op 21-08-2010 13:26 ]

[Gamebuster]

Verwijderd schreef op zaterdag 21 augustus 2010 @ 13:21:
Ik zou zelf eerst een plan schrijven en deze laten lezen door mensen met ervaring. Hun kunnen dan aangeven of dingen reeël zijn en of je punten bent vergeten. Hieruit komt dan uiteindelijk een duidelijke planning die je kunt gebruiken om jezelf te testen.

Je kunt dan een aantal belangrijke onderdelen uitontwikkelen en kijken hoelang je hier mee bezig bent in vergelijking met je planning. Als je dan bv. 4 maanden bezig bent met een onderdeel waar je 1 maand voor had geraamd dan kun je terug naar de tekentafel of het project schrappen.

Als dit topic zo doorgaat zijn alle punten al herzien op realiteit
De kleine puntjes heb ik al zorgvuldig op internet nagegaan of zelf getest in java. Ik heb ze alleen nooit allemaal tegelijk uitgewerkt; dat ga ik nu doen in C++.

Als ik inderdaad aanzienlijk langer bezig ben dan geplant met een bepaald onderdeel zal de planning gewoon verschoven worden. Er wordt bijna geen geld in het project gestoken voordat er echt wat staat.

offtopic:
Zie ook hoeveel reacties en tips betreffende OpenGL er zijn (h)

Heb overigens al een aardige OpenGL tut gevonden:
> http://www.videotutorialsrock.com/

Ik ga deze eens doornemen en daarna misschien/waarschijnlijk een boek aanschaffen.

[ Voor 20% gewijzigd door Gamebuster op 21-08-2010 13:28 ]

[.oisyn]

Altijd leuk, die MMO topics. Hoeveel ik er al niet heb gezien tijdens het afstruinen van menig gamedevelopment forum. Elke keer weer denken de topicstarters dat het hen wél gaat lukken, itt al die andere. Maar de realiteit is dat ik er nog nooit iets moois uit heb zien voortkomen. Maar dit terzijde, de realitychecks heb je inmiddels al gehad.

Het grappige is wel dat men op een of andere manier denkt dat ze er met kennis van C++ en OpenGL/DirectX er wel zijn. Gamedevelopment is op zich geen makkelijk onderwerp, en aan een commerciele game werken tal van specialisten die goed zijn in hun eigen vakgebied maar niet zonder meer elkaars werk kunnen doen. Je wilt een MMO-RTS maken, dus qua visibility determination zul je het niet zo heel erg lastig krijgen, dat scheelt. Maar path finding, heb je daar al eens over nagedacht? Al die units zullen immers vrij soepel over het speelveld naar het doel moeten kunnen bewegen, zonder dat ze elkaar in de weg zitten. Collision detection is wellicht ook nog van belang, afhankelijk van hoe realistisch je de boel maakt. Hoe gaat je serverachtitectuur in elkaar zitten? Ik weet niet wat jij verstaat onder "MMO", maar even 32+ spelers afhandelen doe je ook niet zomaar. Al die spelers moeten immers ook updates van elkaars units krijgen, en het aantal units kan op zich al snel de pan uitrijzen. Wat is je ervaring überhaupt met betrekking tot netwerkcommunicatie en latencyproblemen?

Gamebuster schreef op zaterdag 21 augustus 2010 @ 06:28:
Ik weet dat er veel is, maar ik heb wel 2 jaar fulltime.

Wat je echter niet hebt is ervaring. In een dergelijke game zit iets van 100 tot 200 manjaar, waarbij al het personeel stuk voor stuk ervaren engineers zijn mbt gamedevelopment. Sorry hoor, maar die 2 jaar die jij hebt stelt echt compleet geen ruk voor .

[RedHat]

Ik kan me nog een spel herinneren die 2 studenten gemaakt hebben (en hier een topic hadden op GoT) die later door een uitgever is opgepikt en voor de Wii als 'voltallig' spel is gereleased.

Niets is onmogelijk alleen het failpercentage is ongeveer 100%.

TS heeft het ook over 'basisfunctionaliteit' en dat is in 2 jaar best realiseerbaar (Echter van een 'echt' spel kun je dan nog niet spreken).

Buiten dat is hetgeen wat je hiervan leert van grote waarde. Ik wens de TS dan ook succes.

[Gamebuster]

.oisyn schreef op zaterdag 21 augustus 2010 @ 13:27:
Altijd leuk, die MMO topics. Hoeveel ik er al niet heb gezien tijdens het afstruinen van menig gamedevelopment forum. Elke keer weer denken de topicstarters dat het hen wél gaat lukken, itt al die andere. Maar de realiteit is dat ik er nog nooit iets moois uit heb zien voortkomen. Maar dit terzijde, de realitychecks heb je inmiddels al gehad.

Het grappige is wel dat men op een of andere manier denkt dat ze er met kennis van C++ en OpenGL/DirectX er wel zijn. Gamedevelopment is op zich geen makkelijk onderwerp, en aan een commerciele game werken tal van specialisten die goed zijn in hun eigen vakgebied maar niet zonder meer elkaars werk kunnen doen. Je wilt een MMO-RTS maken, dus qua visibility determination zul je het niet zo heel erg lastig krijgen, dat scheelt. Maar path finding, heb je daar al eens over nagedacht? Al die units zullen immers vrij soepel over het speelveld naar het doel moeten kunnen bewegen, zonder dat ze elkaar in de weg zitten. Collision detection is wellicht ook nog van belang, afhankelijk van hoe realistisch je de boel maakt.

Over nagedacht, ja. Afstand tussen de units berekenen en op basis daarvan de units bijsturen. Ik ben me ervan bewust dat dit best complexe code zal worden, maar ik vind het ook hele leuke code om uit te werken. Verwacht wel dat ik hier eventjes bezig mee zal zijn.

.oisyn schreef op zaterdag 21 augustus 2010 @ 13:27:
Hoe gaat je serverachtitectuur in elkaar zitten? Ik weet niet wat jij verstaat onder "MMO", maar even 32+ spelers afhandelen doe je ook niet zomaar. Al die spelers moeten immers ook updates van elkaars units krijgen, en het aantal units kan op zich al snel de pan uitrijzen. Wat is je ervaring überhaupt met betrekking tot netwerkcommunicatie en latencyproblemen?

P2P waarbij iedere client gedeelde serverload krijgt. Spelers worden tevens alleen met elkaar verbonden als ze bij elkaar in de buurt komen. Bij mijn RTS zal het dus ook beperkt worden in hoeverre je je units kunt verspreiden, aangezien er bij teveel verspreiding teveel connecties geopend moeten worden en dit te zwaar wordt voor de clients. Dit houdt dus ook in dat als er een zooi spelers op een hoopje gaan zitten, dat de clients beginnen te zweten. Dit moet ik dus in de gameplay zien te voorkomen door spelers onbewust aan te moedigen te verspreiden door ze bijvoorbeeld kleine rand-missies te geven om ze naar een andere omgeving te laten zwemmen.

Ervaring betrekkende netwerken: Veel ajax-based turn-based multiplayer games en chats, eigen HTTP server geschreven in Java, eigen P2P chat geschreven in java om UDP hole punching te leren. Latency problemen en de-synchronisatie problemen door onverwachte verbroken verbindingen heb ik wel aardig ervaring mee opgeslopen binnen mijn AJAX-chats en mijn kleine java-chat. Latency problemen in real-time games heb ik echter dus nog geen ervaringen mee, maar ik weet dat het er is.

RedHat schreef op zaterdag 21 augustus 2010 @ 13:32:
Ik kan me nog een spel herinneren die 2 studenten gemaakt hebben (en hier een topic hadden op GoT) die later door een uitgever is opgepikt en voor de Wii als 'voltallig' spel is gereleased.

Niets is onmogelijk alleen het failpercentage is ongeveer 100%.

TS heeft het ook over 'basisfunctionaliteit' en dat is in 2 jaar best realiseerbaar (Echter van een 'echt' spel kun je dan nog niet spreken).

Buiten dat is hetgeen wat je hiervan leert van grote waarde. Ik wens de TS dan ook succes.

lol @ fail-percentage

Maar bedankt

Misschien maar eens een blog starten voor de voortgang. (heb ook nog een lege tweakblog...)

[ Voor 10% gewijzigd door Gamebuster op 21-08-2010 13:42 ]

[Gomez12]

Gamebuster schreef op zaterdag 21 augustus 2010 @ 04:22:
Persoonlijk heb ik in optimisme de deadline voor een werkende basis 2 jaar, dus exclusief de uitwerking van de artwork, gameplay, etc. Als de basis werkt moet dat gedaan worden door anderen onder mijn toezicht/leiding. Ik ga dus geen complete game uitwerken in 2 jaar; alleen een technisch-complete game, waar nog een zooi aan gameplay, artwork, GUI en tweaking toegevoegd moet worden.

Juist voor een prototype om investeerders warm te maken wil je super gelikte artwork / GUI etc hebben. Je gaat niets verkopen met cga-graphics en de belofte dat er foto-realistische graphics inkunnen maar dat er enkel geen demo van is.

maar ik hou over het algemeen niet zo van bestaande frameworks omdat ik het zelf wil maken en ik performance-geil ben; iedere byte die ik kan besparen wil ik besparen, iedere instructie die weg kan moet weg. Ik ben eigenwijs en denk het zelf beter te kunnen dan het gebruik van een framework. Het liefst optimaliseer ik mijn code op ASM-niveau.

Laat ik het simpel zeggen : vergeet dit concept en ga een framework gebruiken.
Je bent in je eentje dus je hebt niet de kennis / mogelijkheden om alle optimalisaties van ASM etc te testen. Voordat je het weet heb je een goede game die snel draait op jouw pc maar op elke andere pc ruk omdat jij NVidia/Intel optimalisaties hebt gebruikt die helemaal niet werken op ATI/Amd.
Een framework is ( als het goed is ) geschikt om goed te werken op alle pc's, terwijl jij met zelf optimaliseren grote verschillen tussen pc's gaat genereren.

Ik besteed soms uren lang aan het optimaliseren van mijn code, of het compleet herschrijven van mijn code om de code netjes, efficient en geheugen-zuinig te houden.

Enkel optimaliseren als het echt 100% nodig is.
Die 0,3% snelheidswinst die je vandaag behaald door 1 dag te optimaliseren is over 2 jaar compleet weggevaagd door de technologische vooruitgang, laat staan over 4 jaar als de echte game uitkomt. En ondertussen ben je wel 1 dag kwijtgeraakt.

Btw een voorbeeld waarom het makkelijk kan zijn om een framework te pakken ipv zelf in ASM te gaan klooien : nieuws: AMD staakt ondersteuning 3DNow-instructieset
Als jij handcoded spul had wat hier gebruik van maakte dan kon je dat in je eentje allemaal weer ombouwen, met een framework heb je gewoon andere mensen die het zeer waarschijnlijk voor je fixen zonder dat jij iets hoeft te doen ( behalve een nieuwe versie van het framework pakken )

[.oisyn]

RedHat schreef op zaterdag 21 augustus 2010 @ 13:32:
Ik kan me nog een spel herinneren die 2 studenten gemaakt hebben (en hier een topic hadden op GoT) die later door een uitgever is opgepikt en voor de Wii als 'voltallig' spel is gereleased.

Dan moet je er ook even bijzeggen dat ze alleen het IP hebben overgenomen, niet de daadwerkelijke content of de programmacode. Dat is allemaal opnieuw from scratch gemaakt door de studio.

Gamebuster schreef op zaterdag 21 augustus 2010 @ 13:39:
[...]

Over nagedacht, ja. Afstand tussen de units berekenen en op basis daarvan de units bijsturen. Ik ben me ervan bewust dat dit best complexe code zal worden, maar ik vind het ook hele leuke code om uit te werken. Verwacht wel dat ik hier eventjes bezig mee zal zijn.

Lol, "eventjes". Er wordt universitair onderzoek naar gedaan. Mensen verkrijgen hun PhD op dergelijke onderwerpen . Wat je hier zegt is een ideetje, het is nog verre van een bruikbaar algoritme. Ideetjes zijn altijd simpel.

Ervaring betrekkende netwerken: Veel ajax-based turn-based multiplayer games en chats, eigen HTTP server geschreven in Java, eigen P2P chat geschreven in java om UDP hole punching te leren. Latency problemen en de-synchronisatie problemen door onverwachte verbroken verbindingen heb ik wel aardig ervaring mee opgeslopen binnen mijn AJAX-chats en mijn kleine java-chat. Latency problemen in real-time games heb ik echter dus nog geen ervaringen mee, maar ik weet dat het er is.

Ok, het antwoord is dus "nihil" . Die communicatie zelf is het probleem niet, het is hoe je die latency afvangt in je realtime game.

[ Voor 16% gewijzigd door .oisyn op 21-08-2010 13:54 ]

[ThomasClay]

Gamebuster schreef op zaterdag 21 augustus 2010 @ 13:39:
P2P waarbij iedere client gedeelde serverload krijgt. Spelers worden tevens alleen met elkaar verbonden als ze bij elkaar in de buurt komen. Bij mijn RTS zal het dus ook beperkt worden in hoeverre je je units kunt verspreiden, aangezien er bij teveel verspreiding teveel connecties geopend moeten worden en dit te zwaar wordt voor de clients.

Ik ben geen kenner, maar is het niet zo dat (veel) huidige MMO games een centrale server gebruiken om cheaten te voorkomen: de server bepaalt wat er gebeurt, en de clients geven dit slechts weer en sturen input naar de server (even heel kort door de bocht). Met een P2P opzet lijkt me cheaten voorkomen een stuk lastiger worden. Wellicht nog iets om goed over na te denken.

[Verwijderd]

Dat klopt wel ongeveer (ook geen echte kenner). Clients kunnen wel proberen te voorspellen wat er gaat gebeuren zodat de animaties wat soepeler lijken (igv lag/connectie problemen).

[frickY]

Een AJAX-chat in javascript lijkt me niet bepaald vergelijkbaar met waar je hier naar kijkt

Is het geen idee om gewoon bij een game developer te gaan werken? Nu gaat het met Playlogic niet zo best, maar er zijn ook nog wel andere kleinere bedrijfjes.
En zou je voor de iPhone/iPad niet met Objective-C bezig moeten zijn ipv C++ ?

Ik bewonder je ambitie, maar zie niet hoe je dit in je uppie voor elkaar wilt gaan boksen.
Ben zelf overigens ook webdeveloper, met ruim 10 jaar ervaring, ook in oa. PHP, maar zou het niet in mijn hoofd halen hier ook maar aan te beginnen.

[ Voor 39% gewijzigd door frickY op 21-08-2010 14:31 ]

[Voutloos]

De ts zegt p2p nu als een soort toverwoord, maar p2p is wellicht al flink moeilijker dan client-server. Met servers heb je een single point of failure, maar dat geeft je tevens een luxe aanname dat er altijd een capabele hoster bij zit, en tevens heb je een node met alle kennis. Met p2p krijg je meer netwerkgezeik: portforwarding, goede groep spelers bepalen is lastiger, state behouden bij disconnects van clients, wellicht toch ergens een algoritme om een leader te bepalen, een algoritme tegen byzantine clients (aka cheaters ) etc. etc.

[Gamebuster]

Voutloos schreef op zaterdag 21 augustus 2010 @ 14:30:
De ts zegt p2p nu als een soort toverwoord, maar p2p is wellicht al flink moeilijker dan client-server. Met servers heb je een single point of failure, maar dat geeft je tevens een luxe aanname dat er altijd een capabele hoster bij zit, en tevens heb je een node met alle kennis. Met p2p krijg je meer netwerkgezeik: portforwarding, goede groep spelers bepalen is lastiger, state behouden bij disconnects van clients, wellicht toch ergens een algoritme om een leader te bepalen, een algoritme tegen byzantine clients (aka cheaters ) etc. etc.

I know. Portforwarding is me iig al gelukt via UDP hole punching binnen java in mijn chatje en ben me bewust van de genoemde punten. Maar als dit goed werkt heb ik geen 100 servers nodig om alle spelers op te vangen en heb ik een prachtig systeem met prachtige mogelijkheden. De man-uren die ik verlies bij de ontwikkeling kan ik missen, de kosten voor die servers niet. Vandaar de keuze om het via P2P te doen, + de uitdaging.

[Gamebuster]

frickY schreef op zaterdag 21 augustus 2010 @ 14:29:
Een AJAX-chat in javascript lijkt me niet bepaald vergelijkbaar met waar je hier naar kijkt

Is het geen idee om gewoon bij een game developer te gaan werken? Nu gaat het met Playlogic niet zo best, maar er zijn ook nog wel andere kleinere bedrijfjes.
En zou je voor de iPhone/iPad niet met Objective-C bezig moeten zijn ipv C++ ?

Ik bewonder je ambitie, maar zie niet hoe je dit in je uppie voor elkaar wilt gaan boksen.
Ben zelf overigens ook webdeveloper, met ruim 10 jaar ervaring, ook in oa. PHP, maar zou het niet in mijn hoofd halen hier ook maar aan te beginnen.

C++ mag/kan ook voor de iDingen; Bovendien kan je Objective-C mengen met C++; de frameworks schrijf ik in C++ en kan ik gebruiken op vrijwel ieder platform. Vervolgens spreek ik dit framework aan vanuit Objective-C. Het is volledig "legaal" C++ en Objective-C te mengen.
Zie ook: http://developer.apple.co...c/uid/TP30001163-CH10-SW1

Voor de iPad versie zal ik ook gaan werken met Objective-C++, voor de Mac/windows versie schrijf ik het puur C++. Zou zelfs moeten werken in linux.

Een AJAX-chat heeft toch wel enkele basic overeenkomsten; clients die onverwacht verdwijnen, niet meer data moeten versturen dan nodig door te controleren of de client de data heeft ontvangen en het niet dubbel verzenden, allerlei algoritmes om bandbreedte te besparen door de request-interval-timeout dynamisch te wijzigen op basis van je activiteit en of je de tab uberhaupt open heb staan, ervoor zorgen dat de berichten in goede volgorde aankomen bij de andere clients; dit soort ervaringen zijn wel handig om te kunnen visualiseren wat voor problemen een game erbij zou kunnen brengen. Verder heb ik niet alleen chats geschreven; heb ook een 4-op-een-rij multiplayer client met matchmaking gemaakt, puur in PHP en javascript met fancy animaties, scoreboards, ranglijsten en replay-mogelijkheid (anderen kunnen matches bekijken van anderen die opgeslagen zijn op de server). Ook heb ik ooit een tetris-client met highscores geschreven waar ik daadwerkelijk met cheaters te maken had die valse scores indiende. Dit heb ik opgelost door complete tetris-sessies op te nemen en te controleren bij het indienen van de score, allemaal in PHP en javascript.

[ Voor 31% gewijzigd door Gamebuster op 21-08-2010 14:56 ]

[Voutloos]

Gamebuster schreef op zaterdag 21 augustus 2010 @ 14:43:
De man-uren die ik verlies bij de ontwikkeling kan ik missen, de kosten voor die servers niet.

Zo zeker zou ik niet zijn van die trade-off. Je hebt al tijd te kort met je plan, dus ik zou het zelf wel weten met hardware kopen versus tijd dat je niet hebt.

[Gamebuster]

Voutloos schreef op zaterdag 21 augustus 2010 @ 14:55:
[...]
Zo zeker zou ik niet zijn van die trade-off. Je hebt al tijd te kort met je plan, dus ik zou het zelf wel weten met hardware kopen versus tijd dat je niet hebt.

Het verschil is dat ik wel tijd heb en geen geld wil uitgeven voor 100 servers terwijl het ook via P2P kan.

[Voutloos]

Tegen de tijd dat je 100 servers nodig hebt, heb je hopelijk al inkomsten.

[Nick The Heazk]

Gamebuster schreef op zaterdag 21 augustus 2010 @ 12:51:
[...]
Ik zei niet dat ik optimaliseer in ASM. Ik zei dat ik boekjes had aangeschaft. Optimaliseren in ASM zie je mij voorlopig niet doen; op dit moment had ik er 1tje gewoon 'ff snel doorgelezen om een beetje inzicht te krijgen hoe CPU's hun werk doen. Later wil ik ook uitvissen hoe C/C++ regeltjes vertaald worden naar ASM om een beetje bewust te zijn wat de load achter iedere regel is.

Ik heb eerder ook altijd gekeken hoe java en php hun werk deden.

Optimaliseren in ASM zou ik in de toekomst (lees: na jaren) wel willen proberen, maar voorlopig nog niet

Mij lijkt het veel nuttiger om je eens te verdiepen in het ontwerp van efficiënte algoritmen en datastructuren, met een focus op grafenalgoritmen, dan op korte of lange termijn de werking van een compiler te leren. Ik vermoed namelijk dat je deze technieken nog niet (volledig) bestudeerd hebt, gezien je voorgeschiedenis met PHP en Javascript. Met de kennis uit Introduction to Algorithms van Cormen et al., kom je al een heel eind wat betreft de minimale basistechnieken voor het schrijven van efficiënte code (die in games een must zijn). In jou geval, voor zover je deze technieken niet beheerst, zou ik de volgende hoofdstukken aanraden: deel 1 tem 6 en hoofdstuk 27 en 33.

Edit: Dit boek is sowieso een aanrader. In mijn ogen een boek dat elke computerwetenschapper zou moeten lezen, begrijpen en steeds binnen handbereik hebben .

[ Voor 5% gewijzigd door Nick The Heazk op 21-08-2010 16:18 ]

[roy-t]

Gamebuster schreef op zaterdag 21 augustus 2010 @ 13:39:
[...]

Over nagedacht, ja. Afstand tussen de units berekenen en op basis daarvan de units bijsturen. Ik ben me ervan bewust dat dit best complexe code zal worden, maar ik vind het ook hele leuke code om uit te werken. Verwacht wel dat ik hier eventjes bezig mee zal zijn.


[...]

Stoute gamebuster!!!!

Nee zo werkt het niet, er zijn tientallen onderzoekers tientallen jaren bezig geweest met verschillende pathfinding algoritmen uit te werken alleen voor games omdat normal algoritmes als A* al snel niet meer voldoen.

Volgens mij maak je de volgende denkfout:

In Administratieve software, websites en andere dingen zijn taken door mensen manueel heel moeilijk te doen, maar een computer vertellen hoe hij dit moet doen is erg makkelijk.

In games een poppetje bewegen om via een (optimaal) pad ergens naar toe te gaan is door een mens super makkelijk te doen, echter een computer dit laten doen is heel erg moeilijk.

Stel je voor, er is een tank midden op het slagveld, om hem heen staan andere soldaten, jij verteld de tank dat hij naar een de kust moet rijden om een boot kapot te schieten.

Maar meerdere bewegende soldaten staan voor hem, deze moeten aan de kant, maar welke kant moeten ze op. Ze moeten dit gezamelijk coordineren want anders gaat de een naar links en de andere naar rechts waardoor nog iedereen in de weg staat uiteindelijk. Maarja nu moeten de soldaten bewegen, maar daar staan andere soldaten en een tank om heen. Zelfde probleem dus.

Ok ondertussen is de tank een vrij stukje veld op gekomen, linksaf is een kronkelig paadje dat lijd naar de kust, rechtsaf is een snelweg die van de kust af leid, maar na 300 meter een bocht maakt en dan recht naar de kust en boot leid. Echter moet je voor die weg eerst jezelf verder weg van de boot verplaatsen.

Ok de tank rijd op de snelweg. Maar shiiiiiiit die boot verplaatst zich en zit nu net buiten vuur bereik van de tank, de tank zal dus een nieuwe route moeten kiezen. Maar shiiiit de boot blijft maar bewegen en je kunt niet elk frame voor elke unit een nieuwe beste route bedenken.


Dit is maar het topje van de ijsberg wat je bij een RTS hebt qua pathfinding. Om nog maar niet eens te beginnen over de prediction die je nodig hebt om ervoor te zorgen dat vijanden op het netwerk niet in je units teleporteren omdat 100ms geleden daar nog niemand stond.


Wat je wilt doen is echt wel heel moeilijk en volgens mij krijgen wij dat met zijn allen gewoon niet bij je naar binnen en dat is echt heel erg zonde! Want je toont veel inzet, dus als je stopt met alles onderschatten en bij elk probleem wat we naar je hoofd gooien te denken "ahh dat los ik wel zus en zo op" dan kom je er niet ondanks je enthausiasme.

Ik zou nu graag je baas willen zijn en je vertellen dat je het komende jaar mario 1 gaat namaken met het complete eerste level (maar dynamisch genoeg voor meer), level editor en multiplayer modus via internet. Geloof me, je bent wel even zoet .

Ja, alle methods in Java zijn virtual, tenzij je een "final" keyword toevoegd.

Ik heb het 'ff opgezocht: is dus meerdere sub-classes kunnen maken van een class, of meerdere implementaties van een interface... of iets dergelijks. Whatever, het is maar een label

Dit doet me denken dat je eigenlijk ook qua basis programmeer vaardigheden niet helemaal bij bent. Met zo'n antwoord en zo'n houding van "of iets dergelijks" kan ik je gerust garanderen dat je er echt niet komt. (Sorry).

Polymorfisme houd in dat je sub-classes van een base class allemaal kunt behandelen als de base class, hierdoor hoeft een management class geen rekening te houden met de implementatie details van de en set sub-classes omdat voor die manager duidelijk is dat het "allemaal units zijn". De manager class hoeft de sub-class alleen maar te vragen "doe je AI dingen" zonder te weten wat er binnen gebeurt.

Met interfaces kun je het zelfde doen. Als een class een interface implementeert dan weet een manager class dat, hoe de binnenkant er ook uitziet, die class sowieso "dit kan".

Dit lijkt op iets wat je vrij snel door hebt, maar je kunt echt heel veel werk en tijd besparen door dit goed te snappen en je zult zien dat elk jaar dat je programmeert je meer van dit simpele idee gaat gebruiken.

[Gamebuster]

roy-t schreef op zaterdag 21 augustus 2010 @ 18:00:
[...]


Stoute gamebuster!!!!

Nee zo werkt het niet, er zijn tientallen onderzoekers tientallen jaren bezig geweest met verschillende pathfinding algoritmen uit te werken alleen voor games omdat normal algoritmes als A* al snel niet meer voldoen.

Volgens mij maak je de volgende denkfout:

In Administratieve software, websites en andere dingen zijn taken door mensen manueel heel moeilijk te doen, maar een computer vertellen hoe hij dit moet doen is erg makkelijk.

In games een poppetje bewegen om via een (optimaal) pad ergens naar toe te gaan is door een mens super makkelijk te doen, echter een computer dit laten doen is heel erg moeilijk.

Stel je voor, er is een tank midden op het slagveld, om hem heen staan andere soldaten, jij verteld de tank dat hij naar een de kust moet rijden om een boot kapot te schieten.

Maar meerdere bewegende soldaten staan voor hem, deze moeten aan de kant, maar welke kant moeten ze op. Ze moeten dit gezamelijk coordineren want anders gaat de een naar links en de andere naar rechts waardoor nog iedereen in de weg staat uiteindelijk. Maarja nu moeten de soldaten bewegen, maar daar staan andere soldaten en een tank om heen. Zelfde probleem dus.

Ok ondertussen is de tank een vrij stukje veld op gekomen, linksaf is een kronkelig paadje dat lijd naar de kust, rechtsaf is een snelweg die van de kust af leid, maar na 300 meter een bocht maakt en dan recht naar de kust en boot leid. Echter moet je voor die weg eerst jezelf verder weg van de boot verplaatsen.

Ok de tank rijd op de snelweg. Maar shiiiiiiit die boot verplaatst zich en zit nu net buiten vuur bereik van de tank, de tank zal dus een nieuwe route moeten kiezen. Maar shiiiit de boot blijft maar bewegen en je kunt niet elk frame voor elke unit een nieuwe beste route bedenken.


Dit is maar het topje van de ijsberg wat je bij een RTS hebt qua pathfinding. Om nog maar niet eens te beginnen over de prediction die je nodig hebt om ervoor te zorgen dat vijanden op het netwerk niet in je units teleporteren omdat 100ms geleden daar nog niemand stond.

Jouw uitleg is lang voor wat ik zo ongeveer bedoelde met "afstand tussen de units berekenen en daarnaar bijsturen". Bovendien is het een onderwaterwereld die een stuk minder complex is dan normale maps, maar inderdaad: de correcte pathfinding wordt nog een fijn stuk code, en dan nog maar te zwijgen over een goede bijpassende animatie.

roy-t schreef op zaterdag 21 augustus 2010 @ 18:00:
Wat je wilt doen is echt wel heel moeilijk en volgens mij krijgen wij dat met zijn allen gewoon niet bij je naar binnen en dat is echt heel erg zonde! Want je toont veel inzet, dus als je stopt met alles onderschatten en bij elk probleem wat we naar je hoofd gooien te denken "ahh dat los ik wel zus en zo op" dan kom je er niet ondanks je enthausiasme.

Ik zou nu graag je baas willen zijn en je vertellen dat je het komende jaar mario 1 gaat namaken met het complete eerste level (maar dynamisch genoeg voor meer), level editor en multiplayer modus via internet. Geloof me, je bent wel even zoet .

Als je denkt dat ik jullie "commentaar" compleet negeer zit je er compleet naast. Het is hele nuttige info en heeft me zeker 'ff aan het denken gezet.

Je mario-idee is ook leuk. Ik ga meteen beginnen om de mario-game in Java na te maken, incl. level-editor en multiplayer...? Maak er wel een coop van met luigi, mario etc... ofzoiets. Ik zie wel hoever ik kom, ik zal je PM'en als-ie af is. Trouwens ook interessant voor meneer de boekhouder, dan ziet die ook eens wat levend.

roy-t schreef op zaterdag 21 augustus 2010 @ 18:00:
Dit doet me denken dat je eigenlijk ook qua basis programmeer vaardigheden niet helemaal bij bent. Met zo'n antwoord en zo'n houding van "of iets dergelijks" kan ik je gerust garanderen dat je er echt niet komt. (Sorry).

Polymorfisme houd in dat je sub-classes van een base class allemaal kunt behandelen als de base class, hierdoor hoeft een management class geen rekening te houden met de implementatie details van de en set sub-classes omdat voor die manager duidelijk is dat het "allemaal units zijn". De manager class hoeft de sub-class alleen maar te vragen "doe je AI dingen" zonder te weten wat er binnen gebeurt.

Met interfaces kun je het zelfde doen. Als een class een interface implementeert dan weet een manager class dat, hoe de binnenkant er ook uitziet, die class sowieso "dit kan".

Dit lijkt op iets wat je vrij snel door hebt, maar je kunt echt heel veel werk en tijd besparen door dit goed te snappen en je zult zien dat elk jaar dat je programmeert je meer van dit simpele idee gaat gebruiken.

Hier ben ik het niet mee eens. Ik ken en gebruik de technieken die je hier opnoemt, ik kende alleen de term "polymorfisme" niet. Althans, ik ken de term wel, maar ik wist de betekenis niet. Ik wist dat het iets met subclasses te maken had, want als je boeken/tutorials leest met "polymorfisme" als titel gaat het altijd over subclasses: http://www.cplusplus.com/doc/tutorial/polymorphism/

Als je ook die tekst doorleest zie je gewoon die titel daar staan; Er staat niet uitgelegd wat het betekend. Tenminste, ik zie het 1-2-3 niet staan. Daarom ken ik de betekenis van het woord simpelweg niet. Dat betekend nog niet dat ik geen subclasses kan maken en methods kan overloaden en meerdere implementaties van een abstracte class weet "samen te laten werken".

[frickY]

Gamebuster schreef op zaterdag 21 augustus 2010 @ 14:47:
Een AJAX-chat heeft toch wel enkele basic overeenkomsten; clients die onverwacht verdwijnen, niet meer data moeten versturen dan nodig door te controleren of de client de data heeft ontvangen en het niet dubbel verzenden

Ja, de situaties zijn misschien overeenkomstig. Alleen daar regelt de browser al het gehannes met de TCP-stack voor je, en hier heb je het over een eigen protocol over UDP.

[Gamebuster]

frickY schreef op zaterdag 21 augustus 2010 @ 18:41:
[...]
Ja, de situaties zijn misschien overeenkomstig. Alleen daar regelt de browser al het gehannes met de TCP-stack voor je, en hier heb je het over een eigen protocol over UDP.

Dat snap ik.

Ik begin nu met mijn mario-achtige game, incl. coop-multiplayer via P2P over UDP (zie bovenstaande post)

Als die af is post ik de handel hier en gaan we verder met de discussie

[ Voor 6% gewijzigd door Gamebuster op 21-08-2010 18:46 ]

[frickY]

Overigens is dit misschien een leuk topic om eens door te lezen; [RTS] De ontwikkeling van een Western
Komen ook problemen zoals pathfinding aan het licht.

Na 4 jaar ontwikkelen zei die TS;

misschien dat ik toch maar eens opnieuw moet beginnen met een bestaande engine, Bijv Torque of OGRE. Dat zal heel veel tijd besparen

[ Voor 34% gewijzigd door frickY op 21-08-2010 18:51 ]

[roy-t]

Gamebuster schreef op zaterdag 21 augustus 2010 @ 18:36:
[...]

Jouw uitleg is lang voor wat ik zo ongeveer bedoelde met "afstand tussen de units berekenen en daarnaar bijsturen". Bovendien is het een onderwaterwereld die een stuk minder complex is dan normale maps, maar inderdaad: de correcte pathfinding wordt nog een fijn stuk code, en dan nog maar te zwijgen over een goede bijpassende animatie.


[...]

Als je denkt dat ik jullie "commentaar" compleet negeer zit je er compleet naast. Het is hele nuttige info en heeft me zeker 'ff aan het denken gezet.

Je mario-idee is ook leuk. Ik ga meteen beginnen om de mario-game in Java na te maken, incl. level-editor en multiplayer...? Maak er wel een coop van met luigi, mario etc... ofzoiets. Ik zie wel hoever ik kom, ik zal je PM'en als-ie af is. Trouwens ook interessant voor meneer de boekhouder, dan ziet die ook eens wat levend.

ik ben zeer benieuwd! Ik wil je ook niet de grond in praten enzo, maar je gewoon wat temperen zodat je meer kans hebt weet je.

[rapture]

Al kan de TS foutloos code kloppen in meerdere talen, dan nog heeft hij last van "wat wil ik nu eigenlijk coderen?". De functionaliteit/mechanismen achter de code ga je eerst moeten doorgronden, daarin zit meestal het verschil tussen een bachelor en een master.

Voor een bachelor is fotobewerking Photoshop opstarten en in praktijk aan foto's klooien volgens een eisenpakket om uiteindelijk een resultaat af te leveren. Voor een master is het Matlab opstarten, foto in een matrix gieten, matrixmanipulatie om te snappen wat er achter de schermen gebeurd en uiteindelijk kan je bv door een fotodatabase zoeken op basis van een paint-schetsje, kan je aantal mensen in een lokaal tellen met een webcam, kan je muntstukken op een tafel tellen met een foto,... en je kan zelfs een modelbouwvliegtuig met terreingeleiding automatisch laten vliegen in situaties dat GPS niet nauwkeurig genoeg is. Met wiskunde, algoritmen, papers (die je bij Web of Science, ACM,... kan vinden),... en onderzoek kan je veel verder gaan dan alleen maar een tool zoals bv Photoshop te leren.

De TS start vanuit een bachelor standpunt: "Als ik tool x leer, dan zal het wel lukken.". Voor de echte mogelijkheden moet je aan de andere kant zijn, veel meer in de (wiskunde, algoritmen,...) achtergrond en veel minder in de details/code. De TS zit momenteel 2 bruggen te ver. Als zijn denkwijze, kennis,... aangepast is, dan zit hij 1 brug te ver (tijd, geld en mankracht nodig).

Liever een onderzoeker die klaagt dat zijn computer stuk is terwijl in werkelijkheid alleen maar een VGA-connector los zit (hij ziet eruit als een computerleek), dan iemand die code kan kloppen, orders kan uitvoeren, maar geen idee heeft van wat er allemaal erachter zit. Die onderzoeker weet wel wat erachter zit en zo zit hij slechts 1 brug te ver (zijn onderzoek heeft funding en mankracht nodig).

Het is een goede tip om van de code/details/uitvoering af te stappen en eerst de mechanismen achter eenvoudige games in een soort gamemaker te doorgronden.

OpenGL en GUI is maar slechts een presentatielaagje boven op je commandline spul, gameserver,... dat op het achtergrond zit. Zie het zoals de ledjes, knopjes,... dat op je computerkast zit, het minst belangrijke gedeelte. Met alleen ledjes en knopjes maak je geen computer. Tuurlijk is het marketingtechnisch interessant om een gelikte uiterlijk te tonen om investeerders te lokken.

[roy-t]

Waar heb je het over?! . Ik snap je echt niet. Als je vind dat iedereen die OpenGL wil gebruiken om modellen op het scherm te tekenen moet weten hoe alles achter OpenGL werk (bijvoorbeeld). Dan is dat leuk voor je. Maar dan zouden er bijna geen programmas meer gemaakt kunnen worden.

[rapture]

Ik zie de verwarring. Achtergrond als in 3D op een plat vlak projecteren, yaw-pitch-roll (Goed voor vliegtuigen, boten,... maar je wilt niet een first person shooter met mannetjes die rond hun middel draaien.),... en achtergrond als in de backend achter de GUI of de laag met de logica in three-tier.

Net zoals je weinig aan een boekhoudprogramma hebt die niet kan uitrekenen hoeveel BTW je na een kwartaal moet afstaan, geen resultatenrekening kan genereren,... Heb je weinig aan gelikte OpenGL GUI, als de pathfinding, game mechanics,... niet in orde komt.

Voordat je een boekhoudprogramma schrijft kan je best uitzoeken hoe dubbel boekhouden werkt. Zo kan je best uitzoeken wat er achter de schermen van een game gebeurd ipv taal x of tool y proberen te doorgronden. Liever met netcat of putty (je krijgt de positie van de units textueel op het scherm en je kan met press 1 voor dit, press 2 voor dat of command's typen het spel besturen) aan een gameserver connecteren die werkende logica heeft dan een gelikte GUI waarin de units niet kunnen bewegen.

[epic007]

..ik hou over het algemeen niet zo van bestaande frameworks omdat ik het zelf wil maken en ik performance-geil ben..

Dat je het zelf wilt maken snap ik, maar denk je echt dat de mensen achter XNA, UDK en Unity3d niet performance geil zijn ? De Unreal engine is al jaren in ontwikkeling, dat haal je echt niet in in 2 jaar.

Ik heb zelf ervaring met Unity 3D, en ik kan je echt aanraden daar eens iets in te gaan maken. Door zo'n engine/framework te gebruiken leer je heel veel over hoe een game-engine inelkaar zit en hoe ze tot bepaalde keuzes zijn gekomen.
Probeer het wiel niet opnieuw uit te vinden, tijdverspilling!

[Gorion3]

Draag iets zinnigs bij of zeg niets. Deze manier van het topic proberen vergallen wordt hier niet op prijs gesteld.

[ Voor 71% gewijzigd door RobIII op 22-08-2010 13:25 ]

[roy-t]

@ rapture

Ooooh ja logisch, nu snap ik wat je bedoelt, dat hele bachelor/master etc.. gedoe had me zoeken in de verkeerde richting.

@Gorion3
Troll

[Gamebuster]

epic007 schreef op zondag 22 augustus 2010 @ 12:11:
[...]

Dat je het zelf wilt maken snap ik, maar denk je echt dat de mensen achter XNA, UDK en Unity3d niet performance geil zijn ? De Unreal engine is al jaren in ontwikkeling, dat haal je echt niet in in 2 jaar.

Ik heb zelf ervaring met Unity 3D, en ik kan je echt aanraden daar eens iets in te gaan maken. Door zo'n engine/framework te gebruiken leer je heel veel over hoe een game-engine inelkaar zit en hoe ze tot bepaalde keuzes zijn gekomen.
Probeer het wiel niet opnieuw uit te vinden, tijdverspilling!

Unity 3D ziet er best interessant uit. Kosten zijn ook wel te doen. 'Ff gedownload.

http://unity3d.com/gallery/
@4:00 Is dat nou in flash of een java applet? Het ziet er in ieder geval erg mooi uit, zoiets had ik in gedachten voor mijn graphics.

[ Voor 11% gewijzigd door Gamebuster op 22-08-2010 13:26 ]

[rapture]

Stel dat je door het wiel opnieuw uit te vinden de performance kan verdubbelen, maar je kiest bij het verkeerde sort algoritme (om maar een voorbeeld te geven) en je game draait factor 10 trager wegens verkeerde keuze. En als je de verdubbeling erbij neemt, dan is het nog altijd factor 5 trager.

Het moment dat de studenten in een studentenhuis met 128 Kbit/s smalband ervoor zorgen dat ik niet meer kan posten en browser games zoals erepublik werken niet meer. Dan werkt EVE Online dankzij hun optimalisatie voor echte massive multiplay nog altijd. Meer dan 40 duizend spelers in 1 gamewereld ipv aparte shards en 1600+ man gevechten in 1 slagveld. Dan telt elke bitje dat naar de clients verstuurd wordt, elke if then else dat in de client uitgevoerd wordt. Er zijn een aantal features voor de clients voorzien:

• Als je op 100 km afstand beschoten wordt, dan is de vijand waarschijnlijk kleiner dan een pixel. Niet renderen.
• Als elke speler 5 drones los laat, dan zouden de duizenden drones het boeltje vertragen. Je kan kiezen om geen drones te renderen.
• Als je uitzoomt om een overzicht over het slagveld te krijgen. Zo weinig mogelijk renderen.
• Als je rond elke speler een vierkantje tekent met red voor vijand, blue voor friendly, purple voor fleet member,... dan moet de client regelmatig door een case gaan om te zien of speler nummero zoveel red, blue, purple,... is. Duizenden switch/case of if-then-else per frame belast de processor zoveel dat de framerate gedeeld door 10 tot 100 gaat. Voor de gpu is 1600+ vierkantjes renderen geen probleem. Vierkantjes uitschakelen en het is ook handig dat de standings/reputatie zo weinig mogelijk opgevraagd wordt.
• Je wilt een vijandelijke speler selecteren om erop te kunnen schieten. De spelers worden in een lijst getoond en je moet zoveel mogelijk dingen uitschakelen om het bruikbaar te maken. bv Alleen battleships die red zijn, worden nu opgelijst. Dan heb je geen 'overview clutter' waarin je de relevante doelwitten niet ziet staan.
• Het groeperen van wapens op een ruimteschip. Dan heb je 1 dikke laserstraal of missilewolk ipv 6, 7 of 8 aparte laserstralen of missiles die gerenderd en berekend moeten worden. Het is ook standaardprocedure om in grote gevechten de wapeneffecten uit te schakelen.
• ...

Drastisch optimaliseren doe je niet in de code, maar in de logica en functionaliteit van je game. Het verschil is ook zo groot als huffman, run-length,... versus mp3 encoding op een wav-bestand toepassen.

[Gamebuster]

rapture schreef op zondag 22 augustus 2010 @ 13:19:
Stel dat je door het wiel opnieuw uit te vinden de performance kan verdubbelen, maar je kiest bij het verkeerde sort algoritme (om maar een voorbeeld te geven) en je game draait factor 10 trager wegens verkeerde keuze. En als je de verdubbeling erbij neemt, dan is het nog altijd factor 5 trager.

Het moment dat de studenten in een studentenhuis met 128 Kbit/s smalband ervoor zorgen dat ik niet meer kan posten en browser games zoals erepublik werken niet meer. Dan werkt EVE Online dankzij hun optimalisatie voor echte massive multiplay nog altijd. Meer dan 40 duizend spelers in 1 gamewereld ipv aparte shards en 1600+ man gevechten in 1 slagveld. Dan telt elke bitje dat naar de clients verstuurd wordt, elke if then else dat in de client uitgevoerd wordt. Er zijn een aantal features voor de clients voorzien:

• Als je op 100 km afstand beschoten wordt, dan is de vijand waarschijnlijk kleiner dan een pixel. Niet renderen.
• Als elke speler 5 drones los laat, dan zouden de duizenden drones het boeltje vertragen. Je kan kiezen om geen drones te renderen.
• Als je uitzoomt om een overzicht over het slagveld te krijgen. Zo weinig mogelijk renderen.
• Als je rond elke speler een vierkantje tekent met red voor vijand, blue voor friendly, purple voor fleet member,... dan moet de client regelmatig door een case gaan om te zien of speler nummero zoveel red, blue, purple,... is. Duizenden case of if-then-else per frame belast de processor zoveel dat de framerate gedeeld door 10 tot 100 gaat. Voor de gpu is 1600+ vierkantjes renderen geen probleem. Vierkantjes uitschakelen en het is ook handig dat de standings/reputatie zo weinig mogelijk opgevraagd wordt.
• Je wilt een vijandelijke speler selecteren om erop te kunnen schieten. De spelers worden in een lijst getoond en je moet zoveel mogelijk dingen uitschakelen om het bruikbaar te maken. bv Alleen battleships die red zijn, worden nu opgelijst.
• Het groeperen van wapens op een ruimteschip. Dan heb je 1 dikke laserstraal of missilewolk ipv 6, 7 of 8 aparte laserstralen of missiles die gerenderd en berekend moeten worden. Het is ook standaardprocedure om in grote gevechten de wapeneffecten uit te schakelen.
• ...

Drastisch optimaliseren doe je niet in de code, maar in de logica en functionaliteit van je game. Het verschil is ook zo groot als huffman, run-length,... versus mp3 encoding op een wav-bestand toepassen.

Bij mijn MMO-RTS zal je alleen verbinding maken met de clients die binnen je actie-radius zijn. Aangezien het allemaal visjes zijn die alleen maar short-range aanvallen, of zelfs alleen maar meelee, is die actie-radius niet groot. Ver uitzoomen zal dus om dezelfde rede uitgeschakeld worden, of ik maak een alternatief waarbij een speciale unit-map wordt ontvangen waarop alleen de spelers of grote units zichtbaar zijn en waar geen informatie over hun snelheid of animaties wordt meeverzonden, en teken ze als, zoals je al zei, vierkantjes/rondjes/stipjes/icoontjes op een soort 2D plattegrond.

Zoals ik al zei, ik ga 'ff unity 3D proberen. Die engine ziet er wel nice uit.

[apNia]

Gamebuster schreef op zondag 22 augustus 2010 @ 13:15:
[...]

Unity 3D ziet er best interessant uit. Kosten zijn ook wel te doen. 'Ff gedownload.

http://unity3d.com/gallery/
@4:00 Is dat nou in flash of een java applet? Het ziet er in ieder geval erg mooi uit, zoiets had ik in gedachten voor mijn graphics.

Pff heb je al uitgezocht wat Unity is?

[Gorion3]

Anyway, mod's vonden mijn post niet mooi genoeg, terwijl het wel daadwerkelijk serieus was bedoeld.

Dus nog een keer, als ik de TS was zou ik dus gewoon het gaan proberen, ookal moet je zeker in je gedachte houden dat je keihard gaat falen, maar je gaat dus wel veel leren. Weet niet hoe oud TS is maar, met zo'n game maken krijg je veel verschillende kanten te zien.

Wel zou ik in XNA beginnen en dan pas naar opengl moven.

Daarnaast is het raggen in xcode of visual studio wel daadwerkelijke het goede leven

[Gamebuster]

Gorion3 schreef op zondag 22 augustus 2010 @ 13:50:
Anyway, mod's vonden mijn post niet mooi genoeg, terwijl het wel daadwerkelijk serieus was bedoeld.

Dus nog een keer, als ik de TS was zou ik dus gewoon het gaan proberen, ookal moet je zeker in je gedachte houden dat je keihard gaat falen, maar je gaat dus wel veel leren. Weet niet hoe oud TS is maar, met zo'n game maken krijg je veel verschillende kanten te zien.

Wel zou ik in XNA beginnen en dan pas naar opengl moven.

Daarnaast is het raggen in xcode of visual studio wel daadwerkelijke het goede leven

Je post was ook niet echt duidelijk of het nou een troll of serieus was, maar moest wel lachen
Ben trouwens bijna 20 (3 weekjes nog)
Toen ik net 17 was begon ik aan webdevelopment op mijn ICT opleiding; toen ik 18 werd zei ik mijn opleiding gedag en ging ik verder met freelance webdevelopment terwijl ik mij in mijn vrije tijd bezig hield met het maken van kleine games in javascript en PHP.

@unity 3D: ik had lol met die struisvogel in die demo. Jammer dat je 'm niet kan neerschieten...

[Hydra]

Gamebuster schreef op zondag 22 augustus 2010 @ 13:34:
Bij mijn MMO-RTS zal je alleen verbinding maken met de clients die binnen je actie-radius zijn.

Hoe ga je je game beveiligen tegen cheats?

[Freak]

Gamebuster schreef op zondag 22 augustus 2010 @ 14:04:
[...]

Je post was ook niet echt duidelijk of het nou een troll of serieus was, maar moest wel lachen
Ben trouwens bijna 20 (3 weekjes nog)
Toen ik net 17 was begon ik aan webdevelopment op mijn ICT opleiding; toen ik 18 werd zei ik mijn opleiding gedag en ging ik verder met freelance webdevelopment terwijl ik mij in mijn vrije tijd bezig hield met het maken van kleine games in javascript en PHP.

@unity 3D: ik had lol met die struisvogel in die demo. Jammer dat je 'm niet kan neerschieten...

Mag ik vragen waarom je niet een opleiding gaat volgen en dit idee uitwerkt in je vrije tijd.
Zo heb je nog iets om op terug te vallen indien dit mislukt.
Ook in verband met eventuele toekomstplannen is het misschien handig.
Ik weet niet of je al hebt nagedacht wat je de rest van je leven wil gaan doen, maar bijvoorbeeld alleen websites bouwen + wat kleine games lijkt me ook saai worden op den duur?
Een papiertje is uiteraard niet nodig om werk te vinden, maar het kan wel helpen.

[Gorion3]

Hmm ook geen opleiding, dan zou ik daar zeker wel eerst voor kiezen, kijk als je al iets van mbo/hbo/uni hebt dan kan je doen wat je wilt. maar zonder opleiding is dat veel "gevaarlijker"

[roy-t]

Gamebuster schreef op zondag 22 augustus 2010 @ 13:15:
[...]

Unity 3D ziet er best interessant uit. Kosten zijn ook wel te doen. 'Ff gedownload.

http://unity3d.com/gallery/
@4:00 Is dat nou in flash of een java applet? Het ziet er in ieder geval erg mooi uit, zoiets had ik in gedachten voor mijn graphics.

Je gaat wel een stuk meer (en grondiger) uitzoek werk moeten doen! Dit merk ik nu al meerdere keren, je gaat telkens voor "ongeveer wel weten" en ziet daardoor niet wat iets nu echt is.

Neem Unity3D, het is geen Flash of Java applet, het is een multiplatform development toolset/framework dat gecompileerd kan worden voor standalone (Windows en Mac), webplatform via de Unity Web Player Plug-in en ook nog voor mac-widgets, zonder dat je je code of project hoeft aan te passen.

Dus je gaat weer veel te kort door de bocht

[Gamebuster]

roy-t schreef op zondag 22 augustus 2010 @ 23:25:
[...]


Je gaat wel een stuk meer (en grondiger) uitzoek werk moeten doen! Dit merk ik nu al meerdere keren, je gaat telkens voor "ongeveer wel weten" en ziet daardoor niet wat iets nu echt is.

Neem Unity3D, het is geen Flash of Java applet, het is een multiplatform development toolset/framework dat gecompileerd kan worden voor standalone (Windows en Mac), webplatform via de Unity Web Player Plug-in en ook nog voor mac-widgets, zonder dat je je code of project hoeft aan te passen.

Dus je gaat weer veel te kort door de bocht

Natuurlijk ga ik veel meer onderzoek werk moeten doen; ik zei alleen dat ik het 'ff gedownload had om te kijken. en was er inderdaad al achter dat het via een plugin ging.

[alex3305]

Gamebuster schreef op zondag 22 augustus 2010 @ 14:04:
[...]

Je post was ook niet echt duidelijk of het nou een troll of serieus was, maar moest wel lachen
Ben trouwens bijna 20 (3 weekjes nog)
Toen ik net 17 was begon ik aan webdevelopment op mijn ICT opleiding; toen ik 18 werd zei ik mijn opleiding gedag en ging ik verder met freelance webdevelopment terwijl ik mij in mijn vrije tijd bezig hield met het maken van kleine games in javascript en PHP.

@unity 3D: ik had lol met die struisvogel in die demo. Jammer dat je 'm niet kan neerschieten...

Toen ik 17 was, begon ik aan mijn HBO Informatica opleiding. Deze was in het begin veel te makkelijk. Echter nu ik, op mijn 21e (wel een jaartje of twee niets gedaan, maar dat is een ander verhaal) net mijn minor (specialisatie) heb afgerond in game development piep ik wel anders, dan 'even een game schrijven'.

Persoonlijk zou ik je erg graag helpen met het zoeken naar bronnen over OpenGL, algoritmiek, lineaire algebra, etc. maar ik denk dat je er veel meer aan hebt om dit idee van je af te zetten en te beginnen aan een full-time informatica of game-development opleiding waarnaast je jouw webdevelopment doet. Als ik namelijk alleen al ga kijken naar 'ons' project in de afgelopen drie maanden, wat we bij lange na niet af hebben gekregen, dan denk ik zelfs dat jouw twee jaar te weinig tijd is voor jouw idee. Laat mij even in detail treden.

Allereerst werkten wij met zeven personen aan één projecten. Aan dit project hebben wij twintig weken gewerkt. De eerste acht (!) weken hebben we alleen al gewerkt aan het bedenken van spellen en een zogenaamd design-document opleveren. Daarna hebben wij twee weken hard moeten doorploeteren om een niet-functionerende demo te maken waarin alleen nog maar simpele bewegingen zaten (geen animatie!!) met wat graphics.

Daarna hebben wij in de tweede periode zeker negen weken lang flink moeten doorwerken (40 - 60 uur per week, per persoon) om zoveel mogelijk af te kunnen krijgen. Hierin hadden we al een framework (XNA) en een physics engine (Farseer), waarnaast wij allemaal ook al C# kende. Uiteindelijk hebben wij vijf levels af kunnen krijgen (waar er 25 gepland stonden) en van alle elementen hebben wij er vier (8 / 9 gepland) af kunnen krijgen. Dit allemaal door de tijd en moeilijkheidsgraad van het maken van een spel.

Het uiteindelijke resultaat kun je overigens downloaden op: http://byggs.h2design.nl - waarbij je dus kunt zien dat het nog niet heel veel is.

Mijn conclusie; zet die JavaScript spelletjes van je af, want die stellen geen drol voor. Drop je idee om uberhaupt zelf een game-engine te gaan schrijven, en al helemaal in C++, want dat ga je niet voor elkaar krijgen in verband met de tijd en moeilijkheidsgraad. Als laatste, maak van je MMO-RTS een leuk hobby-projectje (of stel het uit) en begin aan een game-development of informatica opleiding, daar zul je veeeeeel meer aan hebben!

Daarbij wil ik je niet ontmoedigen, maar even een reality-check geven, want ik denk dat je totaaaal niet beseft wat dit allemaal inhoud. Kijk overigens ook een keer naar Physics for Game Developers (bijv. pag 100) en AI for Game Developers, dan zie je hopelijk wel wat ik bedoel.

[Guillome]

Gamebuster schreef op donderdag 19 augustus 2010 @ 22:56:
[...]

Ik ben niet zo goed met termen, simpelweg omdat ik geen opleiding heb gehad en je die termen dus minder vaak tegenkomt binnen tutorials en online documentatie. Maar toch, even het lijstje afgaan:

-Scenegraph
Nooit van gehoort.
...
...

Omg... je bent inderdaad niet echt goed geschoolt nee

Ik ben wel benieuwd naar je mario spel, en hoe lang je er over doet. Er zijn maar weinig mensen die die mooie fijne feeling van Mario hebben kunnen namaken. En vergeet de muziek niet! Tu-dup-dup tu-dup-dup

[ Voor 18% gewijzigd door Guillome op 23-08-2010 09:54 ]

[roy-t]

Daar bij kan ik je vertellen dat de meeste gamedevelopment/design er meestal niet op gericht zijn om game programmers te kweken, omdat er zoveel aan bod komt (art, leveldesign, narrative design, concept design, mechanics, audio, etc..) dat programmeren een beetje ondergesneeuwd blijft soms.

Een solide informatica opleiding met daarna een specialisatie zoals alex3305 heeft gedaan zou mijn voorkeur hebben.

@Alex3305: grappig spelletje, heb het even gespeeld, het valt altijd vies veel tegen hoeveel tijd dat soort dingen kosten, hadden jullie denk je ook veel overhead door communicatie?

[Killemov]

RedHat schreef op zaterdag 21 augustus 2010 @ 13:32:
Ik kan me nog een spel herinneren die 2 studenten gemaakt hebben (en hier een topic hadden op GoT) die later door een uitgever is opgepikt en voor de Wii als 'voltallig' spel is gereleased.

Deze dus: http://www.deblob.com/

Oogst, jouw 2 cents?

[apNia]

Dat zijn inderdaad de jongens van Ronimo Games. Volgens mij wel een iets groter team. Oogst zat er inderdaad in.

Slightly offtopic, maar ik vond dit een leuk interview met Oogst en zijn indie development: http://bashers.nl/indie-i...ost-van-dongen-over-proun

[Nick The Heazk]

Gamebuster schreef op zondag 22 augustus 2010 @ 14:04:
Toen ik net 17 was begon ik aan webdevelopment op mijn ICT opleiding; toen ik 18 werd zei ik mijn opleiding gedag en ging ik verder met freelance webdevelopment terwijl ik mij in mijn vrije tijd bezig hield met het maken van kleine games in javascript en PHP.

Freak schreef op zondag 22 augustus 2010 @ 14:33:
Mag ik vragen waarom je niet een opleiding gaat volgen en dit idee uitwerkt in je vrije tijd.
Zo heb je nog iets om op terug te vallen indien dit mislukt.
Ook in verband met eventuele toekomstplannen is het misschien handig.
Ik weet niet of je al hebt nagedacht wat je de rest van je leven wil gaan doen, maar bijvoorbeeld alleen websites bouwen + wat kleine games lijkt me ook saai worden op den duur?
Een papiertje is uiteraard niet nodig om werk te vinden, maar het kan wel helpen.

Gorion3 schreef op zondag 22 augustus 2010 @ 14:56:
Hmm ook geen opleiding, dan zou ik daar zeker wel eerst voor kiezen, kijk als je al iets van mbo/hbo/uni hebt dan kan je doen wat je wilt. maar zonder opleiding is dat veel "gevaarlijker"

roy-t schreef op maandag 23 augustus 2010 @ 09:40:
Een solide informatica opleiding met daarna een specialisatie zoals alex3305 heeft gedaan zou mijn voorkeur hebben.

Hoewel het hierboven al een aantal keer benadrukt werd, zou ik het toch ook nog eens willen benadrukken. Als je niet de rest van je leven nog websites wilt bouwen, maar bijvoorbeeld games of andere software, dan zou ik toch ook een opleiding aanbevelen. Je kunt dan in je vrije tijd werken aan allerhande games. Op zo'n opleiding, zeg Technische Informatica of Informatica, zul je belangrijke basiskennis opdoen (zoals algoritmiek, grafen, artificiële intelligentie (zoekalgoritmen), optimalisatietechnieken, netwerken en gedistribueerde systemen ...), die je dan ook kunt toepassen op je vrije tijd-projecten. Zo'n papiertje staat *altijd* beter op je CV en zéker wanneer je dat kunt aanvullen met een paar leuke games die je tijdens je opleiding gemaakt hebt .

Ik vraag me af, en waarschijnlijk enkelen met mij, hoe je jezelf onderhoudt schijnbaar zonder (full-time) inkomsten uit werk (de eerste 2 jaar?), terwijl je toch geen opleiding volgt? Dit lijkt me geen duurbare situatie te zijn?

[rapture]

roy-t schreef op maandag 23 augustus 2010 @ 09:40:
Daar bij kan ik je vertellen dat de meeste gamedevelopment/design er meestal niet op gericht zijn om game programmers te kweken, omdat er zoveel aan bod komt (art, leveldesign, narrative design, concept design, mechanics, audio, etc..) dat programmeren een beetje ondergesneeuwd blijft soms.

Een solide informatica opleiding met daarna een specialisatie zoals alex3305 heeft gedaan zou mijn voorkeur hebben.

Er zijn 3 categorieën van opleidingen naar games te gaan:

• Grafische ontwerp, beeldende kunsten,... dat over art, levels, concepten,... gaat. Zonder dat heb je geen game en je weet niet wat je wilt programmeren. Maar deze mensen kloppen niet graag code.
• Traditionele informatica dat levert programmeurs op, maar hoeverre heb je een game als je alleen code zit te kloppen?
• Combinatie van de 2 (bv DAE in Kortrijk). Meestal heb je ofwel iemand die graag codeert ofwel iemand die grafisch sterk is. Het is een moeilijke combinatie om iemand te vinden die grafisch sterk is en niet vies van code kloppen is.

De TS kan een opleiding naar zijn profiel kiezen, maar hij moet eerst zijn middelbaar afwerken.

[roy-t]

@Rapture: die combinatie opleidingen zijn alleen meestal 'alles net niet', alleen in hele kleine groepen heb je wat aan mensen die alles een beetje kunnen. Zelfs voor kleine games werk je meestal toch wel met 5~10 man, waarbij je dus prima een dedicated programmeur en een dedicated artist kunt hebben.

@GameBuster

We waren hier nog even over aan het chatten in #XNA, omdat dit soort topic vaak voorkomen (en er eigenlijk altijd hetzelfde uit komt). We deden even een snelle poll, eigenlijk heeft iedereen vroeg in het begin aan een MMO of ander 'te' groot project gewerkt en geen van die projecten is tot een succesvol iets gekomen.

Verder zagen we ook dat je een planning op je site hebt staan, die hebben we even bekeken (ik neem aan dat je dit niet erg vind aangezien het er publiek op staat.) En zet het uit je hoofd, wat jij wilt doen zonder ervaring is ingewikkelder dan de mensen van Blizzard en Westwood doen met honderd gekwalificeerde mensen in meerdere jaren voor WoW en C&C.

Dus ja, eigenlijk kunnen we met zijn allen nog wel meerdere paginas op je in praten maar het blijft toch neerkomen op dit

1. Zet je huidige plan uit je hoofd of desnoods meerdere jaren in de koelkast
2. Zoek een studie die aansluit bij je toekomst plannen
3. Kies een high-level framework zoals XNA, Ogre, Unity3D
4. Begin met leuke kleine dingen in je vrije tijd zodat je kunt leren in plaats van door te veel hooi op je vork te nemen na 3 maanden ter aarde te storten in plaats van je langzaam hogerop werken in dit wereldje.

Zie het anders als een ander soort baan. Jij bent beginnend belastingadviseur die voor particulieren leuke aftrekposten vind en je wilt in 2 jaar omscholen naar in je ééntje de belasting kant van Google te regelen, dat is onmogelijk .

[bstudio]

OGRE is niet echt een high level framework he, alleen een rendering engine

Voor de rest idd agreed, zorg dat je klein begint (vooral puzzle games zijn prima gezien je jezelf dan ook erg met het programmeren kan bezig houden en art "minder" belangrijk is).

Unity is trouwens aan te raden als je niet heel erg van programmeren houdt, maar wel lekker wilt knutselen.

[ Voor 17% gewijzigd door bstudio op 23-08-2010 15:44 ]

[Hydra]

@GameBuster: je hebt nog geen antwoord gegeven op de vraag hoe je wilt voorkomen dat mensen in een P2P architectuur gaan cheaten.

[rapture]

En hoe ga je het synchroniseren? Door verschillende vertragingstijden tussen de peers komt het schot van de ene buurman sneller aan dan de andere. Je kan zelfs schieten op iets dat allang dood is. Op een gameserver is het duidelijk wiens schot eerst aankomt en hoeveel hitpoints iedereen op dat moment nog heeft.

[Gamebuster]

rapture schreef op maandag 23 augustus 2010 @ 16:16:
En hoe ga je het synchroniseren? Door verschillende vertragingstijden tussen de peers komt het schot van de ene buurman sneller aan dan de andere. Je kan zelfs schieten op iets dat allang dood is. Op een gameserver is het duidelijk wiens schot eerst aankomt en hoeveel hitpoints iedereen op dat moment nog heeft.

Ik ben nu bezig met een Mario-clone met COOP-multiplayer in Java. Hierin ga ik ook met P2P multiplayer werken, dus dan zullen we wel zien hoe ik dat ga synchroniseren

Als het in mijn mario-clone lukt, lukt het ook op grote schaal in een MMO-RTS.

[ResuCigam]

Gamebuster schreef op maandag 23 augustus 2010 @ 17:21:
[...]
Als het in mijn mario-clone lukt, lukt het ook op grote schaal in een MMO-RTS.

Na alle goede adviezen hierboven is dit je conclusie?

[Voutloos]

Gamebuster schreef op maandag 23 augustus 2010 @ 17:21:
Als het in mijn mario-clone lukt, lukt het ook op grote schaal in een MMO-RTS.

Want als iets een andere schaal is, kan het tenslotte nooit veel complexer zijn.

Ik stop met dit topic, want je doet toch niets met de adviezen cq. doet niets aan je roze bril. Bij deze wens ik je wel oprecht veel succes, laat wat van je horen als je een resultaat hebt.

[ Voor 26% gewijzigd door Voutloos op 23-08-2010 17:29 ]

[EddoH]

Waarom ga je nu in JAVA aan de gang? Je wilde toch C++ i.c.m OpenGL leren?
Of is dit dat alleen om je netwerkprincipe te testen?
Als ik jou was zou ik het dan gelijk goed doen en OpenGL erbij pakken.

[Gamebuster]

EddoH schreef op maandag 23 augustus 2010 @ 17:27:
Waarom ga je nu in JAVA aan de gang? Je wilde toch C++ i.c.m OpenGL leren?
Of is dit dat alleen om je netwerkprincipe te testen?
Als ik jou was zou ik het dan gelijk goed doen en OpenGL erbij pakken.

Princiepes testen. Ik heb inderdaad ook ruimte voor een OpenGL renderer, maar ik maak eerst 1tje in Java's eigen window-toolkit.

ResuCigam schreef op maandag 23 augustus 2010 @ 17:26:
[...]
Na alle goede adviezen hierboven is dit je conclusie?

Het gaat om het princiepe. Als ik in een simpele mario-game alles goed synchroon kan houden zou dat ook op grotere schaal kunnen. Als 2 spelers goed synchroon gehouden kunnen worden kan dat ook met 4, 8, 16 en 32 spelers, alleen moet de code dan beter geoptimaliseerd zijn. Als mijn mario clone klaar is kunnen we dit ook gewoon testen door COOP met 64 spelers toe te staan, kijken wat er gebeurt

Zitten we dan mario te spelen met 64 spelers

[ Voor 41% gewijzigd door Gamebuster op 23-08-2010 18:05 ]

[SH4D3H]

EddoH schreef op maandag 23 augustus 2010 @ 17:27:
Als ik jou was zou ik het dan gelijk goed doen en OpenGL erbij pakken.

Je wilt een testcase onnodig compliceren door een nieuwe onzekerheid toe te voegen?
Hoewel de TS wellicht beter wat met de adviezen kan doen, lijkt me dit toch niet zo'n goed idee.

Gamebuster schreef op maandag 23 augustus 2010 @ 17:58:
Als 2 spelers goed synchroon gehouden kunnen worden kan dat ook met 4, 8, 16 en 32 spelers, alleen moet de code dan beter geoptimaliseerd zijn.

Dat is wel erg simplistisch gesteld. 2 schapen naast elkaar laten lopen kan vrijwel iedereen, 32 schapen op een rijtje houden is toch echt een andere league.

[ Voor 37% gewijzigd door SH4D3H op 23-08-2010 18:12 ]

[rapture]

Doet mij denken aan de gatebug in EVE Online. Als 2 spelers op hetzelfde moment door een stargate willen jumpen, dan kan het gebeuren dat een speler een zwart scherm krijgt en niet geladen wordt. Dat is ok als er weinig verkeer is, maar als je fleets van minstens 200 man door een gate jaagt, dan blijft er maar de helft over. Na x aantal gates/halveringen blijft er niet veel van je fleet over.

Met weinig spelers is de kans dat je een probleem tegenkomt laag, maar naarmate het aantal spelers stijgen stijgt de kans naar een aan zekerheid grenzende waarschijnlijkheid.

[Gamebuster]

rapture schreef op maandag 23 augustus 2010 @ 18:13:
Doet mij denken aan de gatebug in EVE Online. Als 2 spelers op hetzelfde moment door een stargate willen jumpen, dan kan het gebeuren dat een speler een zwart scherm krijgt en niet geladen wordt. Dat is ok als er weinig verkeer is, maar als je fleets van minstens 200 man door een gate jaagt, dan blijft er maar de helft over. Na x aantal gates/halveringen blijft er niet veel van je fleet over.

Met weinig spelers is de kans dat je een probleem tegenkomt laag, maar naarmate het aantal spelers stijgen stijgt de kans naar een aan zekerheid grenzende waarschijnlijkheid.

Maar als het probleem helemaal niet voorkomt bij 2 spelers (lees: het komt nooit voor; als in: technisch onmogelijk), komt het ook niet voor bij 200. ALS het in mijn mario-clone dus zodanig goed geregeld is dat zulke dingen nooit voorkomen kan ik ditzelfde systeem ook gebruiken op meerdere spelers zonder dat het ooit voorkomt.

Persoonlijk, als ik iets schrijf houd ik er altijd rekening mee dat er geen dingen voorkomen waarbij in 0.1% van de gevallen er iets fout gaat. Ik zeg niet dat ik dit altijd correct doe, maar ik denk er van te voren altijd ruim over na om te voorkomen dat zulke problemen voorkomen.

Heel simpel voorbeeld: bij een website had iemand het idee om geuploade afbeeldingen op te slaan met een unix timestamp als de naam. Als dus 2 personen tegelijk een afbeelding uploaden heb je een probleem. Ik zou zelf dit soort problemen altijd vermijden. Als ik dit soort problemen compleet weet te vermijden komt dit probleem nooit meer voor bij 2 spelers, maar ook niet bij 20, 200 of 2000 spelers, simpelweg omdat het technisch gezien in orde is en er niet gewerkt wordt met "ooow, het heeft maar 0.001% kans dat het voorkomt, dus maakt het niet uit."

[ Voor 29% gewijzigd door Gamebuster op 23-08-2010 18:29 ]

[EddoH]

SH4D3H schreef op maandag 23 augustus 2010 @ 18:09:
[...]

Je wilt een testcase onnodig compliceren door een nieuwe onzekerheid toe te voegen?
Hoewel de TS wellicht beter wat met de adviezen kan doen, lijkt me dit toch niet zo'n goed idee.

Het ging me meer om de case. Waarom een hele mario clone maken om dan alleen netwerkfunctionaliteit te testen?
Een simpele pong oid, ok, maar een mario clone is nogal veel 'overhead' m.b.t de netwerkfunctionaliteit. Als je het dan toch gaat maken, waarom dan niet gelijk het grafische gedeelte m.b.v OpenGl. Deze 2 onderdelen staan compleet op zichzelf, van het 1 wordt het ander niet gecompliceerder.

Daarnaast vind ik de keuze voor een Mario-clone nogal vergezocht als het gaat om synchroniseren van spelers in een MMO game.

[Gamebuster]

EddoH schreef op maandag 23 augustus 2010 @ 18:31:
[...]


Het ging me meer om de case. Waarom een hele mario clone maken om dan alleen netwerkfunctionaliteit te testen?
Een simpele pong oid, ok, maar een mario clone is nogal veel 'overhead' m.b.t de netwerkfunctionaliteit. Als je het dan toch gaat maken, waarom dan niet gelijk het grafische gedeelte m.b.v OpenGl. Deze 2 onderdelen staan compleet op zichzelf, van het 1 wordt het ander niet gecompliceerder.

Daarnaast vind ik de keuze voor een Mario-clone nogal vergezocht als het gaat om synchroniseren van spelers in een MMO game.

Maar het gaat niet alleen om het netwerk, het gaat om het geheel. Bovendien heb je met mario ook te maken met AI die je synchroon moet houden over alle spelers. Verder, met de level-editor kan je hier best geinige dingen mee doen. Gewoon een game-mode erbij bakken waarbij je met 16 spelers tegelijk een enorme hoeveelheid vijanden moet afmaken, of iets dergelijks. Als zulke dingen allemaal goed werken lijkt me dat toch wel een mooi begin.

Verander wat cijfertjes en voeg nieuwe sprites toe en je hebt een compleet nieuwe game.

Daarbij kan ik ook OpenGL gaan leren ermee, inderdaad. Ik kan 2 versies maken: 1 waarbij ik allemaal vierkantjes teken en daar de sprites als textures op plak en zou zelfs een 3D view kunnen maken met 3D versies van de characters en nieuwe animaties, puur om te oefenen. Hoef alleen maar een andere view toe te voegen.

[ Voor 11% gewijzigd door Gamebuster op 23-08-2010 18:46 ]

[beany]

Gamebuster schreef op maandag 23 augustus 2010 @ 18:23:
[...]

Maar als het probleem helemaal niet voorkomt bij 2 spelers (lees: het komt nooit voor; als in: technisch onmogelijk), komt het ook niet voor bij 200. ALS het in mijn mario-clone dus zodanig goed geregeld is dat zulke dingen nooit voorkomen kan ik ditzelfde systeem ook gebruiken op meerdere spelers zonder dat het ooit voorkomt.

Persoonlijk, als ik iets schrijf houd ik er altijd rekening mee dat er geen dingen voorkomen waarbij in 0.1% van de gevallen er iets fout gaat. Ik zeg niet dat ik dit altijd correct doe, maar ik denk er van te voren altijd ruim over na om te voorkomen dat zulke problemen voorkomen.

Heel simpel voorbeeld: bij een website had iemand het idee om geuploade afbeeldingen op te slaan met een unix timestamp als de naam. Als dus 2 personen tegelijk een afbeelding uploaden heb je een probleem. Ik zou zelf dit soort problemen altijd vermijden. Als ik dit soort problemen compleet weet te vermijden komt dit probleem nooit meer voor bij 2 spelers, maar ook niet bij 20, 200 of 2000 spelers, simpelweg omdat het technisch gezien in orde is en er niet gewerkt wordt met "ooow, het heeft maar 0.001% kans dat het voorkomt, dus maakt het niet uit."

Op de 1 of andere manier ben ik dolgelukkig dat jij geen software schrijft voor medische apparatuur, of medische administratie software, of software voor kerncentrales, of software voor elektriciteitsnetwerken, of ......

[Gamebuster]

beany schreef op maandag 23 augustus 2010 @ 18:44:
[...]

Op de 1 of andere manier ben ik dolgelukkig dat jij geen software schrijft voor medische apparatuur, of medische administratie software, of software voor kerncentrales, of software voor elektriciteitsnetwerken, of ......

Die volg ik even niet.

Heel simpel voorbeeld: bij een website had iemand het idee om geuploade afbeeldingen op te slaan met een unix timestamp als de naam. Als dus 2 personen tegelijk een afbeelding uploaden heb je een probleem. Ik zou zelf dit soort problemen altijd vermijden.

Hier omschreef ik dat iemand anders die fout had gemaakt en dat ik persoonlijk juist dat soort fouten vermijdt om er zeker van te zijn dat mijn software in alle gevallen werkt en niet bij 0.0001% van de gevallen faalt.

Als ik zou moeten kiezen tussen mijn eigen software of de software van het genoemde voorbeeld, zou ik toch eerder voor mijn eigen software kiezen om op mijn kerncentrale te draaien

Waarschijnlijk had je mijn post verkeerd gelezen, of bedoel je nu iets anders?

[ Voor 3% gewijzigd door Gamebuster op 23-08-2010 18:50 ]

[roy-t]

Gamebuster schreef op maandag 23 augustus 2010 @ 17:58:
[...]

Princiepes testen. Ik heb inderdaad ook ruimte voor een OpenGL renderer, maar ik maak eerst 1tje in Java's eigen window-toolkit.


[...]

Het gaat om het princiepe. Als ik in een simpele mario-game alles goed synchroon kan houden zou dat ook op grotere schaal kunnen. Als 2 spelers goed synchroon gehouden kunnen worden kan dat ook met 4, 8, 16 en 32 spelers, alleen moet de code dan beter geoptimaliseerd zijn. Als mijn mario clone klaar is kunnen we dit ook gewoon testen door COOP met 64 spelers toe te staan, kijken wat er gebeurt

Zitten we dan mario te spelen met 64 spelers

Ohja want CCP en Blizzard gebruiken vast dezelfde algoritmes voor EVE (40k man synchroon per server) en WoW (7k per server) als dat ik gebruik voor 2 spelers.

Langzaam aan begin ik te geloven dat je ons gewoon loopt te trollen, zelfs 2 versus 32 is al een wereld van verschil, de bedoeling van je Mario prototype (zoals ik het voorstelde) was dat je iig alvast iets van netwerking had om aan te ruiken.

En stop nu eens en denk nu eens na over algoritmes e.d. voordat je telkens maar botweg ergens mee begint.

"Als dit me lukt"-> hoe ga ik ervoor zorgen dat dit lukt.

Het belangrijkste gedeelte van programmeren gebeurt toch vaak op je kladblokje op je bureau.

Sorry maar aardig modus gaat nu uit. Je kletst uit je nek en doet door die domheid ontzettend elitair, yeah right, CCP en Blizzard hebben meerdere PHD network-engineers werken en hebben toch af en toe bugs, maar nee meneer gaat het foutvrij voor 2 maken dus dan werkt datzelfde algoritme ook voor infinity and beyond, daar hadden ze nog nooit aan gedacht bij CCP...


Maar ach, hier kom je uiteindelijk zelf wel achter


Oh en beany bedoelt dat je een triviaal probleem (waarbij iemand gewoon duidelijk de verkeerde oplossing heeft gekozen en jij dat terecht hebt gefixed) vergelijkt met een niet triviaal niet 'compleet oplosbaar' probleem.

[ Voor 6% gewijzigd door roy-t op 23-08-2010 18:56 ]

[rapture]

Gamebuster schreef op maandag 23 augustus 2010 @ 18:23:
Maar als het probleem helemaal niet voorkomt bij 2 spelers (lees: het komt nooit voor; als in: technisch onmogelijk), komt het ook niet voor bij 200. ALS het in mijn mario-clone dus zodanig goed geregeld is dat zulke dingen nooit voorkomen kan ik ditzelfde systeem ook gebruiken op meerdere spelers zonder dat het ooit voorkomt.

Elke gameserver heeft grenzen in zijn schaling, vroeg of laat knal je tegen de grenzen aan. Dan zoek je wel naar een manier op de grens te verleggen.

Een eenvoudig voorbeeld is sequentieel schoten verwerken. Elke speler heeft 8 guns/lasers op zijn ruimteschip staan en ze schieten om de 4 seconden. Normaal zou elke speler op een willekeurig moment de guns activeren zodat je gemiddeld kan zeggen 200 speler * 8 guns / 4 seconden = 400 schoten per seconde.

Maar je kan op TS/vent ook een doelwit als primair doelwit uitroepen en een groot percentage van 200 spelers rammen allemaal op F1 tot F8 om hun guns allemaal tegelijkertijd af te gaan. Stel dat 100 spelers binnen een tijdsperiode van 1 seconde het vuur openen, dan heb je 800 schoten per seconde. Stel dat je in 1 ms een schot kan doorrekenen en je bent 0,8s bezig met de schoten te verwerken.

EVE Online kennende proberen de allianties zoveel spelers in te zetten totdat ze de node kapot krijgen. Met 400 man worden de schoten in 1,6 seconde doorgerekend, 800 man 3,2 seconde, 1000 man 4 seconde en 1600 man 6,4 seconde. Inderdaad de guns zouden in EVE sneller schieten dan dat ze kunnen doorgerekend worden en ze beginnen te cyclen. De client toont dat een schot van 4 seconde na 4 seconden nog altijd niet gedaan is. Tussendoor moet de posities van de ruimteschepen die aan het bewegen zijn ook doorgerekend worden.

[Gamebuster]

roy-t schreef op maandag 23 augustus 2010 @ 18:52:
Sorry maar aardig modus gaat nu uit. Je kletst uit je nek en doet door die domheid ontzettend elitair, yeah right, CCP en Blizzard hebben meerdere PHD network-engineers werken en hebben toch af en toe bugs, maar nee meneer gaat het foutvrij voor 2 maken dus dan werkt datzelfde algoritme ook voor infinity and beyond, daar hadden ze nog nooit aan gedacht bij CCP...


Maar ach, hier kom je uiteindelijk zelf wel achter

Je wilt niet weten hoe vaak mensen zulke dingen tegen mij zeggen. Meestal hebben ze ook gelijk, maar ik probeer het toch altijd. Niet alleen met programmeren overigens.

rapture schreef op maandag 23 augustus 2010 @ 19:03:
[...]
Elke gameserver heeft grenzen in zijn schaling, vroeg of laat knal je tegen de grenzen aan. Dan zoek je wel naar een manier op de grens te verleggen.

Een eenvoudig voorbeeld is sequentieel schoten verwerken. Elke speler heeft 8 guns/lasers op zijn ruimteschip staan en ze schieten om de 4 seconden. Normaal zou elke speler op een willekeurig moment de guns activeren zodat je gemiddeld kan zeggen 200 speler * 8 guns / 4 seconden = 400 schoten per seconde.

Maar je kan op TS/vent ook een doelwit als primair doelwit uitroepen en een groot percentage van 200 spelers rammen allemaal op F1 tot F8 om hun guns allemaal tegelijkertijd af te gaan. Stel dat 100 spelers binnen een tijdsperiode van 1 seconde het vuur openen, dan heb je 800 schoten per seconde. Stel dat je in 1 ms een schot kan doorrekenen en je bent 0,8s bezig met de schoten te verwerken.

EVE Online kennende proberen de allianties zoveel spelers in te zetten totdat ze de node kapot krijgen. Met 400 man worden de schoten in 1,6 seconde doorgerekend, 800 man 3,2 seconde, 1000 man 4 seconde en 1600 man 6,4 seconde. Inderdaad de guns zouden in EVE sneller schieten dan dat ze kunnen doorgerekend worden en ze beginnen te cyclen. De client toont dat een schot van 4 seconde na 4 seconden nog altijd niet gedaan is. Tussendoor moet de posities van de ruimteschepen die aan het bewegen zijn ook doorgerekend worden.

Bij mijn MMO-RTS heb je geen lange-afstands wapens en zal de gameplay zo zijn dat men niet gaat groeperen en verspreid blijven. Spelers worden enkel met elkaar verbonden als ze in elkaars actie-radius zijn. Ondanks dat het een MMO-RTS is ben je dus eigenlijk maar verbonden met slechts een paar spelers tegelijk; zeker niet meer dan 32.

Het dynamisch verbinden van de clients gebeurt via een stukje software dat de afstanden tussen clients berekent en op basis daarvan clients de opdracht geeft een verbinding naar elkaar te openen. Dit stukje software weer op enkele clients. Iedere server krijgt dan "beheer" over een bepaald lap grond. Deze server moet de afstand bereken tussen alle clients en clients de opdracht geven met elkaar te verbinden indien nodig. Ook zal deze server clients doorgeven aan andere servers indien de client's units zich buiten het toegewezen gebied van de server verplaatsen. Omdat de servers op clients draaien zullen meerdere clients toegewezen worden aan hetzelfde gebied; mocht 1 van de server onverwacht verdwijnen omdat de client het spel afsluit, dan is die andere client met de server er nog. Indien alle clients met servers over dat gebied verdwijnen moet er z.s.m. een nieuwe client toegewezen worden of zal er een eventuele backup server gebruikt worden zolang er nog geen nieuwe client is toegewezen.

Houd er rekening mee dat het hier gaat om servers die clients met elkaar verbinden wanneer ze in de buurt van elkaar komen; als het een paar seconden duurt voordat er eindelijk een nieuwe server is, merken de spelers daar niets van. Als dit nog langer duurt is er een kans dat 2 spelers niet met elkaar verbonden zijn, ondanks dat ze wel elkaar zouden kunnen zien. Dan krijg je dus synchronisatie-problemen en dit mag dus niet voorkomen.

Verder, de clients krijgen de melding om hun positie eens in de paar seconden door te geven aan de servers; de clients weten dus welke servers beheer hebben over het gebied waar zij zijn. Indien een speler het spel normaal afsluit, zal de client's server nog doorgeven aan de centrale server dat er een nieuwe server toegewezen moet worden aan een client, waarna de client's server al zijn clients doorverwijst naar de nieuwe server.

Het spel zelf is niet zo complex dus de meeste clients hebben genoeg CPU kracht over voor dit soort taken. Eventueel ga ik een soort performance test draaien van te voren om te zien of er nog CPU kracht over is op de client. Natuurlijk moet er ook genoeg bandbreedte over zijn, maar de benodigde bandbreedte zal wel meevallen; het gaat hier om clients die enkel een globale indicatie van hun locatie meesturen met een eventuele radius, bijv. locatie 14567.234x-13453.334, en de units zijn verspreid binnen een cirkel/vierkant met een diameter/hoogte van 34.933.

Een bericht-type, 3 double's of float's, een IP'tje of client-id en een timestamp moet voldoende zijn. Het berekenen van de afstand tussen 2 clients is dan ook met een simpel sommetje gelukt. De CPU kracht die nodig is, is wat hoger: als een server 256 spelers toegewezen krijgt moet het 256^2 afstanden berekenen.

Vervolgens moet de server terugsturen met welke clients een client moet verbinden en met welke clients hij de verbinding moet verbreken. De server moet dus een soort database hebben met welke clients een client verbonden is. Indien iedere client met gemiddeld 16 andere clients verbonden is heb je hier een array van 256x16 client-id's. Vervolgens moet de server controleren of er veranderingen zijn of de client met een andere client verbonden moet worden door de resultaten van de afstands-tests te vergelijken met de huidige database en alle veranderingen doorgeven aan de clients.

Alle veranderingen moeten vervolgens weer doorgegeven worden aan de clients. Dit zijn maximaal 256 berichtjes met een lijstje met client-id's waarmee verbonden moet worden en waarmee de verbinding verbroken moet worden.

Ik kan zo nog wel 'ff doorgaan, maar om nou het hele verhaal weer uit te typen lijkt me onnodig.

[ Voor 94% gewijzigd door Gamebuster op 23-08-2010 19:43 ]

[Gomez12]

Gamebuster schreef op maandag 23 augustus 2010 @ 18:42:
[...]

Maar het gaat niet alleen om het netwerk, het gaat om het geheel. Bovendien heb je met mario ook te maken met AI die je synchroon moet houden over alle spelers. Verder, met de level-editor kan je hier best geinige dingen mee doen. Gewoon een game-mode erbij bakken waarbij je met 16 spelers tegelijk een enorme hoeveelheid vijanden moet afmaken, of iets dergelijks. Als zulke dingen allemaal goed werken lijkt me dat toch wel een mooi begin.

Verander wat cijfertjes en voeg nieuwe sprites toe en je hebt een compleet nieuwe game.

Daarbij kan ik ook OpenGL gaan leren ermee, inderdaad. Ik kan 2 versies maken: 1 waarbij ik allemaal vierkantjes teken en daar de sprites als textures op plak en zou zelfs een 3D view kunnen maken met 3D versies van de characters en nieuwe animaties, puur om te oefenen. Hoef alleen maar een andere view toe te voegen.

Misschien een raar idee, maar waarom werk je dat Mario idee niet verder uit en ga je daar 2 jaar oid insteken?

Want zoals het nu op mij overkomt denk je wel even een Mario game te gaan maken met wat multiplayer modi en verschillende views, terwijl je daar ( als je ervaren zou zijn ) al makkelijk ruim langer dan een jaar in je eentje over doet.
Terwijl volgens mij enkel het doel was een simpele mario als network test te maken ( wat ook al ongeveer 2 maanden zou kosten )