BT

Horia Dragomir on Mobile HTML5
Recorded at:

Interview with Horia Dragomir by Werner Schuster on Aug 31, 2012 |
16:19

Bio Horia Dragomir is a UI Developer, currently working at wooga in Berlin, where he focuses on developing HTML5 Mobile games. He has spent the better part of his working days in distributed teams, employing agile methods and discovering better ways for teams to work together.

GOTO Copenhagen is produced jointly by Trifork and DANSK IT and is a vendor independent conference where the program is put together by a Program Committee. The target audience for GOTO conferences are software developers, IT architects and project managers.

   

1. We’re here at GotoCon Copenhagen 2012. I’m with Horia Dragomir. So who are you and did I pronounce your name correctly?

People should pronounce my name Horia Dragomir. I’m a Romanian UI developer. I’m hungry and foolish and I’m now working at Wooga in Berlin.

   

2. So, what’s Wooga?

Wooga is a company that builds social games. The name is short for World of Gaming and we believe games should be for everybody, not only for the hardcore gamers but also for also for people that just want to spend some time doing something else. So that’s how we approach games and that’s how we build our games, for a lot of people very casual and as fun as we can make them.

   

3. What technologies do you use to build them on the iPhone or what do you use?

Most of our games are still Flash games that run inside Facebook. We are making immense progress in mobile now because we believe that’s the next market and it’s proving to be so. So we have native apps and we have web apps, games actually on mobile.

   

4. Do you actually have performance intensive games using Java Script and HTML5 on mobile. How does that work for you? Does that work?

That’s something you always have to keep in mind when you’re building anything especially a game, performance that is. So you end up optimizing every step of the way and then you just find the pain points and you try to alleviate those and you just increase performance as you would traditionally with any application.

But, yes, it is sometimes a barrier and we sometime drop ideas because it just wouldn’t feel smooth enough. So even though it might be a great effect, it won’t be a great effect because it wouldn’t feel real.

   

5. You mentioned smoothness, it’s responsiveness you’re targeting?

I’m pretty big on that, yes, smoothness and responsiveness. If whatever you’re building doesn’t feel natural to a user, he will always remember that he’s using something. But, if the game, in our case or the application in another case responds in a perfect way or in a way that seems seamless, then the user forgets that there’s another level of interaction between him and what he wants to achieve and he focuses straight on the goal.

   

6. With HTML5 or CSS, what are the big hurdles with mobile development or, making things responsive. Are there things that are just impossible, are there things that are possible, but only for small numbers of sprites and things like that? What’s your view there?

I have a strong belief that you should never ask an engineer if something is possible or not. The answer is always yes, everything is possible and everything is truly possible. It just takes a long time or takes a lot of effort in other cases. But basically barriers are only pretty much hardware related these days. As technology advances, as the iPhone 4S, when it came out it was a lot faster than the 4 and we actually use that performance to create better animations or to have a better frame rate in a game. It’s basically like it always has been, a hardware issue. The software will always catch up with the hardware.

   

7. So hardware issue - do you mean limitations of the hardware?

Yes. I mean number of clicks the processor can handle or number of ticks per second for the processor. How many things can you animate at the same time on the screen? You have to test all that and see where the pain starts to show and then you know your limits where you can play. Sometimes though that’s not enough, you want more and that’s good, that drives the industry forward, I think.

   

8. When you work on mobile games, what kind of technologies do you use in the browser? Do you use Canvas do you use SVG or other things?

SVG, I don’t know why people don’t use it, it is a great technology, but I don’t know why I don’t use it, okay. I just don’t. I use Canvas. Ever since last year, Canvas’ performance has been actually pretty good except for Android, but in general it’s been pretty good. And even on Android it’s not that bad, so you got decent performance, decent animations, and things just seem okay. You don’t need any big improvements anymore. I’m a big fan of Canvas, so you know I use it even on desktop it is a great technology.

   

9. So one of the problems I’ve seen with Canvas is anti-aliasing which, oh, you seem to have an opinion on that?

Yes, of course. Well, it’s pretty okay on iOS based devices. Still, there are problems. But on Android is a lot more apparent and basically what you have to do is take care when you are creating the images in the first place that you don’t have a lot of things that should be anti-aliased, otherwise well, if you’re targeting Retina Displays, the problem becomes so much smaller like half of what it should be which is good. And for the old devices, it doesn’t make that much of a difference and plus if you would really need spiffy icons or stuff like that, you should probably use DOM for that anyway. But it doesn’t get to be a problem as much as it could - not in practice at least.

   

10. Are you actually drawing lines and paths with Canvas or are you mostly using it to push sprites around?

Mostly to push sprites around. But we have had no problems with anti-aliasing rounded corners or what have you inside Canvas. We’re happy, the whole team and I. I do remember some experiments I’ve seen earlier with Canvas. It did seem a bit choppy and seem like they could use a bit more processing power. But I guess, well, I was just dazed by the whole technology behind it anyway.

   

11. With animations on Canvas, is it possible today to use the requestAnimation APIs?

No. It is possible on desktop, yes. On mobile, no, you just don’t get that yet. We’re hoping. Apple promised to have it in pretty soon. It might have landed with the release, I haven’t checked. But that wouldn’t help Canvas anyway because Canvas is like it’s in a separate thread. You can pretty much paint with it regardless of the browser’s animation loop, so that’s one good thing. Painting to Canvas in itself is a costly operation. So you yourself have optimize that.

   

12. In what way?

Oh you may want to cache the big picture and just repaint the dirty bits and then flush it to the Canvas you show. That’s what we do, we have an off screen Canvas where we manipulate everything and the all the clicks go there and what not. And then we just update the dirty bits and we take the image and paint it and we have to do that like 30 times per second, so it actually works.

   

