Pixi.js Noob OOP advice appreciated

[Jonny Shaw]

Hi all, first post, and a Pixi.js noob trying to learn the ropes - so please be gentle!

First off, I'm a designer by trade (www.digilocker.co.uk - shameless plug) but I have dabbled in coding over the years mainly on a UI Development basis (AS3 Scaleform, Flash, C# Unity).  A lot of my work at the moment is casino games, and we've been looking for a modern alternative for putting these together.  Previously games would be made strictly in canvas using sprite sheets and keyframed animations for the most part.  I've started using Spine for animations, which in turn has led us to Pixi.js as front runner for a renderer (with most mobiles now supporting webgl).  Phaser looked attractive, but not sure it would offer the low level access the developers would need to hook into the backend.  My role really is to get a prototype together in some form to showcase animations, get the frontend together and roll that onto future games as we learn the possibilities.  Previously tried Animate CC but webgl offerings are seriously limited I think there atm, so thought it was time to get my hands dirty!

Javascript is also pretty new to me to be honest, so trying to get my head around it at the moment.  I've got a very basic game prototype together, using GSAP for transitions (which I'm already accustomed to), but still struggling on how best to split a game down into classes if this is possible?  All the script is in one js file currently, and was wondering if it would be possible to take a more OOP approach?  (Can tell I'm used to working in editors and attaching scripts to components etc).  So for instance, I have a spin button in the game that has 4-5 functions for the state of the button.  Would it be possible to split this down into a separate class just for this button, and have them communicate with the main game file?  Similar scenario with a few functions I have for preloading webfonts (based on http://www.enea.sk/blog/preloading-web-font-pixi.js.html).  Just trying to lay things out the best I can before I end up with a mammoth js file!

Know this maybe pretty basic javascript coding to some, but if there are any pointers, or tutorials out there that cover this side of things, it would be very greatly appreciated!

Thanks in advance!

 

[themoonrat]

Hey!

First of all, be wary of GSAP unless you're willing to (or your clients are willing to) pay for a business license!

Second; es6 with it's classes syntax sugar makes an oop style a lot easier. I'm fact, pixi uses that right now, with a base display object class that a container inherits from, and a sprite is a container with a texture.. etc. es6 also adds in a standard way of creating and using modules; great for splitting up code into reusable classes/utils. Essentially, you'll want to use a transpiler to let you code in the latest language features to allow support for current browsers. Babel is the best (imo)

Third.... There are tool chains like webpack, gulp, browserify etc that let you help build your game. The are some templates on github you may want to take a look at, like https://github.com/edwinwebb/pixi-seed or https://github.com/Nazariglez/es6-pixi-bolierplate . They've not been updated recently, but you'll get an idea of how others structure their projects.

[mattstyles]

Sounds like you might want to do some reading on module systems in JS, this is currently probably #1 hot-topic as browsers have shipped (or are shipping) 'native' module systems, but, I'd say approach those with caution, be aware that they are there but its still very early and there are numerous kinks to work out.

Have a look first at how different files get executed in the browser and how they share state, it's actually pretty simple once you get a handle on it. Very generally the page gets parsed and executed head to toe so if you're including, say, 10, script files they'll get executed top one first. If you go down this path then you have to be aware of the order and be wary of what has or has not already executed. A common way using this system is to declare some of namespace early on and then share state this way:

// entry.js

var NS = window.NS || {}

// myLibrary.js

NS.myLibrary = {
  create: function () {
    this.message: 'world'
  }

  run: function () {
    console.log('hello', this.message)
  }
}

console.log('I log first!)

// myFile.js

NS.myLibrary.create()
NS.myLibrary.run()

<script src='entry.js'></script>
<script src='myLibrary.js'></script>
<script src='myFile.js'></script>

This is all pretty basic but it follows a pretty generic pattern of declaring a namespace to try and avoiding too much global nastiness, then declares some stuff to work with (its an object here but you might want to use classes if thats more your thing) and then gets into the meat of the business logic and sets up the object by executing a setup function and then executes a function on that object.

I added the console.log('I log first') inside the library file as an example to show that that code is executing in the browser so anything added there will execute immediately as the script is parsed and executed. In this example I'm assuming the script tags are at the bottom of the body but as its not touching the DOM it actually doesn't matter where they are, they can even be spread out, but, you'll get errors if you change the order at all.

This is how stuff began.

The next step was to wrap some stuff in an IIFE (Immediately Invoked Function Expression), which is primarily for library-style code, but was used pretty heavily for a long time (still is, but many module systems abstract this away for you), this tries to give you a little more control over leaky globals.

From there you start to move into the realm of commonJS vs AMD-style modules. requireJS was popular for a while but backed the wrong horse by favouring AMD modules and having only a clunky implementation of commonJS style, as node backed commonJS modules they became common place and as module spec evolved and is now being implemented they look far similar to commonJS style but with some slightly more complex loading patterns to deliver the code.

After requireJS modules in the browser got a whole lot more interesting as commonJS implementations came along, browserify being one of the first but there are a glut of alternatives now, webpack and rollup being very popular (but there are many many other interesting problems like jspm for example).

I'd suggest looking at how scripts get executed in the browser and modularising by simply including a long list of script includes in the page.

Then I'd look at how you can do a simple build pipeline by concatenating those files together (from my example above you could simply concatenate those files together, in the same order, and have only one file to include).

Then look at how browserify works (which requires the build step). I say browserify because it is the simplest to get up and running and it basically wraps all your individual files in closures (via functions) and delivers dependencies to those files via other function-wrapped files (which sounds complex, but, if you get your head round it is pretty simple).

From there you might want to investigate webpack and rollup, but note that browserify, webpack and rollup (and the other systems) are all good enough to create complex applications and modularise code and are all used heavily across web development to create both apps and libraries/dependencies for those apps. They solve problems in slightly different ways but all are more than capable of creating anything you like.

Note also that some tooling (like Phaser) don't always want to work super well with a module system. This isn't necessarily a problem, Phaser is library code and so its not a great deal to just include a script tag for the Phaser code and then use a module/build system for your app code.