Spil Games gaat mobiele spellen bouwen met html 5

Spil Games gaat spelletjes voor smartphones maken die vanuit de browser worden gespeeld. De gamemaker gebruikt hiervoor html5, wat zijn spelletjessites geschikt moet maken voor de smartphonebesturingssystemen van Google en Apple.

Spil GamesGebruikers van een telefoon die beschikt over een browser met html5-compatibiliteit kunnen naar de websites van Spil Games surfen en daar games spelen, zo maakte de softwaremaker bekend. Volgens het Nederlandse bedrijf zijn de spelletjes op zijn websites geschikt voor touchscreen-apparaten. Wie met zijn smartphone of tablet een website van Spil Games bezoekt, wordt automatisch naar de mobiele versie doorgestuurd. Verder blijven de sites ook gewoon op de pc te gebruiken.

Spil Games is eigenaar van gameswebsites zoals spelletjes.nl en spel.nl, waar verscheidene kleine games kunnen worden gespeeld. In totaal zijn er 41 sites, die volgens de softwaremaker 130 miljoen unieke bezoekers per maand trekken.

Door middel van een wedstrijd wil Spil Games ontwikkelaars aansporen om html5-games te maken. De softwaremaker heeft een totaalbedrag van 50.000 dollar beschikbaar gesteld voor de beste html5-spelletjes. Volgens Spil Games worden de beste games op zijn gamewebsites geplaatst.

Naast iOS van Apple en Googles Android heeft versie 6 van het BlackBerry-OS ook ondersteuning voor html5. De smartphonebesturingssystemen maken gebruik van de webkit-engine voor hun browsers.

Door RoD

Forum Admin Mobile & FP PowerMod

01-09-2010 • 08:54

49

Reacties (49)

49
48
36
2
0
4
Wijzig sortering
Er zitten nog een hoop haken en ogen aan HTML5/Javascript voor online games. Om een spelletje succesvol te maken is het de bedoeling dat het ding viral gaat en op andere websites beland. Met Flash is dat makkelijk, het is maar 1 file. Bij HTML5 heb je te maken met honderden assets, dat is veel lastiger door andere sites over te nemen.

Hierdoor is ook de bescherming van intellectueel en creatief eigendom nogal beperkt. Alle muziek en afbeeldingen zijn met een druk op de knop door iemand anders te hergebruiken. Ook het aanpassen van logo’s, links en credits in de game is een piece of cake. Flash bied hiervoor ook geen perfecte oplossing maar de drempel is in ieder geval een heel stuk hoger.

Daarnaast zal de game in een omgeving moeten draaien waarbij de site waarin de game staat niet wordt beïnvloed. Denk aan duplicate function defenities, duplicate element id’s, etc. Ik weet niet of HTML hier mogelijkheden voor heeft maar ik denk dat er al gauw een iframe nodig is.

Voor een site waar alleen zelf geproduceerde spellen op staan zijn er met HTML5 wel mogelijkheden, echter het is nog niet klaar voor de “klassieke” game portals.
Ik zou zeggen verdiep je eens in Bookmarklets. Dit gaat eigenlijk nog een stap verder dan includen zoals met een Flash filmpje, hier kun je, door een bookmark te openen, bepaalde (Javascript-based) functionaliteit aan je website toevoegen

Een goed voorbeeld hiervan is Firebug Lite. Hiermee kun je een Firebug-achtige development console openen in een willekeurige browser door een bookmark aan te klikken. De javascript laadt zelf de plaatjes, CSS en HTML in die nodig zijn om het console venster weer te geven.

Mijn punt is dat het, mits daar enige moeite voor wordt gedaan, echt niet lastiger hoeft te zijn om een 'viral' HTML5 game te includen op een site dan een Flash filmpje.
Ik zat je verhaal te lezen en gelijk schoot "iframe" bij mij al in mijn hoofd. Al zouden we juist van dat soort dingen af moeten, maar volgens mij zijn die problemen die je noemt alleen op te lossen met een iframe.

