En toen kondigde Unity plotseling veranderingen aan zijn prijsbeleid aan. De game-industrie was eind 2023 flink in oproer nadat de populairste game-engine een nieuwe invulling van zijn licenties ging hanteren. In eerste instantie werd menig ontwikkelaar afgeschrikt door het agressieve beleid. Intussen is de storm weer wat gaan liggen, mede doordat de toenmalige ceo van dat bedrijf vertrok en het beleid iets werd afgezwakt. Toch bleek deze saga een confronterende herinnering voor ontwikkelaars: bedrijven waarvan zij afhankelijk zijn, hebben wellicht meer macht in handen dan ze dachten.
In de nasleep van het Unity-drama leek de oplossing vrij voor de hand te liggen: opensource-engines en zelfs volledige opensourcegameontwikkeling. Dat kost immers niets en je loopt geen risico om verrast te worden door een licentieverandering. Tot dusver maakt dit, ondanks die voordelen, slechts een relatief klein deel van de game-industrie uit, terwijl het overgrote deel van de gameontwikkelaars nog steeds vertrouwt op afgeschermde software van derden.
Volgens voorstanders van deze ontwikkelingswijze lijkt het concept van open source aan een stevige opmars bezig in de gamewereld, vooral onder kleine ontwikkelaars die anders erg afhankelijk zijn van derden om hun games te kunnen creëren en onderhouden. Het aantal commercieel verkrijgbare games op basis van een opensource-engine is vooralsnog erg klein, maar er is één duidelijke koploper in deze beweging: Godot. Tweakers sprak voor een dwarsdoorsnede van de opensourcegame-industrie met verschillende schakels in de opensourceketen, van de assetmaker tot de ontwikkelaar en natuurlijk met de Godot Foundation zelf.
Er zijn anno 2024 tientallen opensourcegame-engines beschikbaar onder verschillende licenties. Toch wordt geen van deze engines in principe gebruikt voor een populaire of op een andere manier significante game. Er is echter een uitzondering: Godot. In de afgelopen jaren hebben tientallen kleine ontwikkelaars, soms niet meer dan een individu met een goed idee, een game uitgebracht op basis van deze engine. Sommige wisten de mainstream te bereiken, voor zover dat mogelijk is met een indiegame. Voor zover bekend zijn de bekendste en succesvolste titels Brotato, Dome Keeper en Buckshot Roulette. Deze zijn naar schatting bijna vijf miljoen keer verkocht. Ook de Slay the Spire-sequel wordt gemaakt met Godot.
Gratis en opensource
De opensource-engine Godot is met die titels in de highlightreel veruit de grootste in deze nichecategorie. In tegenstelling tot de engines van veel andere games, heeft iedereen volledige toegang tot de software en onderliggende code. Deze opensourcegame-engine, geschikt voor 2d- en 3d-games, mag iedereen gratis gebruiken voor zowel privéprojecten als commerciële producten. Dat betekent dat elke gebruiker, in tegenstelling tot bij propriëtaire engines, toegang tot de broncode van de engine kan krijgen. Hierdoor kan hij of zij zelfs eventuele bugs verhelpen en functies toevoegen.
Emilio Coppola, executive director van de Godot Foundation, vindt deze benadering vanzelfsprekend: "In de wereld van programmeren is praktisch alles opensource. De game-industrie loopt wat dat betreft nog erg achter." Volgens hem zou het voor de industrie gunstig zijn als er meer opensource-engines op de markt zouden komen.
De Godot-engine werd ongeveer tien jaar geleden voor het eerst publiekelijk en gratis uitgebracht door ontwikkelaars Juan Linietsky en Ariel Manzur. Sindsdien is de non-profitorganisatie uitgegroeid tot een organisatie met tien medewerkers en enkele duizenden contributors, vrijwilligers die bijdragen leveren aan de code van het project. Die organisatiestructuur vormt de basis voor de identiteit van de Godot Foundation, legt Coppola uit: "Ons hoofddoel is om een engine te ontwikkelen die de community wil." Omdat er enkele duizenden vrijwilligers bijdragen aan de code voor Godot, stuurt de community in feite mee aan de ontwikkelingsrichting van de engine.
Verdubbeling donaties en licentieloosheid
De enginemaker is volledig afhankelijk van donaties van gebruikers en bedrijven. Hoewel de verhouding tussen die twee donerende groepen steevast ongeveer 50/50 is, zag de organisatie eind 2023 een drastische verandering in het donatiegedrag van gebruikers. "De organisatie ontving voorheen gemiddeld 25.000 euro aan donaties per maand. Na de controverse met Unity was dat het dubbele", aldus Coppola. Volgens hem is de reden voor de verdubbeling van de donaties sinds de Unity-saga simpel; het laatstgenoemde bedrijf paste plotseling zijn voorwaarden aan, wat voor veel ontwikkelaars tot een confronterende realisatie heeft geleid: "Het voortbestaan van een ontwikkelaar kan door de aanpassing van de voorwaarden van een bedrijf zonder waarschuwing in het geding komen."
Hoe zat dat met Unity?
In september van 2023 kondigde Unity Technologies een vernieuwd prijsmodel aan waarbij ontwikkelaars zouden moeten gaan betalen per game-installatie. Deze extra Runtime Fee zou gelden vanaf een bepaalde omzet van de betreffende games, waardoor kleine ontwikkelaars in theorie gespaard zouden blijven.
Toch ontstond er grote ophef binnen de game-industrie. Als reactie hierop heeft Unity het prijsbeleid afgezwakt, onder meer door de drempelwaarde van de jaaromzet van een game te verhogen naar een miljoen dollar en de Fee op maximaal 2,5 procent van de omzet van een game te stellen. Bestaande games werden vrijgesteld.
Unity is voor zover bekend de populairste propriëtaire game-engine op de markt. Naar eigen zeggen drijft het 69 procent van de 'grootste mobiele games' aan. In 2022 was het naar schatting de primaire engine voor 38 procent van de gameontwikkelaars. Unreal Engine had, als de op een na grootste, een marktaandeel van 15 procent.
Dat heeft alles te maken met licenties. Grote propriëtaire engines zoals Unity en Unreal Engine bieden verschillende licentieopties aan, afhankelijk van het beoogde gebruik. In principe zijn die engines gratis voor privégebruik en in een educatieve context, en kosten ze een maandelijks licentiebedrag voor commerciële toepassing. In de vermelde gevallen wordt er daarnaast een extra royaltybedrag, door Unity de beruchte Runtime Fee genoemd, in rekening gebracht wanneer een product meer dan een miljoen dollar omzet. Unity Technologies en Epic Games hanteren andere voorwaarden voor wanneer deze extra kosten precies in rekening worden gebracht, maar voor beide bedrijven is die miljoen dollar een omslagpunt.
De Godot Foundation biedt geen verschillende licentieopties of abonnementen aan. De engine is voor iedereen gratis beschikbaar onder de MIT-licentie, ongeacht het beoogde gebruik. Deze licentie, ontwikkeld door het Massachusetts Institute of Technology, staat binnen de opensourcecommunity algemeen bekend als een 'permissive' licentie. Onder deze licentie mag iedereen gratis en vrijblijvend kopieën van de software en bijbehorende documentatie maken, de kopie wijzigen, samenvoegen, publiceren, distribueren, een sublicentie uitgeven en verkopen. Daar is maar één voorwaarde voor: "De bovenstaande copyright- en deze toestemmingsverklaring moeten inbegrepen worden in alle kopieën of substantiële delen van de software." Met andere woorden, iedereen mag software beschermd met de MIT-licentie gratis gebruiken voor alle doeleinden, zolang die licentie ook wordt vermeld in afgeleiden van de oorspronkelijke software.
Coppola erkent dat de Godot Foundation de licentievoorwaarden zou kunnen veranderen van toekomstige releases; gebruikers moeten erop vertrouwen dat dit niet gebeurt. Dit past daarentegen niet bij de missie van de organisatie om 'projecten opensource te maken en te houden', zo beweert hij. "We hebben vanwege onze organisatiestructuur als non-profit een hele andere motivatie dan bijvoorbeeld Unity. We hebben namelijk geen winstoogmerk en ook geen aandeelhouders waar we verantwoording aan moeten afleggen." De licentie van bestaande releases van Godot kunnen overigens ook niet retroactief aangepast worden.
Hij gaat verder: "En zelfs al zouden we Godot plots onder een andere licentie uitbrengen of veel geld vragen, we hebben slechts tien vaste werknemers en zijn voor ons voortbestaan volledig afhankelijk van de bijdrage van vrijwilligers." Als al die contributors stoppen met het maken van nieuwe functies, het auditen van code en het onderhouden van bestaande code, is het volgens hem snel afgelopen met de engine.
Bron: Godot / Beehave (MIT License)
Bottleneck: kundige programmeurs
De nadruk op vrijwilligers en het crowdsourcen van bijdragen aan de Godot-code is tegelijkertijd ook een bottleneck, geeft Coppola toe. "Iedereen wil spannende nieuwe functies maken, zoals de tilemaps toevoegen aan de engine, maar weinig contributors hebben zin om bugs in bestaande functies zoals de animatiespeler op te lossen." In het verlengde daarvan moeten deze nieuwe functies vervolgens gecontroleerd en bijgehouden worden en moet de compatibiliteit met bestaande functies gewaarborgd worden, taken die niet alle vrijwilligers even leuk vinden om te doen.
Naast het niet willen uitvoeren van bepaalde taken, is er ook nog een deel van de programmeertaken die de meeste contributors simpelweg niet kunnen doen. "Geavanceerde programmeertaken, zoals de implementatie van een physicsengine, vereisen hele specifieke vaardigheden. Een physics engineer zal zich sneller bij een van de grote bedrijven aansluiten, want wij kunnen geen concurrerend salaris aanbieden", aldus Coppola. Andere voorbeelden van gespecialiseerde werknemers, die hij 'eenhoorns' noemt, zijn audio-engineers en programmeurs met kennis van code dicht bij het driverniveau.
Als positieve noot merkt hij op dat ook de grote bedrijven die deze werknemers inhuren, ten koste van de Godot Foundation, baat hebben bij de ontwikkeling van opensourceprojecten. Hij noemt off the record zeer bekende bedrijven, die achter de schermen niet alleen geld, maar ook werkkrachten aan de organisatie doneren.
Industrie stapt nog niet over
Dat grote techbedrijven alleen achter de schermen dergelijke projecten steunen en daar niet mee naar buiten treden, is wellicht kenmerkend voor de manier waarop de bredere techindustrie momenteel naar opensourceprojecten kijkt. Volgens Coppola staat opensourcegameontwikkeling nog in de kinderschoenen en is het lastig om de huidige gang van zaken te veranderen. "Het gebruik van propriëtaire software is diep geworteld in de gehele productiepijplijn van de game-industrie. Het is dus een risico voor grote studio's om op andere software over te stappen. Waarom zou je immers overstappen als het huidige systeem werkt?"
Daar ligt volgens hem in elk geval deels een zelfversterkend effect aan ten grondslag. De meeste beginnende programmeurs en ontwikkelaars zouden zich immers richten op bestaande productieprocessen om een baan in de industrie te kunnen bemachtigen en leren geen nieuwe software te gebruiken. Daarom noemt Coppola het aanbieden van instructiemateriaal als de belangrijkste manier om verder te groeien: "Een van de manieren waarop een beginnende ontwikkelaar een engine kiest, is door naar YouTube te gaan en te zoeken op 'hoe maak ik een game'. De algemene beschikbaarheid van tutorials is belangrijk voor potentiële gebruikers.""De game-industrie gaat richting een keerpunt."
Vooralsnog blijft Godot vooral een engine die, vanwege het opensourcekarakter, de non-existente kosten en de algemene toegankelijkheid, vooral in trek is bij kleine ontwikkelaars. Ook de organisatie achter de engine is voorlopig relatief klein en richt zich met de toename van de donaties op het uitbreiden van het aantal vaste werknemers 'die taken op zich willen nemen die de community liever overslaat'. Coppola redeneert dat open source hoe dan ook een trend aan het worden is in de game-industrie: "Elk jaar worden games complexer, vereisen ze meer financiële middelen en zijn ze langer in ontwikkeling. Tegelijkertijd ontslaan grote studio's massaal werknemers. De game-industrie nadert een keerpunt."
Bron: Godot
De ontwikkelaar: Buckshot Roulette
De controverse rondom Unity was indirect gunstig voor de Godot Foundation, maar was vooral een confronterende ontwikkeling voor ontwikkelaars, waaronder voor de Estse ontwikkelaar Mike Klubnika. Hij maakte meerdere kleine horrorgames met Unity, maar schrok naar eigen zeggen van de verandering van de licentievoorwaarden van die engine, hoewel hij als kleine ontwikkelaar niet in aanmerking zou komen voor de Runtime Fee. Voor de 'mentale rust' stapte hij over op Godot.
Achteraf gezien zou hij wellicht extra hebben moeten betalen aan Unity. Met de initiële Itch.io-release van Buckshot Roulette in september van 2023 en vooral met de daaropvolgende Steam-release in april van 2024 maakte Klubnika namelijk een onverwachtse indiehit onder streamers. De grimmige game, waarin de speler Russische roulette speelt met een shotgun, is tot dusver ruim een miljoen keer verkocht; meer dan genoeg om de inkomstendrempel van Unity te overschrijden.
De ontwikkelaar beschrijft het proces van overstappen van engine: "Ik had al twee jaar in Unity geïnvesteerd en was huiverig om helemaal opnieuw te moeten beginnen met het leren van een engine. Maar Godot kon ik leren binnen twee weken, zij het uitdagende weken. De overstap was relatief eenvoudig." Dat heeft volgens Klubnika met de relevante programmeertalen te maken. Om de gameplay te programmeren, gebruikt Godot een eigen taal, genaamd GDScript, die wat syntax en schrijfstijl betreft lijkt op Python. Hij stelt: "Als je C# (de programmeertaal in Unity, red.) kunt schrijven, kun je ook Python schrijven, en dus kun je GDScript leren."
Bron: Godot
Tekortkomingen Godot
Het leren van Godot betekent ook leren omgaan met de beperkingen, beschrijft de ontwikkelaar. "Unity is een enorme engine die ontzettend stabiel is. Godot is in sommige opzichten het omgekeerde: een kleinere engine met wat minder ondersteuning en functies." Tijdens de ongeveer 2,5 maand durende ontwikkeling van Buckshot Roulette, merkte hij op dat keyframes voor animaties soms niet goed opgeslagen werden, wat in Unity niet gebeurt. "Je komt zo nu en dan wat kleine fouten en ongemakken in Godot tegen.""Je komt zo nu en dan wat kleine fouten en ongemakken in Godot tegen."
Ook noemt hij het gebrek aan een afspeelfunctie in de opensource-editor als belangrijke tekortkoming: binnen de editoromgeving gebruikt Godot zogenoemde nodes om ieder aspect van de game op te bouwen. Nodes beschrijven een aspect van een game-element, zoals vorm, animatie, geluid of spelonderdeel. Deze aspecten kunnen gecombineerd worden tot een nodetree, een aaneenschakeling van nodes die samen een groter onderdeel vormen, zoals een personage, omgeving of interface. Individuele onderdelen kunnen in de editor bekeken worden, maar niet het geheel. "Het is moeilijker om een project in Godot te debuggen omdat je de game niet in de editor kunt draaien zoals dat in Unity of Unreal kan."
Die twee engines zijn al sinds het begin van deze eeuw toonaangevend en hebben sindsdien talloze upgrades en nieuwe functies gekregen, terwijl Godot nog relatief nieuw is. Dat blijkt ook uit de uitdagingen bij het ontwikkelen van de consoleport van Buckshot Roulette. Klubnika: "Als de game met Unity gemaakt zou zijn, had ik met behulp van een al beschikbare sdk de game vrij gemakkelijk naar consoles kunnen porten. Een dergelijke sdk is er niet voor Godot."
Toegankelijkheid is grootste kracht
'Godot start projecten in een oogwenk op'Daar tegenover staat de toegankelijkheid van de opensource-engine. Klubnika vergelijkt de omvang van Godot en Unity om dit te illustreren. Godot 4.2.2 is namelijk een executable van grofweg 100MB, terwijl een kale versie van Unity 2022.3.xx, inclusief installatiehub, al snel honderd keer zo groot is. "Vanwege de omvang van de engines start je projecten in Godot in een oogwenk op, in Unity kan dat ontzettend lang duren."
Die toegankelijkheid wordt volgens hem een steeds belangrijker voordeel van de opensource-engine, met de kanttekening dat ontwikkelaars soms ook heel afhankelijk zijn van de beschikbaarheid van tools van derde partijen binnen het opensourcecircuit. Als voorbeeld geeft hij aan dat hij momenteel werkt aan een multiplayermodus voor Buckshot Roulette. Om dat voor de Steam-versie van de game mogelijk te maken, moet een bepaalde Steam-sdk in het spel worden geïmplementeerd, zodat gebruikers van dat platform met elkaar kunnen spelen. "Dat is niet iets wat Godot standaard ondersteunt, maar dankzij de opensourcemodule en -plug-in GodotSteam kan dat wel."
Assets voor opensourcegames
De opensourcegame-industrie is dus voor de ontwikkeling van de engine en daarop gebaseerde games sterk afhankelijk van het veelal gratis werk van programmeurs en ontwikkelaars. Maar een game bestaat uit meer dan een engine en het idee van een maker: bijvoorbeeld de assets, de individuele elementen waaruit een game wordt opgebouwd. Ook daarvoor is binnen de opensourcegamestroming een alternatief: gratis assets. De Nederlander Kenney Vleugels, professioneel onder zijn voornaam bekend, maakt assets die hij vervolgens gratis aanbiedt op zijn website.
Waarom opensource?"Iedereen moet met zo weinig mogelijk belemmering toegang hebben tot software."
Je zou je kunnen afvragen waarom iemand zijn werk zomaar weggeeft. Kenney doet dit als hoofdzakelijk werk en onderhoudt daarnaast het Nationaal Archief Educatieve Games, waar honderden educatieve games gratis worden aangeboden. De initiatieven hebben eenzelfde overtuiging als drijfveer: "Iedereen moet met zo weinig mogelijk belemmering toegang hebben tot software." Als het om zijn assets gaat, stelt hij dat het niet zou moeten uitmaken of een persoon nog studeert, in armoede leeft of in een land woont dat vanwege sancties geen geld kan overmaken naar een bedrijf in het buitenland: "Ook die mensen moeten games kunnen maken."
Kenney publiceert zijn assets onder de Creative Commons CC0 1.0-licentie. Dit betekent dat ze geen copyright hebben en dus deel uitmaken van het publieke domein. De assets zijn vrij te gebruiken, al is er volgens hem in het geval van visuele elementen technisch gezien geen sprake van 'open source'. "Open source is een mindset. Deze community richt zich op samenspel en elkaar helpen, in tegenstelling tot het commerciële denken waarbij alles in de eerste plaats in eigenbelang is."
Bron: Kenney
Bestaan als maker gratis assets is onzeker
Die houding heeft ervoor gezorgd dat de assets van Kenney in uiteenlopende media gebruikt werden, waaronder in grote games, tijdens een Apple WWDC-presentatie en in een artikel van The New York Times. Met de kanttekening dat het doorgaans niet volledig zeker is of het inderdaad om zijn assets gaat. "Bedrijven hoeven geen toestemming te vragen om mijn assets te gebruiken. Ik weet dus niet wie ze gebruikt en of ze eventueel zijn aangepast." De enige indicatie van de populariteit van zijn assets is het internetverkeer. Er wordt maandelijks zo'n 1,5TB aan data van zijn website gedownload. Ter referentie: de meeste assetpacks zijn .zip-bestanden van enkele honderden KB's tot maximaal ongeveer 7MB.
'Ik weet niet wat ik volgende maand ga verdienen'Voor het downloaden van de assets is geen registratie vereist, want dat is volgens de maker een vorm van betaling die de drempel verhoogt. Toch zijn er verschillende manieren waarop gebruikers Kenney iets terug kunnen geven. In het licentietekstdocument, dat bij iedere assetpack wordt geleverd, vraagt hij vrijblijvend om credit voor zijn werk. "Ontwikkelaars die de assets tof vinden geven vaak credit." Daar kun je echter niet van leven. In het downloadbestand zit ook een link naar zijn Patreon-pagina. "Ik leef van donaties en ik weet niet wat ik volgende maand ga verdienen." Het bestaan als maker van gratis assets is daarmee relatief onzeker.
Het kan ook volledig opensource?
Vooralsnog bestaat de opensourcegame-industrie hoofdzakelijk uit één populaire engine die vooral bekendheid krijgt door sporadische mainstream hits van projecten die in principe commercieel zijn. In die gevallen is een opensource-engine gebruikt om een closedsourcegame te maken, iets wat mag onder de MIT-licentie. Maar het kan nog meer opensource. Binnen de opensourcecommunity wordt aan enkele zeer populaire projecten gewerkt die volledig opensource zijn. Een goed voorbeeld hiervan is de gerenommeerde management- en towerdefensegame Mindustry, ontwikkeld door Anton Kramskoi, die beter bekend is onder zijn gebruikersnaam Anuke.
Hij creëerde in 2017 voor een ontwikkelaarsevenement, een zogenoemde gamejam, de basis voor Mindustry. "Ik had een plek nodig om de broncode van de game op te slaan en ik was bekend met GitHub. Het opensource publiceren van mijn game was in eerste instantie dus vooral een kwestie van gemak." Hij publiceerde ook andere games op dit codeplatform. Gebruikers kunnen de broncode van het platform downloaden en het spel zelf compileren; de code is beschikbaar onder de GNU Public License v3. Intussen zijn er overigens ook executables beschikbaar via onder meer Itch.io en een retailversie via Steam.
Bron: Mindustry / Anuke
Mindustry ging op GitHub een eigen leven leiden. "Over de jaren heen heb ik talloze contributies van vrijwilligers ontvangen; de game zou drastisch anders zijn zonder hen", stelt Anuke. Hij zegt dat de meeste bijdragen kleine veranderingen betreffen, waaronder quality-of-lifeverbeteringen en UI-aanpassingen. Soms komen contributors echter met omvangrijke nieuwe ideeën, waaronder volledige overhauls van bestaande gameplaymechanismen. Toch is de ontwikkeling van de game volgens Anuke niet gedreven door de community: "Uiteindelijk neem ik alle beslissingen en schrijf het merendeel van de code." De enige uitzondering hierop, zo geeft hij toe, zijn de vertalingen van het spel.
Een bijkomend voordeel van de opensourceaard van het spel is volgens de ontwikkelaar de toegankelijkheid voor modders. Als iemand een mod wil ontwikkelen, is diegene niet afhankelijk van documentatie, zo redeneert hij. "Modders kunnen naar de broncode kijken om te achterhalen hoe gamefuncties werken en wat voor de invulling van de mod daaraan veranderd zou moeten worden."
Niet levensvatbaar zonder verkoop
Na enkele jaren van transparante ontwikkeling bracht Anuke zijn game in de herfst van 2019 uit op Steam. Het spel is gratis verkrijgbaar, maar voor gamers die de ontwikkelaar willen steunen, Mindustry in hun Steam-bibliotheek willen hebben of via dat platform multiplayer willen spelen, is er een betaalde versie. Ook gemakzucht speelt volgens de ontwikkelaar een rol. Een gebruiker hoeft de betaalde versie namelijk niet zelf te compileren."Een overweldigend groot deel van alle inkomsten van Mindustry heb ik te danken aan de verkoop via Steam."
De ontwikkelaar maakt er geen geheim van hoe belangrijk de Steam-release voor hem is: "Een overweldigend groot deel van alle inkomsten van Mindustry heb ik te danken aan de verkoop via Steam." Hoewel hij geen exacte bedragen noemt, zou het totaal aan donaties 'niet eens in de buurt van het minimumloon' komen. "Ik kan me niet voorstellen dat een opensourcegame ooit voor een realistisch inkomen zou kunnen zorgen zonder een release op Steam of een vergelijkbaar platform."
Gevaren van opensource
Hij stipt ook enkele potentiële nadelen aan van het opensource uitbrengen van een videogame: "Het is moeilijker om code te auditen dan het zelf te schrijven. Soms glipt er een probleem in bijgedragen code door de controle. Als een functie breekt, kan het soms lang duren om de oorzaak in andermans code te vinden." In het verlengde daarvan zegt hij dat het soms sneller is om iets zelf te schrijven dan code van een contributor aan een game toe te voegen.
"Het is moeilijker om code te auditen dan het zelf te schrijven."Een tweede probleem met het publiceren van een opensourcegame is eventueel misbruik van de gamebestanden door derden. In principe kan iedereen de broncode downloaden en zelf een verdienmodel zoals advertenties toevoegen of de game onder een andere naam op een ander platform verkopen. Dit is een van de inherente problemen van opensourcesoftware met relatief restrictieloze licenties, maar dit weerhoudt ontwikkelaars zoals Anuke er niet van om hun games gratis beschikbaar te maken.
Tegelijkertijd is er een andere stroming binnen de opensourcesubcultuur, namelijk die van opensourceclones van bestaande closedsourcegames. Voorbeelden zijn de moderne Escape Velocity-clone Endless Sky, de opensourceversies van Transport Tycoon Deluxe en RollerCoaster Tycoon 2 in de vorm van respectievelijk OpenTTD en OpenRCT2, de recreatie van het oude RuneScape onder de naam RuneLite of de Minecraft-kopie Craft.
Conclusie: een stroming in kinderschoenen
De wereld van opensourcegameontwikkeling bevindt zich nog in de kinderschoenen. Hoewel er tientallen engines met inzichtelijke broncode beschikbaar zijn, is het aantal commercieel verkrijgbare games dat daarmee is gemaakt nog zeer beperkt. Maar er is wel ontwikkeling te zien binnen deze niche. De opensource-engine Godot drijft enkele intussen ontzettend populaire indietitels aan, terwijl donaties aan de non-profitorganisatie zijn verdubbeld.
Dat een kleine groep ontwikkelaars, vooral indiedevs, overstapt op opensource-engines als Godot heeft deels te maken met een belangrijke ontwikkeling in de game-industrie: controverse rondom licentievoorwaarden. Unity wordt daarbij als voornaamste boosdoener aangewezen. Het bedrijf paste zijn prijsbeleid aan, waardoor veel ontwikkelaars werden geconfronteerd met hun afhankelijkheid van grote bedrijven en de potentieel negatieve gevolgen hiervan.
Opensource-engines als volledig alternatief zien voor de uitgebreidere propriëtaire engines vraagt om nuance. Godot, vermoedelijk de best uitgewerkte versie van een opensource-engine op de markt, heeft minder ondersteuning en features dan de grotere engines van derden. Veel onderdelen van de workflow bij het gebruik van een opensource-engine zijn daarnaast gebaseerd op de bijdragen van vrijwilligers. Deze contributors zorgen vaak voor nieuwe functies, ondersteuning, tutorials, assets en andere gameonderdelen. Daarbij zijn makers van opensourceprojecten vaak volledig afhankelijk van donaties om voort te bestaan. Dat maakt de ontwikkelingen van deze projecten overwegend door de community gedreven, maar ook van die groep afhankelijk.
Ondanks deze uitdagingen kan het nog extremer. Een kleine stroming binnen de opensourcegame-industrie opensourcet hun games volledig. Niet alleen de gebruikte engine en eventueel gameonderdelen zijn opensource, maar het volledige project, inclusief broncode, is gratis verkrijgbaar. Veelal gaat het dan om klonen van een oorspronkelijk als closedsource uitgebrachte game, maar er zijn commerciële uitzonderingen die zowel gratis als via gevestigde gameplatforms worden uitgebracht.
Kortom, ontwikkelaars moeten vooralsnog vooral een opensourcemindset als drijfveer gebruiken om, ondanks enkele unieke uitdagingen, hun projecten openbaar aan te bieden. De opensourceontwikkelaar is voorlopig nog in de minderheid binnen de game-industrie. Dat lijkt langzaam te veranderen, maar de afhankelijkheid van vrijwilligers en donaties, in combinatie met een beperkter scala aan features in vergelijking met propriëtaire engines, maakt opensourcegame-ontwikkeling tot dusver vooral een principiële keuze.
Allereerst, leuk om te zien dat Tweakers ook hier aandacht aan besteed!
Zelf ben ik al twee jaar bezig met een nieuwe race simulatie op basis van Godot, die je ook even kort kunt terugzien in de 2023 Showreel en ik heb aan het begin van dit kalenderjaar op een event ook mensen zelf al even laten rijden ermee.
Daarvoor heb ik in 2016 Studio 397 opgericht voor de doorontwikkeling van rFactor 2 en ben daarnaast betrokken geweest bij Automobilista, rFactor, The Grand Tour Game en NASCAR 21 Ignition, waarbij ik gewerkt heb met "eigen" game engines, Lumberyard, Unreal Engine en Unity.
Het artikel noemt al een aantal voor- en nadelen van een open source engine, maar wat voor mij uiteindelijk de doorslag gegeven heeft is juist het feit dat Godot niet gigantisch groot en breed is in vergelijking met commerciele alternatieven. Dit heeft voordelen tijdens de dagelijkse ontwikkeling, de je kunt heel snel code schrijven, bouwen en testen. Het heeft ook voordelen als je een keer iets wilt aanpassen, want niet alleen is de sourcecode van de engine beschikbaar en vrij aan te passen, het is ook nog steeds te begrijpen allemaal.
Het feit dat andere engines veel meer features hebben, betekent niet automatisch dat ze daardoor beter zijn! Als je die features niet nodig hebt in je game, dan voegen ze niks toe. Ik krijg wel eens het idee dat Unreal Engine en Unity vooral geschikt zijn voor AAA studios met honderden developers die ook daadwerkelijk alle aspecten ervan kunnen en willen benutten. In elk geval voor het genre waar ik mee bezig ben, zelfs als je een team van 30-50 man hebt, is een game engine vooral een manier om een graphics en sound engine en wat game scripting voor elkaar te krijgen. De vehicle physics moet je toch zelf doen en waarschijnlijk geldt dat ook voor de hele netwerk communicatie voor on-line races. En dan is Godot een prima keuze!
Het feit dat andere engines veel meer features hebben, betekent niet automatisch dat ze daardoor beter zijn! Als je die features niet nodig hebt in je game, dan voegen ze niks toe. Ik krijg wel eens het idee dat Unreal Engine en Unity vooral geschikt zijn voor AAA studios met honderden developers die ook daadwerkelijk alle aspecten ervan kunnen en willen benutten.
Ik denk dat een racing sim net te uitzonderlijk is om veel van die standaardfunctionaliteit gebruik te maken (je ziet de meeste sims dan ook geen off-the-shelf engine gebruiken), maar voor andere producties zou het je verbazen hoeveel er soms kan ontbreken in een wat meer basale engine.
Voor een third person game heb je bijvoorbeeld een behoorlijk robuust animatiesysteem nodig om aan hedendaagse eisen te voldoen. Ik vind die van Unity al wat basaal vergeleken met UE5.
Je hoeft in ieder geval geen AAA productie te zijn om baat te hebben bij veel features. Veel is ook gewoon nice-to-have. En gebruik je het niet - dan heb je er ook geen last van.
[Reactie gewijzigd door Wolfos op 22 juli 2024 13:28]
Een racing sim is zeker een voorbeeld waar je geen gebruik kan maken van de meegeleverde physics engine in een game engine. Voor veel andere games is dat geen probleem. Op de "eigen" physics engine van Godot is zeker nog wel het e.e.a. aan te merken (2D en 3D) maar wat dan wel weer heel interessant is, is dat je er eenvoudig een andere physics engine in kunt pluggen. De "Jolt" physics engine (bekend uit de Horizon games) is een voorbeeld van een engine die als plugin ter vervanging van de standaard engine te gebruiken is.
Qua animatie systeem heb je wel een punt, maar ook daar zie ik games (in ontwikkeling met Godot) die dat aardig onder controle hebben. Neem bijvoorbeeld Road to Vostok, die toevallig net een devlog hebben gepubliceerd dat onder andere daarover gaat.
Tot slot, "gebruik je het niet dan heb je er ook geen last van" behoeft wel wat nuance, want soms is dat niet het geval. Natuurlijk, als je 't niet gebruikt in je game, heb je er geen last van, maar het feit dat de ontwikkelaar van de engine er wel support voor moet blijven leveren is iets waar jij uiteindelijk ook gewoon voor betaalt. Niet voor niets zie je de verdienmodellen van Unity en Unreal Engine langzaam veranderen. Die teams moeten ook betaald worden. En een ander voorbeeld is als je zelf in de engine iets wilt aanpassen, dan kom je al die andere code wel tegen en misschien zijn er onder water toch meer raakvlakken met stukken die je niet gebruikt, maar wel moet snappen wil je iets kunnen aanpassen.
Dus het klopt dat Godot not the way to go is voor een grafisch mooi spel omdat deze logica allemaal zelf geimplementeerd moet worden ? En dat is juist gemakkelijker gemaakt bij de andere engines ?
Je kunt zeker grafisch mooie games maken met Godot. Hoewel engines zichzelf veelal adverteren met allerlei grafische features is dit wellicht nog wel het minst belangrijke onderdeel. Dezelfde assets zien er in verschillende engines niet heel anders uit.
Helemaal mee eens @Wolfos een mooie game begint bij goede assets, die maken echt het verschil, en zoals je zegt, elke moderne engine kan die dan wel netjes renderen (met de juiste belichting, PBR materialen, HDR/tonemapper, etc.).
Hoewel engines zichzelf veelal adverteren met allerlei grafische features is dit wellicht nog wel het minst belangrijke onderdeel.
Ik denk dat dat erg afhangt wat je als ontwikkelaar / speler ambieert. Godot kan vanzelfsprekend niet tippen aan de grafische pracht die (onder andere) Unreal biedt. Of je dat erg vindt is natuurlijk een tweede.
Ik denk dat je met Godot prima een grafisch mooi spel kunt maken. De Vulkan (en DX12) graphics engines ondersteunen de basis features die je nodig hebt daarvoor. Natuurlijk zijn er wel specifieke dingen die je zelf nog moet doen, maar die kan ik voor andere engines ook bedenken.
Een concreet voorbeeld is Assetto Corsa Competizione, een race simulatie gebouwd op Unreal Engine. Bij race simulaties is het gebruikelijk om ondersteuning te hebben voor zowel VR als ook "triple screens". Die laatste zijn 3 schermen, waarbij de zij-schermen onder een hoek staan. Die moeten dus ook als aparte viewports gerenderd worden. Unreal Engine heeft daar totaal geen support voor en als je dat wilt, zul je zelf de sourcecode moeten aanpassen, of Epic engineers inhuren om dat voor je te doen.
Als ik die showreel zie dan hebben ze toch nog heel veel werk aan de physics engine. Het ziet er allemaal wat uit als spellen van twintig jaar geleden ook. Maar er lijken wel leuke indie games tussen te zitten.
Er is een extensie die de Jolt physics engine in godot integreert, welk echt een stuk beter werkt dan de native versie: https://github.com/godot-jolt/godot-jolt
Ik meende ook ergens gelezen te hebben dat er sprake is om Jolt volledig te integreren in mainstream godot, maar ik kan hier niet snel een artikel hier van vinden. In iedergeval, godot is nog aardig in ontwikkeling
De physicsengine is inderdaad een ding waar nog volop aan gesleuteld wordt. Je hebt zoals riemer1990 zegt extensies om engines als Jolt in Godot te integreren en de Foundation werkt eraan om dit de standaard engine te maken (geloof ik, don't quote me on that). Eerder werd Bullet gebruikt.
Maar zoals Coppola uitlegt, het is heel lastig voor zo'n klein team om een geavanceerde functie als physics engines te ontwikkelen en onderhouden. En de meeste experts op dit gebied zijn al in dienst bij andere bedrijven.
Dit artikel prikkelt mij een beetje, omdat de term 'open-source' niet geheel correct wordt gebruikt. Engines zoals de Unreal Engine en Source Engine (overduidelijk de oude variant, 2013) zijn open-source in de zin dat je de broncode kunt bekijken, maar het daadwerkelijk uitbrengen van producten met deze engines is niet geheel gratis; denk aan royalties, licenties, etc.
Daarnaast zijn er, zoals @Estel aangaf, genoeg spellen die, hoewel ze tussen Indie en AAA in zitten, volledig open-source en zonder royalties zijn uitgebracht. Denk bijvoorbeeld aan spellen zoals Stardew Valley, Fez, Bastion, Celeste gemaakt met Monogame. Verder zijn er ook spellen zoals Getting Over It With Bennett Foddy, Halls of Torment en het in het artikel genoemde Buckshot Roulette die met Godot zijn gemaakt. Een gecureerde lijst van dergelijke spellen op Steam kun je bijvoorbeeld hier vinden.
Tot slot kijken steeds meer opleidingen (zoals Creative Media en Game Technologies op verschillende locaties) naar Godot als een optie. De overstap naar Godot en weg van Unity zal op den duur plaatsvinden, mits Unity of Unreal hun businessmodel niet aanpassen. Daarom ben ik het ook niet geheel eens met de conclusie die de auteur schetst, ik verwacht juist dat in de toekomende jaren het gebruik van Godot bij kersverse, professionele, developers zal gaan toenemen.
[Reactie gewijzigd door Doctor Waffles op 22 juli 2024 13:28]
Het lijkt er meer op dat jij de term niet helemaal correct gebruikt en wat terminologie door elkaar haalt. Open source heeft een specifiekere betekenis dan alleen maar de bron code inzichtelijk hebben (source available).
Er is dan ook echt een verschil tussen code inzichtelijk maken en code beschikbaar stellen onder een open source licentie.
Dit is niet alleen een theoretisch verschil, wat je eigenlijk zelf al aanhaalt
maar het daadwerkelijk uitbrengen van producten met deze engines is niet geheel gratis; denk aan royalties, licenties, etc.
Als het echt een open source licentie heeft dan zou hier geen sprake van zijn. Open source licenties kunnen wel met beperkingen komen. Zou kan het zijn dat de licentie afdwingt dat producten die je maakt op basis van de code ook open source zijn. Of dat aanpassingen die je doet aan de open source code openbaar moeten zijn. Maar er zijn ook licenties die alleen maar vereisen dat je ergens vermeld dat je gebruik hebt gemaakt van de open source code. Dit is het geval bij zowel Monogame als Godot.
Het lijstje van games die je aanhaalt, is dan ook niet zonder meer open source.
Voor Stardew Valley bijvoorbeeld, is zover ik weet de bron code niet beschikbaar onder een open source licentie.
Open source heeft een specifiekere betekenis dan alleen maar de bron code inzichtelijk hebben (source available).
Daar is (helaas) discussie over, vanaf de eerste keer dat de term "open source" werd gebruikt. Vroeger hadden we het over Vrije Software. Sommigen waren bang dat bedrijven zouden worden afgeschrikt door termen als "vrijheid" en dat "Free" in het Engels ook gratis betekent. Toen heeft iemand bedacht om de term "open source" als synoniem te gebruiken in de zakelijke wereld. De term is aangeslagen en al door sommigen snel uitgekleed tot niet meer dan het minimum: "het is mogelijk om de source te zien".
Toen Free Software/Open Source bekendheid begon te krijgen hebben tal van bedrijven nog geprobeerd mee te liften door hun eigen "open source" licenties uit te brengen, waarvan sommigen totaal niks meer te maken hadden met idealen van de Vrije Software beweging.
Tegenwoordig is dat weer een beetje verdwenen en wordt de term weer vooral gebruikt voor licenties die gebruiker alle vrijheid geven om de broncode te zien en aan te passen.
Zelf gebruik ik de term "Open Source" alleen als ik denk dat het nodig is om mijn boodschap over te brengen, of als is ik echt niet meer bedoel dan toegang tot de broncode.
Ik heb het zo veel mogelijk over "Vrije Software". Het "vrijheid" aspect is voor mij de kern waar het echt om gaat, broncode inzien is daartoe een middel, geen doel op zich.
Broncode alleen is echter maar beperkt nuttig, zelfs als je alle rechten er bij hebt.
Je zal bijvoorbeeld ook een compiler/interpreter nodig hebben om die broncode om te zetten in een werkend programma. Dat is echter nog steeds niet genoeg als je geen mogelijheid hebt om je die binary te installeren op je computer/apparaat. Dan is er nog dat moderne software nooit echt "compleet" is maar gebruik maakt van resources van het OS of de computer zoals voorgeinstalleerde lettertypes. Zelfs als je alle stukken hebt dan zal je er in praktijk niet uitkomen zonder goede documentatie, die heb je dus ook nodig.
Richard Stallman van Free Software Foundation heeft dat inderdtijd goed voorzien en z'n licentie heel breed gemaakt om dat soort aspecten op te vangen. De kale "open source" interpretatie mist dat hele stuk.
De filosofie staat nog altijd stevig overreind en de licentie heeft verbazend veel van de moderne softwaremarkt voorzien, maar er beginnen wel scheuren zichtbaar te worden. Het GPL werkt namelijk niet goed in situaties waarin software draait op computers van anderen, zoals zo ongeveer alles op internet en in de cloud. Je kan (bij wijze van spreke) een programma van 1 regel lang maken dat niks anders doet dan verbinding maken met een of andere server en de resultaten laten zien. Aan die ene regel code heb je niks als je wil weten welke algoritmes je leven aansturen.
Ook daarom blijf ik het over "Vrije Software" hebben. Het gaat mij om de filosofie dat je als mens moet kunnen weten hoe de apparaten en software om je heen werken en de vrijheid moet hebben om die naar eigen inzicht aan te passen.
Baas op eigen apparaat.
Baas over eigen data.
Baas over eigen algoritmes.
Ik, niet een bedrijf dat mijn eigen data tegen me gebruikt om me via advertenties geld af te troggelen. Geen bedrijf dat mijn eigen OS tegen me gebruikt om advertenties te tonen. Geen bedrijf dat openlijk surveilliance methodes gebruikt waar 30 jaar geleden geen geheime dienst van zou durven dromen. Geen bedrijf dat menselijke relaties en emoties ziet als iets om ruzie in te stoken om meer geld te verdienen met clicks. Geen bedrijf dat zichzelf aanstelt als de poortwachter van alle software die ik op mijn apparaat mag draaien. Geen bedrijf dat zichzelf meer rechten geeft op mijn apparaten en over mijn data dan ik zelf heb en mij behandelt als aanvaller die moet worden buitengesloten van z'n eigen apparaat. Ik.
Dat gaat allemaal verder dan alleen broncode, licenties en software. Toegang tot de brocode is leuk maar niet echt relevant voor de genoemde problemen. De Vrije Software filosofie denkt groter en kan de genoemde problemen in iedere geval benoemen en plaatsen in het denkraam door te kijken naar doelen en belangen van de gebruiker.
De gebruiker op de eerste plaats zetten is het allerbelangrijkste idee van de Free Software filosofie. De gebruiker en dus niet de programmeur, verkoper, hardwarefabrikant, dienstverlener, streamer, overheid, aandeelhouders, geld, etc...
Alle regels en voorscrhiften van de Free Software Filosofie kun je daar uit afleiden.
Dat zelfde principe kun je ook volgen op gebieden waar de huidige licenties niet goed werken, bv omdat er geen traditionele source code is die stand-alone kan draaien op een manier waar je als eindgebruiker iets mee kan. Uit het doel kun je de middelen afleiden of aangeven waar problemen zijn.
Daarom is de Free Software Filosofie nog altijd heel belangrijk en relevant.
Ik ken ook geen enkele andere IT-beweging die zo diep nadenkt over fundamentele vraagstukken, sociale kwesties als burgerrechten, in plaats van te focussen op pragmatisme. De right-to-repair-beweging en piratenpartijen komen het dichtste bij en je ziet daar dus ook veel van het zelfde gedachtegoed terugkomen.
Excuses voor de lange tekst, maar in deze context leek het me belangrijk om hier even wat dieper op in te gaan.
[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 13:28]
... dat is dus heel wat meer dan het enkel beschikbaar maken van de broncode. Wel legt open-source zoals OSI het bedoelt minder nadruk op vrijheid en meer nadruk op open-source als softwareontwikkelingsmechanisme waarin bijvoorbeeld concurrenten met elkaar kunnen samen werken op een manier dat ze elkaar kunnen vertrouwen.
Wat jij correct vind is niet noodzakelijk correct
Open-source is in basis precies dat, beschikbaarheid van de code om in te zien. Wat je er meer mee mag hangt volledig af van de licentie. Daarom zijn er ook zo veel licenties en is er zelfs een organisatie die licenties bestudeerd en bepaald of ze wel of niet als open beschouwd mogen worden.
Open is een term ter discussie en persoonlijk vind ik het kunnen inzien van de code voldoende. De rest is aan de auteur. Open hoeft niet gratis te jatten of gebruiken te zijn.
Het staat je vrij om een tegendraads petje op te zetten als je in zo'n bui bent. Maar in de basis wordt open source in het merendeel van de software wereld in een vrij specifieke context gebruikt met een specifieke betekenis.
Dat je daar persoonlijk wat anders van vindt, verandert hier niet zo veel aan. Wat je zelf ook al erkent gezien je opmerking over organisaties en licenties
Ik zie dat je moeite hebt om te herkennen dat jou mening ook maar een mening is. En ik denk dat jij alleen maar naar dat deel van die wereld kijkt die in jou straatje past. Zoveel ontwikkelaars in die wereld, zoveel meningen over wat open source wel of niet is. Jou aanname over wat de rest denkt is niet meer dan dat, een aanname. Omdat je graag met Engelse worden gooit, heb ik er ook 1 voor jou: "overreach"
Jou aanname over wat de rest denkt is niet meer dan dat, een aanname.
Met merendeel bedoel ik precies dat, de meerderheid, niet 100%. Dit is niet alleen gebaseerd op mijn mening, maar ook ervaring ondersteund door de omschrijving op wikipedia, IBM, RedHat, HPE, GitHub. Je hebt gelijk dat het allebei meningen zijn, sommige meningen komen echter met wat meer onderbouwing dan andere meningen.
Dat jij het persoonlijk al open genoeg vindt als je de code kan bekijken (zonder er iets mee te mogen) is prima. Dat neemt niet weg dat het toch echt zo is dat over het algemeen de definitie echt iets specifieker is.
[Reactie gewijzigd door Creesch op 22 juli 2024 13:28]
De overstap naar Godot en weg van Unity zal op den duur plaatsvinden, mits Unity of Unreal hun businessmodel niet aanpassen.
Je vergeet dat het geheel gratis is om het op "educatieve" wijzen te gebruiken voor onderwijs en studenten. De nieuwe business model veranderd daar volgens mij niks aan.
Opleidingen moeten juist engines gebruiken die in de branche het meest gebruikt worden vind ik. Dan heb je ieder geval de basis die de meeste werkgevers vragen.
Ja en nee, het klopt dat momenteel Unity en Unreal het vaakst voorkomen. Echter, in Nederland hebben we veel kleine game-studio's die met minimale investeringen werken, als ze die überhaupt al krijgen.
Aangezien Unity en Unreal duurder zijn geworden, verwacht ik dat nieuwe startups of kleine bedrijven eerder voor Godot zullen kiezen, omdat dit geen kosten met zich meebrengt.
Dit is dus ook een dilemma voor hogescholen, en er is niet een eenvoudig antwoord op te geven. Unity en Unreal worden momenteel het meest gebruikt door Nederlandse studio's, maar nieuwe, kersverse studio's zullen, na mijn verwachting, eerder voor Godot kiezen en zo mogelijk de toekomst bepalen.
Aangezien Unity en Unreal duurder zijn geworden, verwacht ik
Unreal is goedkoop omdat het een percentage vraagt en alleen wanneer je meer dan 1 miljoen dollar/euro winst maakt volgens mij. Dat is perfect voor kleine Indie studios.
Scholen zouden helemaal niet op een specifieke engine of tool moeten aansturen, maar alleen het resultaat moeten controleren dat de studenten leveren.
Studenten zouden zo breed mogelijk scala aan tools moeten kennen of beter gezegd begrijpen. De ene tool is niet fundamenteel anders dan de andere als je goed begrijpt wat je aan het doen bent. physics == physicks in welke taal je het ook uitdrukt.
Er ligt te veel nadruk in het onderwijs op "monkey see, monkey do". Je hebt weinig tot niets aan dat soort mensen als je innovatief wil zijn. Mensen moeten getraind worden in voor zichzelf denken en begrip en keuzes maken. Niet op trucjes.
Scholen zouden helemaal niet op een specifieke engine of tool moeten aansturen, maar alleen het resultaat moeten controleren dat de studenten leveren.
Studenten zouden zo breed mogelijk scala aan tools moeten kennen of beter gezegd begrijpen. De ene tool is niet fundamenteel anders dan de andere als je goed begrijpt wat je aan het doen bent. physics == physicks in welke taal je het ook uitdrukt.
Daar heb je gelijk in helaas is het onderwijs te rigide daarvoor. Bijvoorbeeld HBO-ICT heb je een vak zoals web frameworks standaard wordt daar met Vue.js gewerkt waar je uit 5 opdrachten kan kiezen. Iets anders mag je niet gebruikens.
Misschien interessante toevoeging, de reden dat je met Godot niet echt makkelijk voor consoles kan developen, is omdat de libraries etc. voor Playstation en Switch het tekenen van een NDA vereisen en niet zomaar ingezien en gedeeld mogen worden, en dat gaat dus niet met een FOSS licentie.
Nou zijn er wel bedrijven zoals W4Games, lonewolftechnology, etc.. die hier oplossingen voor aanbieden, maar dat is natuurlijk weer extra kosten (vanaf €3000) die ook niet iedereen kan ophoesten.
[Reactie gewijzigd door dakka op 22 juli 2024 13:28]
Dit is een beetje een slap excuus omdat er veel open source libraries zijn die wél strakke console support hebben. MonoGame en FNA bijvoorbeeld.
Hoe dat werkt is dat ze die versies beschikbaar maken op de development forums, of je kunt toegang krijgen wanneer je kunt aantonen dat je geregistreerde developer ben.
Maar even los daarvan - het zou heel mooi zijn als consoles eens af zouden stappen van die achterlijke geheimhouding. Alle NDA info komt lang en breed op het internet. Het zorgt er alleen voor dat open source development lastiger is, en dat ontwikkelaars het vaak als moeilijker zien dan dat het is omdat we niet over specifieke dingen mogen praten.
Ik begrijp dat het onder NDA valt voordat de console uit is, maar zodra die voor het grote publiek beschikbaar is, bestaan er eigenlijk al geen geheimen meer en werkt het alleen maar ontmoedigend voor ontwikkelaars die vragen hebben over het proces en de kosten.
[Reactie gewijzigd door Wolfos op 22 juli 2024 13:28]
Maar Godot maakt gebruik van een MIT licentie, en MonoGame en FNA gebruiken een Microsoft Public Licence, waardoor ze die voorwaarden dus kunnen stellen en zo die support native kunnen maken.
Het wordt in dit artikel gepresenteerd als een nieuwe ontwikkeling, maar dat is het eigenlijk niet. Ik speelde 15-20 jaar geleden al opensource games uit de repositories van Linux distros. Dat waren ook vaak clones van bestaande games. Veel 3d shooters a la Quake, maar ook RTS (Warzone2100, en een tankspel waarvan ik de naam vergeten ben), of het Mario Kart geïnspireerde SuperTuxKart. Er was zelfs al focus op het maken van engines. Het spel Cube was vooral bedoeld als techdemo voor de Cube engine (maar toch best uitgebreid voor een gratis spel). Ik kan iedereen die in dit topic geïnteresseerd is aanraden om eens een Linux distro te installeren en kijken wat er momenteel aan games in de repository zit. Dat is allemaal open source. Het is niet allemaal even goed, maar meestal best vermakelijk.
Plus dat een aantal classics zoals Duke Nukem 3D en Shadow Warrior ook hun code uitgebracht hebben, wat heeft geleid tot de ontwikkeling van betere versies (eduke32, jfduke) met o.a. OpenGL ondersteuning (alhoewel je officieel nog steeds de originele game moet kopen voor de assets).
Het wordt in dit artikel gepresenteerd als een nieuwe ontwikkeling
Ik denk in alle eerlijkheid dat je dan iets te snel een conclusie hebt getrokken en voorbij gaat aan de context van dit artikel. Het bestaan van open source games en daarmee engines is inderdaad niks nieuws. Maar, wat het artikel ook aangeeft zijn er tot dusver niet echt grote spelers uit voortgekomen. Godot is wel degelijk de eerste open source engine die meer mainstream lijkt te worden en breder geadopteerd wordt dan andere projecten.
Dat neemt niet weg dat ik het volledig eens ben met je aanbeveling om eens te kijken wat er allemaal nog meer beschikbaar is in de open source wereld. Want er is inderdaad een rijke geschiedenis aan open source games en engines die Godot vooraf zijn gegaan of nog steeds in ontwikkeling zijn.
[Reactie gewijzigd door Creesch op 22 juli 2024 13:28]
Het gaat hier niet om de games per se die open source zijn maar meer de tooling (in dit geval godot). Weinig games zijn open source omdat je dan zelf zou kunnen builden. Dit hoeft niet (veel) uit te maken (kijk naar bijvoorbeel aseprite, geen game maar wel op steam).
Aan de andere kant zou je ook kunnen stellen dat alle games die werken met three.js of open/webGL e.d. ook gewoon met een open stack werken. Dit gaat puur om devs die niet zelf alles (willen) opbouwen en liever met een game engine werken.
Ik heb ook vorig jaar even met GoDot zitten 'spelen' n.a.v. het gedoe om Unity (waar ik nu alweer 15 jaar mee werk). Opzich was ik niet teleurgesteld in hoe snel je iets hebt draaien. Maar inderdaad zijn er wat 'gebreken' vergeleken met Unity die je uiteindelijk toch weer eerst laten terug gaan. Vooral het draaien in de editor en het debuggen / snel itereren maakte voor mij het verschil.
Overigens vind ik ook dat het ook redelijk asociaal is wat Unity deed (en doet), maar het zal altijd voor ontwikkelaars een afweging zijn of het waard is om over te stappen. Het zelfde geld voor bijvoorbeeld een 3DSMax of Photoshop gebruiker: De tarieven stijgen steeds, op welk moment ga je over naar een open-source alternatief (zoals Blender) en kan deze het zelfde als wat je wellicht al meerdere decennia gebruikt? Tegenwoordig is Blender goed te doen, maar ik denk dat velen hier wel herinneren dat het business model "verkoop van een handleiding" was . Ondertussen kost een Unity licentie bijna 5000 euro/jaar als je wat tools maakt in een grotere organisatie.Een abonnementsmodel is echt de beste cash-cow uitvinding geweest op software gebied wat de industrie had kunnen bedenken.
Overigens zakt de aandelenkoers van Unity praktisch wekelijks sinds december 2023. Benieuwd waar ze binnenkort mee komen aanzetten (o.a. om de aandeelhouders blij te krijgen).
Ja, ik heb er heel wat geprobeert maar ik denk ook al snel "dit kan beter in Unity of Unreal". En als een engine daadwerkelijk betere resultaten oplevert dan zijn die kosten het al snel waard.
Zeker bij 3D engines loop je al snel tegen een blocker aan, en dan mag je het zelf gaan fixen of hopen dat de engine developers je bug belangrijk vinden. Zeker bij open source werken ze vaak liever aan nieuwe features dan bugfixes.
Er zijn anno 2024 tientallen opensourcegame-engines beschikbaar onder verschillende licenties. Toch wordt geen van deze engines in principe gebruikt voor een populaire of op een andere manier significante game.
Ik zou Stardew Valley toch echt wel willen scharen onder populaire games... En die draait toch echt op Monogame welke open source is. Toegegeven, het zijn er niet veel, maar deze stelling is veel te strict.
Monogame is geen engine maar een framework. dat is best een belangrijk verschil. Monogame levert geen UI, maar alleen een skelet aan code om de "saaie" dingen af te handelen, zoals renderen, controller support, geluid etc. Unity en godot zijn echt engines. Je hebt een UI om je spel in te bouwen en een veel meer tools zoals de animator en tilemaps. Het is dus best wel een verschil, vooral omdat het maken/onderhouden van een engine VEEEEL meer werk is.
Het klopt nog wel wat je zegt dat er meer zijn, maar ik durf te zeggen dat 90% van de games nu gemaakt wordt in Unreal en Unity, en daarna komt godot.
[Reactie gewijzigd door hugodijkstra op 22 juli 2024 13:28]
Ik zie wel dat onder indie developers (in ieder geval het groepje wat ik ken) het 'engineless' ontwikkelen steeds populairder wordt; deels omdat er met iedere engine wel 'iets is'. Ik zie inderdaad Monogame/FNA en varianten (maar die lijken af te nemen want de basis is wel gedateerd) maar ook veel met SDL2 (en langzaamaan experimenten met SDL3).
Ja het is maar wat je wil bereiken. Ik heb zelf een 2D platform game lopen rawdoggen eerst in Typescript in de browser en uiteindelijk heb ik het overgezet naar Google Go met een minimalistisch framework eronder.
En toen zat ik uit pure interesse naar een Youtube video te kijken waarin een 2D platformer in Godot gemaakt werd en letterlijk zonder een regel code of script te schrijven deed de game al de helft van wat ik zelf met de hand had gebouwd via honderden regels code. Eventjes in een half uurtje klikken, slepen en pleuren zat er al scrolling, collision detection en basis bewegingen zoals rennen en springen in.
Maar van dat klikken leer je dan weer geen bal over hoe games onder water tikken natuurlijk. Ik leer zelf altijd wel erg graag hoe en waarom het werkt, dat is de halve lol.
Een game + engine maken is idd wel echt iets anders dan een game maken. Exact jou omschrijving is de reden dat ik met SDL zit te spelen. Het is vooral ontdekken en leren hoe bepaalde mechanics in elkaar zitten en dat is leuk. Zou er alleen niet mn geld mee moeten verdienen
De grens tussen framework en engine is wat vaag, maar Monogame is toch echt een framework. Het is dan ook min of meer een opensource implementatie van Microsofts XNA Framework.
Bij een engine heb je meestal een basis om een game op te bouwen en te debuggen, zoals een editor en debugger en bied de engine je mogelijkheden om je spel te scripten op die engine. De programeer taal waarin je het spel bouwt hoeft dan ook niet perse dezelfde te zijn als die waarin de engine gebouwd is.
Bij Unity was er (nog steeds?) UnityScript, een ECMA script implementatie, en uiteraard C#.
Bij Unreal is er support voor meerdere talen, maar de basis is C++ of blueprint.
Bij MonoGame krijg je een bare bones basis game loop, en wat abstracties voor audio, input en zo maar het is een framework wat gebouwd is in C#.
De meest simpele gedachte is dat een framework een begin is wat iemand voor je gemaakt heeft en een engine een complete toolset.
Elke amateur kan nu lekker een game ontwikkelen in hun vrije tijd. Zonder potentiele licentiekosten/royalties als je uiteindelijk iets maakt wat verkoopt. En met professioneel aandoende software. Dit verlaagt de drempel enorm en dit is gewelding wat mij betreft.
Je kunt al decennia games ontwikkelen in je vrije tijd als hobbyist.
Zelfs de grootste commerciële game engines van het moment zijn extreem toegankelijk voor hobbyisten, zelfs Unity. Je moet pas geld betalen bij Unity als je meer dan een ton omzet draait, en bij Epic pas als je game meer dan een miljoen dollar omzet heeft gemaakt. Een luxe probleem voor vrijwel alle hobby game developers op aarde.
Overigens bestaan er sinds jaar en dag legio open source game engines, of games met modding tools, waar je als hobbyist helemaal los mee kan gaan.
Het is nogal een verschil tussen de huidige opensource situatie en mijn vroege (vroege jaren 90) situatie op mijn Amiga.
Toen :
In je eentje alles zelf moeten uitzoeken in Assembly (later C), telkens stuk lopen omdat je niemand anders kent die ook programmeert. De documentatie die ik had was erg beperkt. Dit was als hobby, want zelfs als ik wat zou creeren, dan had ik nog niet geweten hoe dit te publiceren.
Nu :
Erg uitgebreide game engine die het vuile werk grotendeels voor je opknapt zodat je je voornamelijk bezig kunt houden met de logica van de game! Daarnaast een zee aan informatie dankzij internet en een community die je heel graag helpt. Dit zonder start up kosten (buiten je PC) of licenties als je wat verkoopt.
EDIT: Wat Unity betreft. Ze hebben al een keer de grens opgezocht. Je kunt ze nu gewoon niet meer vertrouwen wat dat betreft.
[Reactie gewijzigd door tweaker29789 op 22 juli 2024 13:28]
Juist ja, oh die goede oude tijd dat het nog echt leuk was om zoiets te bouwen. In assembly (PC) de game-engine schrijven met paralax scrolling, joystick en verschillende geluidskaarten ondersteuning als de originele soundblaster, gravis ultrasound, midi. En in Turbo pascal de hele world/sprite/animation editor schrijven. Zucht..
Hah, erg herkenbaar. Voor mij voornamelijk level design en 3D art met XSI Softimage (de Source engine modding tools) eerst, daarna 3Ds Max 7, etc. GameMaker, XNA, etc etc.
Persoonlijk mis ik het onbeholpen aankloten zonder te denken aan het commercialiseren van iets.
Op internet staat er inderdaad een zee van informatie heden ten dagen, maar helaas is een groot gedeelte van de game development / game art / etc content niet goed, en (alleen) gemaakt om geld mee te verdienen. Achja, er is altijd iets te zeuren. Ik was als tiener enorm blij om online iemand gevonden te hebben die ervaring had met 3D animatie software, dat is natuurlijk nu wel een ander verhaal.
Maarja, je moet een 'commerciele' engine als UnrealEngine niet onderschatten, de extra's zoals veel geavanceerdere, en vooral goede, workflows en tooling is van inschatbare waarde, zelfs voor amateurtjes. En dan de gratis Quixel Megascan assets, die zelfs voor films etc gebruikt worden, is ook wel een hele grote pluspunt. Vanaf dat je royalties moet gaan betalen valt het allemaal wel mee, als amateur mag je blij zijn als je dat niveau haalt.
Voor Godot op dat niveau is wat betreft engine en tooling zijn we jaren verder, als het uberhaupt ooit op dat niveau komt.
Maar Godot onderschatten moet je zeker niet doen, maar mijn tijd is kostbaar, dus als ik met die commerciele engines veel sneller klaar ben, en dan ook sneller multiplatform kan releasen, wat tegenwoordig ook erg belangrijk is, dan is me dat die royalties op den duur wel waard.
De kracht van die commercial licentie engines is de content productie piiplijn.
Waar je art team deel productief kan zijn.
In niet commerciële engine opensource werken er team in vrijtijd aan dan is zo een engine beperkter. Waar grote game engine groot vast team die volgens werk week werken.
Grote studio of publishers hebben hun eigen inhouse game engine die hebben vaak ook goede en uitgewerkte tooling.
Naast inhouse kan je het raw houden en bugs . Commercial licenceerbaar lever je game engine en editor als eind product op voor devs.
Juist voor een team dat in de vrije tijd werkt is fatsoenlijke tooling zeer belangrijk, immers wil je niet onnodig vrije tijd kwijt raken aan alles moeilijk moeten doen.
RuneLite is niet een recreatie van het oude RuneScape, het is een client voor OldSchool RuneScape wat een officieel gehoste recreatie en continuatie is van het oude RuneScape. (Eind pagina 5)
[Reactie gewijzigd door AlisAnon op 22 juli 2024 13:28]
Oh maar dat is een big deal! Zijn tutorials zijn het startpunt van menig (Unity) game ontwikkelaar, geweldig dat hij nu Godot tutorials maakt! Hij was volledig gestopt met zijn kanaal een paar jaar terug, blij om te zien dat hij terug is!
/i/2006811944.webp?f=imagegallery)
:strip_exif()/i/2006811954.jpeg?f=imagenormal)
:strip_exif()/i/2006811940.jpeg?f=imagenormal)
:strip_icc():strip_exif()/i/2006836020.jpeg?f=fpa_thumb)
:strip_exif()/i/2004894166.jpeg?f=fpa)
/i/2005660672.png?f=fpa)
/i/2006079680.png?f=fpa)
:strip_exif()/i/2005279580.jpeg?f=fpa)
/i/2005083998.png?f=fpa)
:strip_exif()/i/2004824274.jpeg?f=fpa)
/i/2000868224.png?f=fpa)
:strip_exif()/i/1089840299.jpg?f=fpa)
/u/385219/crop61781417d0d80_cropped.png?f=community){kind=small}
/u/381607/have%2520a%2520nice%2520day%2520-%2520small.png?f=community){kind=small}
:strip_icc():strip_exif()/u/338167/Spiralboxes_60x60.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/21712/crop668d500bcc980_cropped.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/1620490/crop61fe9f1db1033_cropped.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/497245/crop668cea7ea1a5f_cropped.jpg?f=community){kind=small}
/u/48718/crop619e5ed546e66_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/79614/Family-Guy-Victory-is-Ours.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/789283/crop65b0dfe4af024_cropped.jpg?f=community){kind=small}
/u/152942/crop687206d7bca78.png?f=community){kind=small}
:strip_exif()/u/375629/faviconLogo.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/57655/SuperTeamLogo.jpg?f=community){kind=small}
/u/46983/multitasking.png?f=community){kind=small}
/u/407251/crop5dbc1006845b8_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/61340/125281113_256.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/122141/ic.tweakimg.net2.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/522151/crop5e877227df17a_cropped.jpeg?f=community){kind=small}