Sign in to follow this  

Connect html ui and phaser canvas

Recommended Posts

I dont use Phaser but I do it frequently with other canvas renderers (usually I use Pixi or Stackgl stuff).

Think of an architecture where rendering is decoupled from logic, this is almost always a good way to go. Your UI, or, your rendering, can be considered fairly dumb, it simply tracks user interactions and passes those events to the logic, the logic then performs the actions.

If you structure like this then its easy to tie up multiple different rendering layers, such as HTML and canvas stuff, as the logic that you use to change states in your application isnt really concerned with how your application is displayed, it simply performs mutations which update your game state, your rendering layer should then re-render your game and you’ll get a visual representation of the changes that have occurred.

I'm in the camp that discourages globals, but, in some cases it can simply make your job easier (and therefore quicker) if some classes are available all over your application. Taking the global approach is usually great for early development, or fairly trivial applications, but will quickly become a ballache as your application grows. However, libraries like jQuery or Phaser, (where you ordinarily have just a single instance) it makes sense that they are global, even if you use a module system to remove them from the window global context. Really it is up to you and needs of your application whether globals make sense or not.

For me, the major case against globals is that they can be grabbed from anywhere in your code. At first glance this may seem like an advantage, but, it encourages you to use them in the middle of function/algorithms which means that you may be introducing undesirable and/or unpredictable side effects. This can be a real killer.

Share this post

Link to post
Share on other sites

I was not thinking global globals like old school but one global object to namespace everything. 

Like this

var MyGame = MyGame || {}; = new;

MyGame.triggerUi =function () {

// do UI magic here

} ;

Atm I structure stuff like this. As I am Always looking for better options that is the reason I started this topic. 

Share this post

Link to post
Share on other sites

JS being what it is, you're kind of stuck with the namespacing and leak at least one global. There are solutions to this though as namespacing is still pretty horrendous.

There are a fair number of module systems available for use in the browser, they require a build step (yes, build steps are a pain) but allow you to modularise your code a bit better and stop leaking globals. I recommend browserify, although webpack is another popular solution, there are a number of others. I'd say steer clear of AMD solutions like requireJS, modules are coming to the browser and they will not be AMD so not really worth learning, the commonJS style is more intuitive and simpler anyway (learn about all these terms if you dont already know them).

But whether you choose to use `globals` or some other module system is secondary to your question anyway.

Your question could easily be 'How do I connect disparate parts of my application?' or 'How can I let my objects communicate with one another?'

The good news is that these concerns are about as old as programming is, certainly as old as object-oriented programming anyway.

At the moment it doesnt really look like you are making much distinction about the different parts of your application. 

Think about things in a slightly different way. Each action that your application performs could mutate (change) the state of the application. If you take this approach then your UI sections, and any JS that might control them, are simply responsible for turning user events into actions and passing those actions on to other parts of your application that then respond to those actions. The chain is simple, and I'm sure you already know it:

* Register user event

* Convert user event into application action

* Perform state mutation based on action

* At some point, render the new application state

The bit you're asking about is between steps 2 and 3.

The simplest pattern I know to learn about is the publisher/subscriber pattern.

Your UI code are publishers, they publish (or emit) events when they receive user events. Your logic code (or application code, or business logic, whatever you like to call it) are subscribers, they subscribe to publishers so that when the actions are published they are told about it1 and can respond accordingly. (there a few different ways to tell a subscriber about an action, some do not involve telling! I'm trying to keep things simple so I'll gloss over that detail for now). 

There are many other ways (and many variants of pub/sub) but I think this is the simplest pattern to understand, and it is the one used by the browser itself to respond to user events so any frontend web dev should be very comfortable with it.

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.