Ik denk wel dat je een groot deel van je code kan beschermen door veel door een serverside language te doen. PHP dat Javascript genereert bijvoorbeeld. Dan nog kan je veel dingen makkelijk stelen, maar je kan het moeilijker maken.
Ik denk dat dit vooral effect zal hebben op AndroidMarker en de AppStore. Als je straks via het internet spelletjes kunt spelen is het niet meer nodig om ze te kopen en zullen de inkomsten van de spelletjes afdelingen misschien wel eens gaan dalen bij Google en Apple.

Het is natuurlijk zo dat je een spel uitgebreider en mooier kan maken als je deze installeert en echt op de telefoon draait. De meeste mensen spelen echter maar eventjes een spelletje om de tijd te doden. Waardoor ze straks waarschijnlijk genoeg hebben aan de gratis / online spelletjes.
Cool! Ben benieuwd of dat op m'n iPad werkt. Zou wel veel geld schelen in de AppStore :)
I rest my case.

[Reactie gewijzigd door WoBaDijk op 28 juli 2024 01:12]

Als ik een spelontwikkelaar was zou ik het echter op twee manieren doen - een 'gratis' versie op het internet (met evt. beperkte functionaliteit) en een 'dedicated' versie voor de verschillende mobiele platformen. Een soort van embedded browser maken die aan de server vertelt dat er voor het spel betaald is zou je lijkt me redelijk snel kunnen ontwikkelen voor alle bekende telefoon OSen.
jouw hele case is gebaseerd op apple's fundamentele idee: apps zouden webbased moeten zijn, ze waren niet op zoek om een enorme appstore te maken.
In de Android market zijn er een hoop gratis spellen. Net als er op internet gratis spellen zijn. Maar wie gaat er nou een mooi gratis spel ontwikkelen als je er ook voor betaald kan krijgen.
Het voordeel van html5 spelletjes is dat je ze niet voor iPhone en Android opnieuw hoeft te schrijven en dus sneller klaar bent met ontwikkelen.
Maar er wordt straks nog steeds geld gevraagd voor ontwikkelde games. Hoe ze het doen veranderd misschien, maar dit is geen concurrent voor de betaalde apps in de Android Market of Appstore.
Je kunt met HTML5 geen spellen maken. Wel kan dat met HTML (versie maakt niet uit) i.c.m. javascript, voldoende CSS en evt. canvas.
Dus Spil Games zou aan een taak beginnen die ze, volgens jou, nooit kunnen uitvoeren? Ik denk dat een bedrijf wel weet waar ze aan beginnen vooraleer ze dit bericht de wereld insturen.
Kan je ons ook even meedelen waarom je geen games in html-5 zou kunnen maken?
Hij heeft wel een punt. Met alleen HTML5 kan je geen games maken, maar voeg je er wat javascript aan toe in samenwerking met een canvas element, dan kan dit wel ;)
Maar canvas is alleen beschikbaar in HTML5, tenzij je javascript gebruikt, maar dat vergt te veel van de client. Doordat canvas standaard in HTML5 zit, is het veel meer geoptimaliseerd.
Canvas kan ook bestaan in XHTML 1.x, en javascript is zelfs een vereiste voor canvas, gezien je met javascript dingen tekent. Alleen SVG kan statische vectorplaatjes tonen (en dat kan overigens ook in XHTML 1.x bestaan)
Javascript wordt in HTML5 echt gezien als onderdeel van het geheel. Veel javascript zaken zul je verplicht moeten implementeren als browser maker anders mag je het geen HTML5 noemen. Hij mist dus eigenlijk juist een beetje het punt...
Mag niet van wie? Moet je es kijken wat voor fundamentele regels de browsers ongelofelijk aan hun laars lappen (quirksmode kan je er alles over vertellen, dat is niet mijn taak) dus wat let de browsermakers om dat voort te zetten?

Daarnaast als Javascript een onderdeel van het geheel is, waarom wordt er in de HTML5-standaard dan kennelijk ingestemd met ancient javascript parsers? Toegegeven, Javascript 1.6 is niet heel oud, maar het blijft gebouwd op de antieke ECMAscript 3 basis.
en evt. canvas
En canvas is onderdeel van? Juist: HTML5.

Je hebt strikt gezien wel gelijk, maar HTML5 voegt wel precies die zaken toe die je als spelletjesmaker nodig hebt: Een canvas om op te tekenen, video, audio.

