However, a game state is essentially a one big global scope.
It defines where the enemies are, how many hit points they have, and how much health and ammo you’ve got. And each part of that system potentially can affect any other.
In reality, the global scope is not that bad if you know how to deal with it.
Collider.JAM offers its own approach of global scope organization and handling.
The global scope in Collider.JAM represents the scene
and all associated resources.
It is called the mix since it mixes all mods and fixes
into a single tree hierarchy.
At the top of the mix, there is the root mod.
All other mods are mounted inside at
/mod by default.
Everything in your game is placed somewhere in the mix.
You can think of it as a virtual filesystem
that joins together all the
folders you have plus all the system
folders shipped with Collider.JAM.
The mixing process is pretty straightforward - you start with a bunch of mod & fix folders and load them into a single tree at particular mount points.
$ Global Accessor
By default, the whole mix hierarchy is exported as a $ object.
It is done primarily for the convenience of debugging.
You can always open the browser developer console
$ to dump the whole mix,
$.lab.hero to dump the hero object.
Since Collider.JAM DR9, the
$ object is defined
both as a global variable and as a variable within Collider.JAM scope.
The reason is that the global $ can be disabled to restrict the access to mix from the outside:
window.$ = null
Also, it can be reused for other purposes.
But within Collider.JAM scope, the
will still be pointing at the mix.
Almost everything in your game can be accessed through
since everything is placed as a node on the mix tree. It is truly the global context of the game. The rare exception would be the data and functions hidden inside closures.
In most cases, you don’t need to access the root mod.
Usually, you work with the current mod and there are a bunch of links in scope to access it. We call it a local mod context, but it is not truly local. Better think of it as a global context of the current mod.
There is the
_ accessor that points to the current mod.
There are also fast node accessors like
trap. You can use them for quick access
to particular components of the current mod.
Let’s assume you need to run the
hud object in
You can access it from anywhere by using the mix
console.mod you can say:
Or even better, use the
By using the local path instead of global, you make code shorter and more portable. You can rename the mod or mount it at another node of the tree and all the local links will continue to work without any changes.
_ and $
$ are the main things you need to know
about the global scope in Collider.JAM.
_ to access current mod.
$ when you need to access things globally in other mods.
$ in the browser dev console.
_ accessor is defined only within each mod’s scope
and makes no sense in the browser dev console context.
Collider.JAM Global Context
It would be unfair if I’ll not mention other objects in Collider.JAM global context.
$, there are many more
things defined in the mod scope.
There are drawing functions like
There are math functions like
There are utility functions like
But these would require more than a single post to cover them properly, so see you the next time.