Best practice for Canvas game development

[non_tech_guy]

Hello,

 

I have been creating simple online 2d apps for the last few years. I started out in flash and now find myself doing only HTML5 canvas development. Because of my background I am using the createjs library which has really seem so many improvements over the last year and makes the transition to js quite seemless. Phaser is a good looking framework but not all of my projects suit it. I have also been implementing my own MVC design pattern which I had been using in flash. It basically sets up a model and controller as singletons and dispatches events via an eventDispatcher. There are a few things that I am still unsure about starting out a project and I hope to find some of the answers here. By using my MVC approach I have to spend quite a lot of time setting up my project and I am looking at other built frameworks that might help speed this process up.

 

1. What is the best approach when doing a canvas app? Should all assets be part of the canvas like game overlay screens or should those screen be divs in the HTML that exist above the canvas? I have implemented projects both ways but don't see which is better.
2. Even when implementing my MVC pattern I find that my projects can start to fall over when they get bigger so I have been looking at Backbone and Angular but not sure which framework is better for canvas development. I guess that it the game overlay screens mentioned above are divs then Angular could work. Anyone been there done that?

 

Any and all feedback is welcome,

 

Thanks.

[rvizcaino]

Hi, with phaser you just reference the main div, all the work of loading assets is from phaser directly.

[d13]

I have also been implementing my own MVC design pattern which I had been using in flash. 

HTML5 game development uses immediate mode rendering. This is very different from web applications which use retained mode rendering. Here's an explanation of these different modes:

 

http://msdn.microsoft.com/en-us/library/windows/desktop/ff684178(v=vs.85).aspx

 

MVC patterns (Angular, Backbone etc) are useful in web development because most web pages are stateless. That means there's no event loop updating them 60 times per second that drives the application through time. If there's a change in an object's state, the only way it can inform the rest of the system of its new state is through an MVC notification system. 

 

HTML game development (and Flash) use an event loop, which means they run in immediate mode. Instead of having a notification system between objects, you can check for changes in an object's state directly in the event loop. Something like this:

function gameLoop(){  requestAnimationFrame(gameLoop);  if (object.state === changed){    doThis();  }}

This is actually a much simpler an possibly more efficient way of tracking states than using MVC.

 

AS3.0 suffered from a lot of baggage brought over from Java and C++, and many game developers (myself included) felt we had things the proper, OOP way and implement an MVC to track states. What we forgot was that Flash uses immediate mode rendering with and event loop (onEnterFrame) which is much better way to track state than building a complex (and unnecessary MVC system).

 

So to get back to your original question, my suggestion is to check for and change properties directly on objects inside the event loop. There's no need to route them through any intermediate notification systems like MVC.

[non_tech_guy]

@rvizcaino Phaser is great but is not always the best framework for me to use. I really do like the way that the framework is structured ie - Boot | Preloader | Main Menu | Game.

 

@d13 thanks for you in depth response. I have seen the gameLoop mentioned quite a lot posts but I was not familiar with it in fact I am not familiar with retained and intermediate mode so thanks for the link.

 

On the topic of game screens like start screen | main menu | pause overlay | reset overlay | game over screens,  should those be part of the canvas or as divs that exist above the canvas? I have implemented them both ways in my projects but I am not certain one has a distinct advantage over the other. In flash they were always part of the swf but canvas does not render fonts very well.

[d13]

On the topic of game screens should those be part of the canvas or as divs that exist above the canvas?

It really depends on your coding style.

I prefer making game screens using canvas based sprites, because then I end up with more consistent code.

(It means I don't have to jump between HTML and canvas code.)

But to do that you need a fairly robust sprite system (a "scene graph") that lets you nest sprites inside other sprites.

That means you can use sprites as containers for all the child sprites inside a game scene.

It's then easy to hide and show different scenes depending on the state of the game.

 

It's not too difficult to build your own scene graph from scratch, but does take a bit of time and a lot of testing.

I've done it a few times, and every time it scares me

But you could use a pre-built scene graph like Pixi, which I would strongly recommend for production level development.