En je hebt het over de combinatie met Javascript en dat is juist iets wat ze in HTML5 heel goed gedaan hebben (of eigenlijk, nog steeds doen, het is nog niet helemaal af): Men ziet Javascript en het Document Object Model echt als een wezenlijk onderdeel van de HTML5 standaard, dus je zult als browser maker die zaken echt goed moeten implementeren anders kun je nooit claimen dat je HTML5 compliant bent. Dat was vroeger anders waardoor er grote verschillen tussen de Javascript implementaties waren. Erg lastig als je een game wilt maken ;)
Het <canvas> element is onderdeel van HTML5, maar deze doet niets. De rendering context welke je via JavaScript kunt aanspreken is een aparte specificatie, deze voor 2D en deze voor WebGL/3D. JavaScript wordt niet eens verplicht door de HTML5 standaard.
Klopt dat Javascript niet verplicht aan(wezig) hoeft te zijn, echter *als* het er is moet het werken volgens de afspraken en HTML5 besteedt hier (als eerste HTML standaard voor zover ik weet) een heel hoofdstuk aan:

HTML5, H6 Web application APIs

Het idee dat je gaat gamen met Javascript uit is natuurlijk onzin dus vind ik een beetje vergezocht.

WebGL is (voor ozver ik weet) nog experimenteel en het feit dat je eigen link naar de Canvas 2D spec gewoon 'html5' in de URL heeft staan zegt imho genoeg :+
Anoniem: 80466 @OddesE1 september 2010 13:28
WebGL is (voor ozver ik weet) nog experimenteel
WebGL is geen W3C standaard.
Je zal dan eerder moeten denken aan een toekomstige 3D Canvas of aan 3D SVG die dan via WebGL of Dirext3D API's ondersteunt zullen worden.
Heel goed, het canvas element zit in HTML5, maar de techniek die het mogelijk maakt om met javascript vectors op een website te tekenen, die we met z'n allen "canvas" noemen, bestaat al heel lang en is uitstekend te gebruiken i.c.m. HTML4 en XHTML 1.x, zonder dat je daarmee invalide code moet produceren.
Leuk meer browser games, en met html5 zullen er meer mogelijkheden zijn om leukere spellen te kunnen maken dan nu het geval was. :)
Ze zijn er al, kijk maar eens naar deze cilindrische tetris
http://www.benjoffe.com/code/games/torus/
Anoniem: 196662 @DJMaze1 september 2010 09:15
Leuk dat zo'n onnozel spel al een volledige core van een core2duo bezig houdt.
Dat is helaas javascript die dat veroorzaakt.
Javascript heeft geen sleep functie zoals vele andere talen dat wel hebben, resultaat:
een script draait altijd 100% cpu totdat het klaar is
Dit komt helemaal niet door de sleep functie.
Javascript zelf is het probleem.
Javascript+HTML5 games werkt gewoon niet zo fantastisch als iedereen wil doen geloven.
Anoniem: 196662 @-=bas=-1 september 2010 13:20
Bingo.

Ik heb nog geen enkel volledig spel gezien dat lage resources vraagt met JS/HTML5. Of zelfs niet beter dan Flash/SL zoals zovelen hier altijd blijven liegen.
Een sudoku spelletje gaat natuurlijk lichter zijn maar dat is dan ook weer met Flash/SL.

Dan moet je ook nog eens rekening houden dat iemand die slechte Flash/SL maakt, dat ook bij JS/HTML5 zal gaan doen.
The next big step is dan ook gewoon Google Go als webbrowser taal uitbrengen. Downloaden + Compileren ( bij Go super snel ) = Geweldige performance.
In een ideale wereld wel. Ik denk dat Google Go geen geslaagd product gaat worden. Ik ben het voornamelijk eens met de auteur van dit artikel

http://java.dzone.com/new...%2Fdotnet+%28.NET+Zone%29
Synchroniseren op sleep is suf. Javascript heeft wel timers. Die moeten dus gebruikt worden.
Sleep wordt gebruikt om andere processen tijd te geven... Niet om te ' syncen'
Dat heeft waarschijnlijk te maken met hoe de game loop van dat spel is geschreven. Het maakt daarvoor niet zoveel uit of het een next-gen 3D shooter is of een pong kloon.
Anoniem: 174951 @DJMaze1 september 2010 09:12
Hmm.. dat heeft ook gelijk een 'lekkerdere feel' dan menig Flash spelletje die ik ken.

