We often get email from readers or podcast listeners asking to expand on certain topics. Many of these questions can be of value to all our readers so I’m going to start posting them Q&A style on the blog now and then. So, without further ado, on to this installment of LDG Mailbag!
I’d suggest using a game focused framework as opposed to something like jQuery or MooTools because most of them weren’t created specifically for browser based games. That said, if you’re familiar with a certain framework and you’re creating a DOM based game then it could be a good choice for your needs.
If you’re looking for a game framework I’d have a look at ImpactJS. You’ll need to purchase a license, but it’s totally worth it in my opinion. Checkout our interview with Domenic Dominic Szablewski, the creator of ImpactJS.
At the end of the day, you’ll want to be using whatever framework fits your particular needs, coding style and project requirements. For example, a side-scrolling action game is much easier to develop building on ImpactJS than jQuery. However, a text or menu based game might be easier to develop using a more DOM centric framework.
The canvas object is featured very heavily in your games. I played about with canvas coding in 2010(ish) and was put off by the very limited support in some browsers. I know that the baseline browser has significantly improved but does the canvas offer that much improvement over moving elements on the page? Generally I will change the position of a div element (or similar) to move something but know the canvas can do this.
Canvas support and performance is definitely much better these days. The canvas API has always been pretty straight-forward which makes browser differences less likely. At its core, canvas is all about copying pixel data from images to the canvas and isn’t as affected by the DOM box model or other browser specific layout quirks.
I personally like the canvas approach more because the concepts are closer to traditional game development. Some developers choose to go a hybrid route with canvas and DOM, but I prefer to keep our stack homogeneous. One benefit of that choice is that all our UI elements can be layered and animated in the same way as our in-game sprites.
A downside to canvas is that being so low-level, you’ll have to handle certain tasks yourself that the DOM would provide for free. For example, when rendering text in canvas you’ll need to handle text wrapping explicitly. User input controls is another area where DOM gives you a leg up, but in my experience it’s been pretty easy to create re-usable canvas based input controls with our framework.
Again, using canvas, DOM or both definitely comes down to personal preference and project needs. The closer your game is to a tradional web app, the more you are likely to lean towards the DOM.
Finally I read the post about using the Game Closure framework to get Onslaught! Arena running on an iPad. At the end of last year I had to develop my iPad orientated first web app (an interactive publication for a customer) and although I got quite a few things working OK such as finger swipes and similar, developing for the iPad clearly requires a slightly different approach to a regular web app. To this end it’s an area that I’m really trying to push myself to learn more and possibly start developing some native apps. Looking at the Game Closure site, it appears to basically be a development server for static html5 applications and a fully fledged JS framework, plus a compiler. Did you have to recode parts of your game using their framework or did it largely just import in OK? Are there any pitfalls you found when using it?
Integrating Onslaught! Arena with Game Closure’s tech was pretty easy. We had developed the game with a few main entry points such as handling input, updating the game world and rendering the game. Game Closure’s framework took a similar approach so we simply wired up their handlers to ours and everything mostly just worked.
I think the primary selling point of using Game Closure would be that it solves the framework, IDE and deployment hurdles in a single tool.
Ask your own questions by contacting us or posting a question in the comments section below!