In het huidige nummer van Control staat een artikel over HTML5 – wat zijn de mogelijkheden hiervan voor games en vormt het een bedreiging voor de alleenheerschappij van Flash? Voor het artikel interviewde Niels ’t Hooft de Italiaan Francesco Cottone, de maker van Akihabara, een framework voor het maken van (2D)-games. Aangezien niet alle citaten een plekje vonden in het artikel, en het interview interessant is voor ontwikkelaars van webgames, vind je na de klik het hele gesprek (in het Engels).
Niels: First of all, can you tell me who you are?
Cottone: “I’m Francesco Cottone and I work as a senior programmer in a company in Milan, for boring things like application servers: Asterisk PBX and other funny acronyms. I’m that guy that never wanted to play soccer with schoolmates because playing The Great Giana Sisters on his Commodore 64 was better. That guy that skipped the beer out with friends just because he had to install the next cool Linux distribution and that guy that thinks that a cool game is not Metal Gear but Noitu Love 2. The usual nerd.”
How did Akihabara come about?
“I wrote Akihabara in my spare time, with the purpose of helping me develop some proof-of-concept on the Mac I use at work, the Windows laptop and my personal Linux laptop I use on the train, without installing a cross compiler: just open the notepad and starting prototyping.”
What everyone is calling ‘HTML5’ is really a grab bag of technologies, including CSS and Javascript. How would you describe it?
“You’re right. HTML5, CSS and Javascript are a bunch of technologies: the fun starts when the technologies works together. Many of them are already doing their thing during our everyday browsing, without us noticing it (Facebook, many of the Google services). As with all technologies, they are just funny names – Java and Script are actually the names of two pirate robots I invented for my nephew – but what makes them cool is how they are used. Chatting in a web page is now an old thing, but this happened when Javascript, HTML and CSS started working nice together.”
Which parts of HTML5 technologies do you depend on for your framework?
“I’ve used just a small part of HTML5, that is the tag. Canvas is just like, well, an artist’s canvas: you can draw anything on it, from lines to copying frames of an animation. Working with canvas is really like working with the famous SDL library – just in the browser. What makes everything move is massive JavaScript code, that I’ve tried to optimize for speed, sacrificing a little something in readability. ”
Can you explain how your framework works?
“Akihabara uses the good old ‘blit the image / render the frame’ approach on creating videogames, mixed with the flexibility of JavaScript in terms of object structure. In Akihabara there aren’t ‘sprites’ but raw objects: it’s like having many small robots that do some math and draw together on the screen. One will calculate the position of the hero and draw it on the screen (adding the annoying fairy that follows him, if this hero is heavily licensed, because a robot can do many things in sequence) and another one will move a goblin and check if it is going to hit the player. If this happens, it will ask the player’s robot to gently ‘kill’ himself. It is a mix of classic C-like SDL programming with modern object oriented programming. I’m not sure that this is the best approach for games, but it simply works.”
For what types of games does it work best?
“Akihabara was built with 2D games in mind, so 2D platformers (classic, stage-based or with exploration), adventures, puzzles, beat ‘em up and so on should be doable. The Solitude demo shows some bullets, but I don’t know if a bullet-hell game (a genre I love) is doable without lagging on slower devices. It is still in its infancy, so I don’t know what is really doable. Probably the best thing to do is just try, as I did with the demos.”
What do you feel are its limitations?
“For now, for making games with Akihabara, programming skills are required. Nowadays that is some sort of drawback. There are no visual tools for designing a game at the moment, but keeping with the metaphor I’ve used before, there’s a number of ‘presets of robots’ that can help you in Akihabara. Another big problem is the lack of documentation but I’m seeing tutorials and contributions popping around.
I noticed you’re not supporting audio yet. Do you think audio is possible with the current technology?
“I played with Gimp for years, so I can produce some graphics by myself, but I’m really the negation of music. So, since I didn’t need that, I simply didn’t work on audio. I’ve started working on audio in the past few weeks because I think that – as I read in a forum – audio can be half a game. And I’m facing a lot of technical problems: browsers aren’t providing something that ensures realtime performance of audio. I don’t mean that audio is impossible – I hope to commit my changes to Akihabara in the next few weeks, which will add music and sound effects support as an experimental feature on many browsers. I’ve added sound effects and music to all the demos, but I’m awaiting responses from some chiptune artists about using their music. Some of them are really happy to work on the project – I’ll never stop to thank them for their work.”
What did you achieve during development that you’re really proud of?
“After having coded most of the engine in JavaScript, I figured out that there was a big performance problem on desktop browsers when the game screen was ‘stretched’: the higher the zoom was, the slower the game became. The performance degraded because I was using a surface as big as the stretched screen as framebuffer. Then I discovered that, applying a doubled height and width to the canvas tag using the ‘style’ attribute of the tag (a classic practice when creating a site) and keeping the original frame at this smaller size, the slowdown vanished, since the ‘charge’ of stretching the frame was moved from JavaScript to the browser (which is faster). With this change, games started to run at full speed on 20x zoomed displays (not useful, but it shows very cool big pixels) on desktop browsers but, more important, at full speed on iPhone 3GS (and sometime also on older iPhones).”
What are the greatest remaining limitations of HTML5, that you would like to see fixed in, say, HTML6?
“HTML5 is still in draft, as you can see on the specifications page, so it is still improving. 2D support is already good, from raster graphics to vectors (which I’ve not explored enough). 3D support is on the HTML5 schedule, but it still needs standards and solid implementations.”
“What is probably missing is more clarity and strictness on audio specifications – sometimes I suspect that this feature was added just for putting some background music on sites. Probably something like but for audio should be the best solution for videogames (i.e. not samples-based but with raw audio support – Firefox is trying to implement something like that, but it’s not a standard specification). Another important fact is that HTML5 only defines how some things should be done but not how these should be implemented. That means, for example, that responsiveness of audio elements is very different from browser to browser, since it’s not defined by standards. Browsers have to work still a bit for better implementing these specifications, with high-performances solutions.”
How far along is full support of HTML5 in all browsers? Do you see Microsoft supporting the tag in IE9?
“Microsoft says, ‘HTML5 is the future’, so I hope that all the features will be implemented in their browser. You probably want me to say something about commercial things, agreements and the market, but I’m too much of a user for this. As a player, I’ve bought a Nintendo Wii for playing Zelda. I’ll use [insert cool browser name here] if a cool game will be available for that. It’s easy if I don’t have to pay a buck for this. And even easier if I don’t have to pay a buck for making that game. Without stealing, obviously. Long story short: the next Cave Story will need a browser that supports ? I’ll use a browser that supports . It is like the console war, but with browsers.”
Do you see HTML5 replacing Flash as the platform of choice for developers of web games?
“I think that what ‘rides’ the technologies are ideas. So when more good games / sites / geek things will be done using HTML5, we will probably see less things in Flash. It’s the king of obvious. I really love Pac-Man Championship for Xbox 360 and iPhone. I purchased a game from 1980 twice, so probably it’s not the technology they have used to convice me about choosing the product. Akihabara mimics the old-age games, trying to pay tribute to indie gaming, but after a quick look at the code, you will see that the 2x zoom and the 320×240 resolution are just default values. Ideas are the things that HTML5 (or Flash) need to win.”
Do you think it would (theoretically and practically) be possible to create HTML5 authoring software to make creating games as easy as it is in Flash?
“The tendency of the internet is to reproduce desktop-like experiences in browsers: Google provides free word processors, document viewers, chat, mail applications and spreadsheets. So, a GUI is doable for sure.
Blockbuster game creator tools are commercial, so probably just need more attention from the market – probably companies are discouraged by mixed performances of browsers and the lack of details of the specifications. Meanwhile some ‘nothing to lose’ solution can progressively fill the gap. Time has the answer. (I always feel old when I say such things.)”