Weet iemand waarmee dit soort games gemaakt worden, is daar ook een 'pakket' voor? Of is dit gewoon echt met de hand geprogrammeerd?
Hmm.. dat heeft ook gelijk een 'lekkerdere feel' dan menig Flash spelletje die ik ken.

Weet iemand waarmee dit soort games gemaakt worden, is daar ook een 'pakket' voor? Of is dit gewoon echt met de hand geprogrammeerd?
Ik denk dat het in den beginne nog grotendeels handmatig gedaan wordt - zie bijvoorbeeld de broncode van dat spel. Maar er zullen waarschijnlijk wel spoedig frameworks voor komen - dat was immers ook het geval toen de veele won'dren van AJAX uitgevonden werden, met als resultaat frameworks als JQuery en dergelijke.
Er zijn al wel verschillende frameworks om games te maken, zoals bijvoorbeeld Gamequery. Gamequery is vooral gebasseerd op jquery.

Al verwacht ik inderdaad dat veel games nog echt helemaal zelf geprogrammeerd worden.
Werkt erg fijn idd, het is perfect speelbaar onder Opera op Linux x64 hier, terwijl ik dat met Flash content wel kan vergeten :P
Anoniem: 316357 @DJMaze1 september 2010 09:31
Hij is nu al dood, kan geen verbinding krijgen met de website.
Jammer lijkt me leuk om te zien hoe het gecode is.
Probeer anders even een HTML5-spelletje van Google: Pacman

http://www.google.com/pacman
Als dit goed werkt heeft de App Store inderdaad een probleem.
Wie gaat daar nou nog spelletjes kopen als je ook dolfijn springen kan spelen?
Een Javascript browser game gaat écht niet de performance halen die een native opengl applicatie kan halen. Kortom, zo snel zal die markt echt niet ten onder gaan.
Het zal echter wel een deel van die markt wegsnoepen, hoeveel huismoeders / meisjes spelen niet zo ongeveer uitsluitend webbased flash games ? En als er veel gratis games beschikbaar zijn van een goede kwaliteit zijn consumenten ook minder snel bereid om te betalen voor een native game, daar er toch zat gratis alternatieven zijn (al dan niet exact hetzelfde game-genre). Vergeet niet de dat de meeste mensen niet heel lang zoeken naar exact game X, maar gewoon op zoek zijn naar vluchtig tijdsverdrijf ...
Hoezo zou de App Store een probleem hebben?

Apple heeft zelf aangegeven dat de App Store niet winstgevend is, de gelden die ze verdienen verdwijnen weer in de kosten. Denk juist dat Apple er wel blij mee is, minder belasting op hun eigen netwerken.
Het gaat nog jaren duren voordat er (aansprekende) spelletjes in HTML5 worden gebouwd met de technische mogelijkheden van Flash. Daarvoor zal er eerst een (grafische) ontwikkelomgeving moeten komen vergelijkbaar met Flash Professional.
Ik moet nog zien of het ooit zover komt.
Ik denk dat dat wel meevalt... Ja voor de (vector)graphics heb je gelijk, maar wat betreft de ontwikkelomgeving (coding) doe je dat ipv in ActionScript nu met Javascript / CSS.
Zozo, zal spelletjes.nl blij mee zijn met deze reclamebanner ;) Ben benieuwd of het wat zal zijn die spelletejs..
Anoniem: 174951 1 september 2010 09:09
Cool! Ben benieuwd of dat op m'n iPad werkt. Zou wel veel geld schelen in de AppStore :)
Waarom denk je dan Apple dit nu eigenlijk juist niet wil?

Maar het is toch een kansloze missie van Spil Games die niks geinvesteerd hebben in games voor de iPhone.
Ze dachten wel dat Flash er toch wel zou komen en zo hun bergen oude games snel ff te kunnen porten.
Mooi de plank misgeslagen door een aantal zogenaamde topmanagers die het beter dachten weten.

HTML5 linkt leuk maar het is lang niet wat het had moeten zijn om een serieuze Flash/Silverlight concurrent te kunnen zijn.

Op dit item kan niet meer gereageerd worden.