13. It's a sort of double buffering in a way?

Yes. Also, if we change nothing on the Canvas, we don’t touch it, we don’t redraw if we don’t have to and that’s a huge battery saver.

   

14. Which I guess suits your games because…?

Horia: We want people to be able to play and have e-mail and still have a phone at the end of the day.

Werner Schuster: After twenty minutes.

Horia: Yes, exactly, exactly. So even battery is important or should be for everybody. And you get nice APIs now in Firefox indicating the battery level or not level but if it’s charging. If it’s not charging, if you should do the animations or not. I want to see those APIs in all the platforms because they are helpful.

   

15. How do you develop for mobile platforms? Do you develop on a desktop and work with an emulator or how do you test these things?

Horia: Well, for the most part, there are two different things, really. It’s the interface, the graphical part that you have to test in a phone or the simulator. I use Adobe Shadow to like load seven devices with the same thing and it’s a time saver. If I want to do small changes, I use the simulator because it’s just faster, but for logic, you can do it on anything and we actually do it in Chrome, the closest thing. Okay, there’s Safari, but we like Chrome. And that’s where we develop the logical bits, the logic part, the business logic whatever you want to call it because that should work independent of platform.

Werner Schuster: So if you test or want to find an issue on an actual device...?

Horia: We have the actual device, in-house.

   

16. Right. And what’s your view on debugging and testing on actual devices today?

It used to be a lot worse, horrible, but now, tools have caught up with what people are actually doing and it’s no longer a pain. Like I said, you have Shadow from Adobe, that’s pretty cool. You have Remote Inspectors, Apple has enabled something like that with native applications. And if you’re doing a debugger, you can just link your Safari’s inspector to the phone, I mean the simulator. Opera has been doing it for years, nobody mentions them, nobody gives them love, I do. Opera has been remote debugging on mobile devices since, I don’t know 2008 maybe. So it’s getting to be a good environment to finally be able to debug. It’s cool. It’s getting better finally.

   

17. You already mention iOS and Android and things that behave differently on these platforms. What’s your experience with that? Do you develop mobile HTML 5 applications? Do you target them at iOS and not others?

There’s generally a common ground between Windows Phone and Android and iPhone. But then you have to make platform-specific adjustments, let’s call them that because things don’t always behave the same and we’re used to that. I’m a web developer by trade, that’s my background. So I’m used to differences between browsers and having different adjustments based on the browser. That's not a new thing and I think nobody who works in this industry sees this as something that’s weird. It would be great if everything would behave the same, but you don’t get that and that’s okay as well.

   

18. But for that you use Flash?

Yes. We use Flash on desktop exactly for that because everything just works and you just don’t have to care anymore.

   

19. So here at GotoCon, we had a keynote on the latest language from Google called Google Dart. When are you going to switch to Google Dart?

Switch? I’m never going to switch. I haven’t switched to CoffeeScript. I use CoffeeScript but I would only use Dart for a huge project. And don’t get me wrong, a game is a huge project, but we built it so fast and we actually never transitioned properly from a prototype to a natural implementation. We just built on top of the prototype, that’s how fast we had to move. And Dart makes sense in my eyes only if you have a huge code base with many people working on it and that way you can just ignore problems from the language and just enjoy the syntactic sugar it offers and the nice constructs. For a weekend hackathon, I wouldn’t choose Dart, especially because I would have to learn it. I’d use CoffeeScript for that.

   

20. So you use CoffeeScript for quick experiments?

Horia: Just to have fun. It’s just a pleasure.

Werner Schuster: And what does CoffeeScript do for you? Is it just fixing all the problems of JavaScript?

Horia: Oh, nothing is ever going to fix all the problems with JavaScript. No, but that’s why I love it. And the CoffeeScript is like a shortcut to things I want to do. Something I would have to write in a hundred lines of JavaScript CoffeeScript can do in like twenty. And that’s a lot less I have to type, it looks a lot cleaner too and it compiles to JavaScript, I don’t have to syntax check which is great because I suck at syntax.

   

21. You just have to remember CoffeeScript syntax?

Yes, which is fairly easier, plus I enjoyed Lisp when I was in college and you only had brackets. So I like it when you have nothing that obfuscates the code. It’s like Python and Ruby, it’s a lot easier to read.

   

22. Or ClojureScript?

I’m not a big fan. I’m not a big fan. I don’t hate it. I don’t have an opinion against it. I like Rich, but I’ve never gotten around to actually play with it in a meaningful way. So that’s why I’m not a big fan. I just need to try it properly.

   

23. What’s your view on languages that compile to JavaScript? Any other big languages, eg. GWT? Would you use that as an alternative, for large teams, as an alternative to Dart, for instance?

I’m biased here because I don’t like to work in large teams. If it’s something that’s over twenty people, all coding, that just drives me away. So it doesn’t appeal to me on a personal level, that’s my only problem. I know and I acknowledge that it has its place in the universe, it’s just I’m not in that place. So I wouldn’t choose any big framework with that compiles to Java Script in production.

   

24. And to wrap up, what kinds of platforms are you watching besides the existing ones? Are there any interesting mobile platforms coming up or are we stuck with the ones we have now?

We’re definitely not stuck and if you know Mozilla, they can pull off amazing stuff. Their Boot2Gecko platform, I think is going to be big. I don’t think it’s fragmenting the web as others do, it’s just giving an alternative and if you can plug in and write JavaScript and simple HTML apps to do just plug in to an OS and have direct access to battery levels and orientation just off the bat. I think that’s going to enable a lot of cool apps and cool things that aren’t possible yet because of all the limitations. So definitely keep an eye on Boot2Gecko.

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT