Tag Archives: rex

Why C2?

For the past many weeks, I’ve been focusing a lot on the development of the animation sheets. But because of this, I hadn’t touched the former aspects of the game for some time, and when I got back to it, there were some issues that were brought to the fore, such as the Beltway being broken. To be honest, I was utterly surprised at this, since I had no recollection, or notes, that say that it had been broken when I left it to develop the other parts. There were also other things that I noticed that needed changing as I tested the implementation of the animation sheets along with overall player movement.

I found myself a bit overwhelmed and a bit tired, as I sometimes do, from having to debug C2 events. For all the user-friendliness it has, it can still be be quite opaque especially if you’re trying anything abstractly complex. It’s not totally the fault of C2, but because of its lack of modularisation, or object-oriented framework within the event system, picking apart why something doesn’t work requires a bit of jumping around, trying to sort out which are workarounds to some weird behaviour, and which ones are meant to do something actually functional.

Anyway, for several minutes I stared at the monitor, and I was seriously debating why I’m developing this game in C2, and not in Unity, where I have some experience in, and the fact that I’m actually good at coding (at least good enough not to doubt my ability to see the project through). Not only do I code, but I’ve been in the CG industry as a 3D artist and TD for 15 years now; on that alone, Unity is more of a familiar programme than C2. But I had a discussion with my wife who takes these technical diatribes with calmness and puts out good arguments, and the result is my rethinking of my situation.

So the question is: why C2?

It began with the fact that C2 made things simple. But what I’m doing with CITIZEN is not so simple. And that reason seemed to be not good enough.

C2 is fun because of the event sheets. But though the event sheets are effective, they are effective as procedures. They are less fun, and less effective when you want some object-orientation or inheritance, which is so useful when when I started delving into certain gameplay concepts that I wanted to implement for the game.

But I think one of the strongest reasons is one of a balance between a simplistic framework, and the relatively blackbox type of plugin filtered into the C2 editor which results in less bugs during development. This is both a pro and con. Taking Rex’s GridMove/Board/SLG/InstGroup system. These are separate systems working together as one. But it has some learning curve to understand how it all of them work. In fact, some components actually need the other, so they’re really necessary modules in order to come up with something like an isometric grid framework. But once this framework is up, the input and output (eg On reach target, On move accept) is unambiguous, and can interact naturally with any other event/behaviour in C2. Why unambiguous? Well, first, the C2 editor registers the event, so it’s part of the choices. Unity, on the other hand, can be quite confusing in this respect; what event handler is being called?; a search through the documentation is necessary.

In Unity, it is possible to get a well-written framework, but you’re going to have to try it out first before you know what you’re going to get. Sure, that’s the same with C2 plugins, but the C2 plugin framework shields you from some the randomness of 3rd-party scripting. C2 plugins follow C2’s rules in order to play nicely with C2. You’ll spot a lemon faster.

But I think the most important aspect to plugin frameworks is simply that they can be added in without messing things up. I don’t have syntax errors in C2 compared to Unity, so if something doesn’t work, syntax doesn’t necessarily some into the picture. Even data types are managed.

I think the best example I can think of is trying to implement Unity’s 3rd-person controller setup to your own game. There’s so much going on in that package that if you try to fix it to behave how you want it, you’re going to mess it up so much that you might as well write your own to begin with. Unity is so flexible, but unless something is so well written, with open-ended framework development in mind (like, for example, PlayMaker), the Unity environment is pretty much like a sandbox.

C2, on the other hand, is more like a playground. You can’t move the playground that’s there, but you can add other stuff into it, transforming it into something new.

At the end of the day, this is just a hobby so it’s important to have fun. Fun is a major motivator. It’s obviously not fun when I have to deal with the awkwardness of C2, or when I have to refactor my events. It’s not fun when I accidentally change the image-point on one of my images and having no undo option for that. But nevertheless, it’s fun to figure out how implement features on an engine that offers a good starting framework.

Without a doubt (in my opinion, at any rate), it is primitive tool when you consider other production engines out there, open-source or otherwise. I think it is easy to outgrow the tools due to the ever-expanding ideas for a game. That’s partly why I had to limit the ideas that I was coming up with. Is that a bad thing? No, but I think I should like a separate post about that. 🙂

I think, however, in the future, after I complete CITIZEN in C2, I will more seriously consider using Unity for other projects that may require a more expansive toolset, especially one that may yield a better game by going 3D.

Workflow: Z-Sorting by Y

In the RND test project, I ran into performance issues with ZSorter due to the high number of instances I was using. I’ve easily re-implemented the C2 ‘native’ action of z sorting and the performance is much better.

However there is a gotcha.

The native version, despite what seems to be a vague reference of layering behaviour in the manual (search for Sort Z ordermoves instances which might have been in other layers to layer that had been sorted last. If the sorting is done per tick, there is no way to force a particular instance to another layer and expect that to render accordingly. (For example, I created a ghost clone over my main sprite. The ghost sits on a top layer, but is an instance of that sprite. Because the ghost belongs to the same sort family in which I base the sort, the ghost also gets sorted. And because the action moves the ghost into the same layer as the other instances, it loses its layer blending purpose.

The solution looks more like a hack: in cases like the above, where instances need to be separated, the sort reference variable (the variable that the action uses as a basis for a sort), should be overridden. In the case above, the ghost instance’s sort reference variable had an extremely large value so that the sort engine will always have to place it on top.

Workflow: Using AnimationLoader, dynamic tilesets

As usual, Rex has done it again. Or rather, he’d already done it.

The look development of the game is what I’ve always been concerned about. I’m creating tiles, binning them, replacing them. The tile management in Tiled is a bit too simple for my needs.

First came the issue of volatile tile IDs. Then the inability of re-arranging the tiles. So what I’ve done now is to offload all the actual organisation of data to 3d and C2 workflows. What this means is that I no longer have to use tile IDs to reference.

This is an outline of what I’m thinking of designing (and have implemented it for the most part at the end).


3d renders, or wherever the tile renders may come from are rendered directly to the C2 folder’s /Files directory. They have the following name convention.


This collapses the tilset name and tile id into one name. These are then put into a flat hierarchy in the /Files directory.

C2 animation name

Back in C2, I create a single tile sprite. The content of this sprite can be empty because the idea here is that the image will be dynamically loaded in.

This is the gtiles sprite (GBoard tiles), and contains (I think) all of the tilesets used in the game. Now the tilesets are stored in C2’s animation blocks. So in the gtiles sprite, I create all the tileset names that should exist:


This refers to the naming convention of the .png described above.

C2 animation frames

After the animation blocks/tilesets have been created, then I note down how many frames each tileset should have. I create the exact number of frames for them though the frames are blank. If I don’t I will get errors in the Browser console, but it won’t stop the execution of the game.


Rex’s AnimationLoader handles the loading of the renders in the /Files folder by going through every animation block in the gtiles sprite, and then through every frame that it has. I’ve written events that concats it properly, adds the underscores to conform with the convention, and it loads the images into those frames.


This is the important bit.

In Tiled, when I load in the tiles into the tileset, I must reference the png files in the /Files folder, because when the TMX is read, the image source from the tile is also read. This image source TMX attribute is the string that is parsed in order to determine which tileset this belongs to, and what the tile ID is. So, in effect, by the naming convention alone, regardless of which tileset the tiles belong to in Tiled, the fact that the file contains the tileset and id, that’s enough to make a connection to C2. In this way, it doesn’t matter how I arrange my tiles in Tiled because I only use the name of the png for the correspondence.


Collisions are often defined in the C2 image editor, and the information is stored in the caproj. However, when dynamically loading sprites, the corresponding collisions must also be dynamically loaded.

I’m currently implementing a solution to this which involves writing out .col files (collision files) that is partnered with their respective images. This much in the same vein as .imagepoint files.

Collision polygons are defined in Photoshop using paths. A ‘Work Path’ must be created, and a jsx to save that path is run. This outputs a .col file alongside the .png file that is being edited.

Back in C2, I’m currently modifying Rex’s AnimationLoader to take in this .col file implicitly, by reading the file, and then injecting the information directly into the poly_pnts array of the Sprite object.


Workflow: Tiled to C2 – Tilemaps

No C2 support for isometric Tiled maps

Using C2 Tile Object is limited to orthogonal, both in terms of doing the design in the C2 layout, or importing TMX files through the Tilebar functionality in C2. In other words, native C2 is a no-go for isometric levels.

Rex’s TMX Importer V2 Workflows

I turned to TMX Importer v2.x (tmxiv2) by Rex, which is a runtime importer and supports a much wider aspect of Tiled’s functionality. By ‘runtime’ this means that the map is not loaded into the C2 editor, and can’t be seen until the level is being previewed. This a bit of disadvantage for me, as I am used to editing things in C2. But I have been getting predictable results and I think, with enough practice, the workflow will be seamless.

The TMX Importer uses Sprite as though it were a tilesheet. It uses the animation frame of the C2 Sprite as a tile id.

Get TMX via AJAX

The standard way to retrieve text (ASCII) files from external source is to use the C2 AJAX object. In Rex’s own TMX examples, he uses pasted strings into the input. Either way, the workflow to do this is as follows:

On start of layout, AJAX object requests the ‘iso.tmx’ file. It is necessary to import this file into the project (under the project’s /File folder) in because the AJAX object assumes this to be relative root. This request is tagged with a name (eg ‘tmx’) and when the reading of the file is completed, Trigger:On completed is called, whereby we assume that AJAX.LastData contains the text file string data.

Using TMX Importer v2.x

Once the AJAX object reads the TMX file, it will run Trigger:On completed. Here we take AJAX.LastData as the content of the TMX file, and feed that into tmxiv2. There are two main methods of importing: creating tiles immediately, or retrieving a tile array.

Creating tiles (Action:Create tiles) is simpler, but it obeys a pre-defined behaviour which requires you to create C2 layers to match the TMX layers. This becomes a hindrance when you consider sorting Sprites. As I will touch on later about Rex’s ZSorter plugin, we need many of the Sprites in one layer. And so Action:Create tiles will not do that for us.

So the other way of doing it is to use Action:Retrieve tile array, which kicks off a procedure that starts getting the tile information. Note that the TMXXMLParser is used because a TMX file is an XML.

When Action:Retrieve tile array is called, it goes into procedure locating every tile. For every tile it encounters in the TMX file, it goes to Trigger:On each cell tile.

As each tile is being retrieved, it triggers Trigger:On each cell tile, which is the place to configure the tile as they are being placed. There is a caveat however. Although a Sprite instance is being created in Trigger:On each cell tile, there seems to be a problem accessing at least some instance information and thus some actions are not possible in that trigger. In the picture above, I had to reposition the tiles after they were placed by tmxiv2. I had tried to do it in Trigger:On each cell tile but the reference to tiles.ImagePointX/Y were not being read at all. While this may be a bug, I decided to use a trigger variable that is switched when the retrieving is finished in order to act upon the tiles instances from a different scope.

ZSorter and ImagePoints

In order to incorporate z-sorting, which is the sorting of Sprites based on their Y-position, the Sprites must reside in the same layer as the player character, and those moving elements expected to move in front or behind of other Sprites.

The first obstacle to this is the ZSorter’s use of the Origin imagepoint as a basis for determining the Y-position. This is not customisable, so I developed a workaround.

  • Place the Origin imagepoint in respect to how ZSorter references this position for sorting.
    Place the 'Origin' imagepoint for ZSorter.
  • Create a new imagepoint called ‘center’. This is the imagepoint used by TMX Importer for placement. This image point resides at the point where the center of the logical position is.


So what happens is that when TMX Importer first imports the tiles, it will default to using the Origin imagepoint, which will likely cause many of the tiles to be offset. We remedy this by using the vector difference between the Origin imagepoint and the desired center imagepoint and applying that difference to the tile





Understanding REXRAINBOW’s Board plugin


The Board plugin has several important dependencies that must be put in the project depending on what functionality is desired. Some of the following notes are not necessarily in Rex’s docs, which sometimes can be sparse in detail, though his examples explain things very clearly. So, in effect, the following is a distillation of the things learned in the docs and as it relates to the examples.

Board Setup

Before anything, the Board must be setup, which, at its most primitive, just the Board object, which defines the logical positions of the tiles.


The Board is responsible for creating the virtual logical grid (ie tile coordinates with logical positions). It specifies its dimensions.


This is a plugin that allows sprites/tiles to be placed on the Board as they currently are positioned in the editor. This is a convenience feature that is more useful if I was editing my level in C2. However, Tiled is my editor and will place tiles procedurally through other means.


ProjectionTx properties
ProjectionTx allows for trimetric projections, and other custom aspects. The key to its customisation is the VectorU/V.

This was an improvement that I personally suggested to Rex which is an upgrade from the original squareTx plugin. (Currently, ProjectionTx is not available at his site). The purpose of these ‘Tx’ plugins is to display the Board’s logical positions as a particular projection. Rex has kept these two aspects separate, as it is easier to visualise a ‘top-down’ Board as the basis for computation, and a ‘projection’ as a basis for defining how that Board is going to be visually represented.

When a call to Board’s Action:Create tile is made it uses ProjectionTx to place it in screenspace. It also seems that all other calls that involve visual representation, Board uses ProjectionTx to translate it.

The image to the right is ProjectionTx’s property panel. VectorU represent the direction of the U (or X or left-right) of the tile (if you imagine looking top-down) and VectorV represent the other axis. In other words, ProjectionTx is asking what is the screenspace direction of the X and Y axis of the tile. In an isometric projection, 32×16 pixels sprite, UX=+32, UY=-16, VX=-32, VY=-16. Explanation: X axis of the tile right and down: right for 32 pixels (+32), and down 16 pixels (-16); the Y axis of the tiles goes left and down, hence -32 (left) and -16 (down).


The Edge plugin works in conjunction with Board and movement. Edge objects exist between tiles, and the Edge object itself is queried if a particular edge exists between two tiles. This might contrast with the instinctive notion that we query the Board if certain Edges exist in its logical positions. After all, it is the Board’s turf. However, the way it works is that Edge objects keep track of themselves and where they exist between tiles.

Edges oriented by default along VectorU/V.
Edges oriented by default along VectorU/V.

When Edges are created, a Sprite is used to visually represent the Edge. It is thus rotated perpendicularly to the VectorU or VectorV of any given tile depending on the side of the tile the Edge is being created on. In isometric tiles, this produces a wrong result, since the orientation has a isometric ‘skewing’, and thus the angles must be set manually.


In isometric projection, the rotation of Edges facing along U (side=1|3) is -60 degrees, and those facing along V (side=0|2) is 60 degrees.
The result of a 60/-60 degree fix based on direction of Edge.
The result of a 60/-60 degree fix based on direction of Edge.



Movement is more involved than Board setup. It involves at least two plugins working in conjunction with each other, and involves a third if pathfinding is needed. For my needs, I need all three.


SLGMovement is the plugin that is responsible for pathfinding. Its responsibility is querying the board for the best possible path, and taking that information and feeding it into the InstGroup plugin (explained later). Thus, SLGMovement has two dependencies at all times: Board, and InstGroup.

Implicitly, it will use the first Board and InstGroup object in the scene.

However, a specific Board and InstGroup can be specified through its Action:Setup call.

The plugin computes for ‘cost’, which is the concept of how many ‘points’ it takes to travel to a tile. In the same vein, it can also prevent movement from one tile to another (for example when tile is impassable).


Edge objects can be optionally queried in cases where movement between two tiles cannot occur at a particular direction between each other (though it can occur if the path goes around the Edge).

The example here shows that if an Edge exists between two tiles that the ‘chess’ is trying to move across, then that particular movement is slg_movement.BLOCKING.

Through the example SLGMovement works this way: the path to follow is computed beforehand. This means that SLGMovement calls the On cost function repeatedly as it makes its way to query which tiles it can use to the desired destination. When by setting the cost as SLGMovement travels to the destination using its pathfinding algorithm, it can determine the best way. If SLGMovement.BLOCKING is encoutered, this means that this particular ‘leg’ of the path is not possible, and SLGMovement will try to find another way around.

Get moving path and InstGroup

The heart of SLGMovement is its Get moving path function, which calls the pathfinder. It has a few parameters:

SLGMovement dialog
Get moving path from a particular ‘chess’ object, to a particular tile (or ‘chess’). Moving points limits how far the pathfinder will trace. Moving cost is the ‘moving cost function’ that is called during query. Group is the InstGroup object which will receive the pathfinding data.

As the captions explain, the ‘moving cost function’ is the heart of the pathfinding querying. It’s here where a valid path is traced based on the moving points and the results of the ‘moving cost function’.

The weird thing about this setup, however, is in the InstGroup, which is an implicit dependency. You need InstGroup to make SLGMovement work because there is no other way to store the resulting path.

Once the path has been stored, the next part is the actual movement, which is handled by GridMove.


Once SLGMovement has stored the path in InstGroup, GridMove is used to access the path. The principle is to start the chain of calls to GridMove by ‘popping’ the first element that’s stored in InstGroup. The first ‘pop’ and move occurs in the ‘Mouse on click’ or ‘Touch’ trigger itself. When the first node is ‘popped’ it is SOL’d, and thus a call to ‘GridMove move to tile‘ will yield the SOL’d tile as the target.

GridMove On reach target
GridMove is used as a chain, where an initial move is made, and then using GridMove’s Condition:On reach target to iterate through the next point on the path. Note InstGroup’s ‘Pop one instance’ usage here, as it looks like a condition, but actually is a condition and an ‘action’ in a sense that it ‘pops’ one instance off the group ‘path’, and selects (SOL) that instance for GridMove to move to.

Then on Condition:On GridMove reach target, another instance is ‘popped’ out of the InstGroup. As the caption above describes, the ‘popping’ of the the instance is a GridMove condition. The condition will return a False if there are no more elements to ‘pop’, and in the image above, Function “GetMoveableTile” is run after the path has been reached.

Note that the ‘popping’ occurs at the head of the InstGroup array. This denotes that the sorting of the path nodes where the first element is always the next waypoint down the line.

Connection to Board

Normally, I would expect a explicit connection from GridMove to the Board, and hence, access to ProjectionTx in order to find the screen position of the logical coordinates. But as I look at it, the GridMove is attached as a behaviour of any given ‘chess’ (ie a movable element on the Board), and a ‘chess’ instance can only be in one Board anyway. So it seems that GridMove is able to trace back the Sprite’s association to the Board it was originally created in.


So, these are the following procedures that comprise isometric tile-based movement.


  • Board plugin as the basis for providing logical coordinates for positioning, and populating its own tiles with content through procedure.
  • (Optional) LayoutToBoard plugin as a convenience feature to populate Board with ‘chess’ data based on how the objects themselves are placed in the C2 editor in relation to the established Board.
  • Edge plugin as another element that is can be used in conjunction with SLGMovement to determine pathfinding. Though Edge is not technically related to Board, determining Edges is best done during the setup (though it can be changed any time).
  • ProjectionTx plugin as a visual transformation of the Board into a desired projection. In this case I’m concentrating on an isometric (or possibly trimetric) projection.


  • SLGMovement plugin as the pathfinding engine. It is connected to two other plugins: Board and InstGroup. By default, it will use the first object of each kind, so there’s no need to setup SLGMovement unless you need to. SLGMovement computes the cost of movement from one tile to another in the Board, and in this ‘cost function’ you can influence the pathfinding (eg blocking tiles). It then puts the resulting path into a named group in InstGroup.
  • InstGroup plugin as the container and actionable condition that works in conjunction with GridMove to ‘daisy-chain’ the stored waypoints. InstGroup allows ‘popping’ of instances in the array (ie group) which give the effect of moving to the next waypoint which is then fed into GridMove
  • GridMove behaviour as the function that moves the Sprite. GridMove is implicitly connected to the Board that the Sprite had been generated in using Board’s Action:Create tile method.