My biggest challenge was always time. Building an entire game engine from scratch is the kind of thing people deride as a challenging and, let's be honest, slightly foolish endeavour.

Life commitments in 2020 drastically reduced my free time and all my passion projects had to take a back seat to paid work. By 2026 that had started to change. Agentic coding tools had matured enough that chipping away at a project this size in limited time finally felt feasible, and the vision I had been carrying in my head for years was worth chasing again. It felt like time to embark on this epic journey once more.

So I got a Claude subscription, dumped Opus 4.6 inside my decade-old codebase and started a massive modernisation campaign.

setState(prevState)

While the engineering fundamentals of the engine and game code were strong, the scaffolding around them was a different story. It had rotted into a graveyard of unsupported libraries and known vulnerabilities.

The game and the engine lived in separate repos, each built on the deprecated create-react-app. The two were decoupled, but building them together was a chore. There was version drift between the repos, and endless npm link dances just to test a change that touched both. The build was old, I could not even run the thing on Apple's ARM-based processors and the engine had very poor test coverage.

I did not just want to get it running though. I wanted to finally bring to life so much of what I had dreamt about before.

The goals

I had a few clear goals in my head:

• Modular Monorepo – The engine was always meant to be its own reusable thing but it was off in its own repo. This made integration between the engine and its first game brittle and hard to manage. What I lacked was a single workspace where the engine and game could evolve together, with the boundaries between them enforced by tooling instead of hand-wired across two repos.
• Modern tooling – A proper monorepo built on pnpm, with Vite for builds and Vitest for tests. This replaces the aging create-react-app setup I had carried for years. The payoff is fast feedback and single-version dependencies, with no more toolchain archaeology.
• Covered by tests – A modernisation this aggressive is only safe if you can prove nothing broke along the way. I was tearing the engine into many packages, swapping the build tool, bumping rendering-heavy dependencies, and upgrading three-nebula (which I also maintain and needed to upgrade in tandem) across a major version. A real safety net was not optional. It was the single thing that made the migration possible at all. The centrepiece is a visual-regression suite that drives the engine and diffs every rendered frame against a committed baseline, so a shifted pixel gets caught the moment it happens. This is possible because of a deterministic game clock. The whole simulation advances off one clock, so pausing it and stepping it by fixed amounts (paired with a seeded RNG) makes even particle effects reproducible frame for frame. Determinism turns "looks fine to me" into a guarantee you can actually check.
• Ship a real game to many platforms – Project GoldScript's aim is to ship a game to Steam, mobile and hopefully consoles. In order to take advantage of the advances in frameworks designed to help distribute and build for multiple platforms, the framework it currently runs on (NWJS) has been completely decoupled from the engine itself. Tauri is probably a better choice nowadays, and a migration to it is on the cards in the near future.
• Clean, operable interfaces – This one is new for 2026. I have been building the whole modernisation alongside an AI agent. A codebase that an agent can navigate and operate turns out to be a codebase with clean interfaces and real tests. Building for AI-operability turned out to be the same thing as building for maintainability, which was a pleasant surprise.
• Better tools – AI has made shipping internal engine tools much faster, letting me prototype and ship things in a few short sessions that would have taken me weeks of full-time effort before. This means I can enrich my engine's toolset at a fast pace.

What actually got done

So far, the modernisation has come together in a few big pushes, each getting its own post over the coming weeks:

• Becoming a Time Mage. Before I dared touch anything, I made the engine's clock fully controllable, a single time source the whole simulation runs off that can be paused and stepped by fixed amounts. On top of it I built a visual-regression suite that drives the engine and diffs every rendered frame against a committed baseline. It is the reason every other push on this list was safe to attempt.
• Wiring it all together. Two separate repos on aging deprecated tools became one pnpm and Vite monorepo. The game and engine now live in a single workspace, the boundaries between them enforced by tooling instead of hand-wired, and the engine is layered into eleven focused packages with a guardrail against circular dependencies.
• Real particle effects. I built a particle abstraction into the engine on top of three-nebula and used it for two things. The first was combat VFX like a proper combust and fire effect. The second was a map-level atmosphere system for weather, with snow drifting over the terrain and rain streaking across the field.
• The Effect Designer. This is the feature I had dreamed of ever since creating three-nebula.org and its editor GUI. Instead of authoring effects in a separate tool and exporting JSON, I built an adapter on top of websockets so the Nebula editor could wire directly into the game's toolset. Because of this, you can design a VFX in place, live, on the actual map.

Where it's going

I'm trying to build an engine for a very specific type of game which I have loved throughout my life. From my very first playthrough of the Krynn saga through to Final Fantasy Tactics and Baldur's Gate 3, tactical RPGs have been a huge source of fun for me.

I don't know where this latest push will end, but I'm happy to be back on the horse at least!

When it was originally released, FFXII got a lot of flack for the Gambit System. I believe a lot of that discontent came from players who felt that their loss of control over every combat action, which the more traditional ATB system gave you, was too much of a drastic change.

However, PC gamers were very used to this kind of combat. Some of the most beloved RPGs of all time – the Infinity Engine games such as Baldur’s Gate, Icewind Dale and Planescape Torment – carved their place in history by taking the classic turn based combat from Dungeons & Dragons and flipping it on its head with a system that’s become known as “Real Time With Pause” (RTWP). In this system, players can pause at any time during combat, issue commands to their units, and then let the battle play out according to their carefully crafted plan. It was a direct byproduct of the engine starting out as being built for RTS games. Pausing in the thick of battle allows you to change your tactics on the fly and it’s a mechanic that was so loved that it has lived on today in modern hits like Dragon Age: Origins and Obsidian’s Pillars of Eternity series.

When comparing the two, you start to realise that the Gambit System, which allowed you to interrupt your gambits to intervene when your plan started to go awry, is very similar to RTWP. You are just constructing your plan ahead of an encounter. I wasn’t a programmer when I played FFXII for the first time, but I believe that it introduced me to one of the most fundamental and powerful features of any programming language – conditionals. Because at the end of the day, the Gambit System is basically a high level programming language that allows you create a matrix of conditional statements which determine the AI behaviours of Vaan and the rest of the gang.

Some people found this boring, they felt like they weren’t in control, but I found it really satisfying. Now, I’m a turn based fan through and through. I think The Temple of Elemental Evil is the pinnacle of Dungeons & Dragons combat in a video game. Final Fantasy Tactics is in my top 5 games of all time. But I still found the Gambit System incredibly fun and to this day, FFXII is still one of my favourite games (I dream of a day when I have enough time to play the remastered version). Because of this, I looked to it for inspiration on how to rethink AI in the GoldScript Engine.

(Dragon) Scaling My AI

A few months ago, after I had finished the bulk of the Encounter Designer work, I began to want to set up some encounters and watch my AI fight itself to see how my combat and stat system was really working since there is a good amount of RNG going on and it’s hard to get a feeling for how combat in the game might actually play. At the time, I only had a single AI behaviour and it was basically a procedurally written function. I wanted to write more behaviours but I immediately felt like it was going to be crappy to have to write every thought process of the behaviour each time. What about common aspects of behaviours? What if you wanted a generic set of rules for a unit to follow and then just pepper those with some customised ones? I’d be violating DRY all over the place and it would become really messy. It simply wasn’t going to scale.

I had a good think about it and eventually decided to implement a Gambit System type pattern for my unit AI. This system, which I call the Strategy Tactics System (very generic, I know) basically works like this:

• Each unit has a strategy which is composed of an array of tactics
• Tactics are composed of two objects, a target selector and an action creator
• When a unit gets a turn, the strategy loops through all of its tactics and attempts them
• An attempt consists of calling the target selector’s select method to find a target and then passing that target to the action creator’s create method (as well as other arguments)
• The action creator will try to create an array of objects, each of which conform to an internally validated standard I call an AI Standard Action or ASA for short. The reason it is an array is one of the key differences between the Gambit System and the Strategy Tactics System – movement & pathfinding. In FFXII, a character’s position was never a factor, if a target could be selected based on the first condition, the assigned action would always get executed against it (as long as any consumable stat or item required was available). That’s not always going to be the case in a tactical game, you have to consider the grid and whether the unit can actually move to where it needs to be in order to perform the desired action
• To achieve this, the game package exports a Strategy class that the engine instantiates whenever an AI controlled unit gets a turn. All the dependencies are passed into the class constructor and a single public API method, getActions, is called which returns an array of ASAs which are then synchronously performed as a single promise chain

This is now all completely functional and working in the engine. What else is cool is that I’ve wired in UI for composing AI into the Encounter Designer so that map designers can craft whatever AI strategies they want for their units. Right now, there are simply sets of premade behaviours to choose from, but in the future it will be possible to mix and match tactics.

I know your search for the rarest of treasures, updates, has been arduous. It’s probably led you into an entirely new fetch quest and you’ve ended up having to get crafting materials to craft the materials for another fetch quest but fear not! I am here to bestow upon you a gift from the gods themselves, the mythical Encounter Designer. Legend has it that this sacred tool allows those who wield it to swiftly design combat encounters in the GoldScript Engine, save them, and reload them for further editing at a time that is of their choosing!

Ahem, yep, that’s right, the Encounter Designer is finally finished and while it may not be much to look at, it’s a pretty cool milestone and one that took me a crap load of time to get to. I’ve been on this thing in my very little spare time, on and off for about six months. To be honest what made this more challenging than other tools was the architecture of the data structure and the desire to make this tool truly modular. So here’s a little bit about how it works.

Combat maps now have a nested Encounter property that contains all the data required to load units into a map. Units are sorted into teams and defined by what the engine calls profiles, which are basically character sheets in code. You can configure everything about the units via the Encounter Designer itself and all of the options are imported into the engine directly from the game module (which is a separate package / repo altogether). Here’s a brief list of the things you can do with the Encounter Designer

• Edit the Encounter name
• Add as many potential teams to the encounter as you like
• Place units on the map on specific tiles
• Sort these units into the teams available
• Edit each unit’s name
• Edit each unit’s archetype (job/class)
• Edit all of their stats
• Edit all of their equipment
• Edit all of their skills
• Set their initial facing position
• Move them from one tile to another after placement
• Set their AI behaviour type

After you’re done editing to your heart’s content, you can simply save the encounter to a new file. When loading again, you can simply launch the tool again to edit, or run the combat simulator to play your designed encounter.

In the video you’ll see me actively playing an encounter I’ve designed. Granted there’s a huge amount of stuff missing, units don’t actually take any damage yet, so no one can actually win. There’s also no skills or anything super interesting to play around with and the current game module exports a very limited equipment set. Like I’ve always said, everything is about laying the foundations for something cool right now. I won’t be getting deep into designing content until I know the engine is as fit for purpose as it needs to be.

Luckily this is one nice step forward on that journey!

That’s all for now, the next post will most likely focus on the rewrite I’m currently doing of the AI system to something that is far more modular and composable. Until next time…

This month, I was lucky enough to be able to give a talk about creating games with JavaScript and React to an audience made up of predominantly web developers and it was a great experience. I tried to impart all the stuff I’ve learned about building games with these tools, the challenges I’ve faced and even demoed a bit of Project GoldScript. The response was really positive overall which was super cool. 

My wife came along and provided moral and iPhone video support so I’ve uploaded what we got to YouTube. It’s not the best quality but I think it’s decent enough to share, you can find the slides here. Might invest in a GoPro and a tripod if I end up doing more of these. Many thanks to Jess Telford for the photo. 

In engine related news, I’ve finally finished the Encounter Designer tool which has taken a huge amount of time and effort, particularly on the React side of things as the data for this tool is quite complex. I should have a new post up soon, so watch this space!

Up until now, all the combat maps had the same lighting configuration and it was hard coded. It was just something I put there to make sure that lights actually worked.

A couple of weeks ago, after working on 2D combat UI, I decided that I wanted to change this, but I needed a nice GUI to be able to do it. Something with sliders was absolutely necessary because with an isometric camera in 3D space, it becomes very hard to understand what’s going on with objects in the scene very quickly. The best outcome would be something I could just play around with like crazy until I got the look I wanted, and then save it.

React dat.GUI

I looked to many of the various Three demos for inspiration and of course remembered dat.GUI, Google’s cool little GUI app that is used for almost every single WebGL demo. It fit my use case pretty much perfectly. One catch though, it was made a while ago and while the code is very well written, it’s still vanilla JavaScript and jQuery. This wasn’t going to play nice with React, so I did a quick search on GitHub and found that someone had already started a React port. The code looked good and solid so I forked it and finished it off.

After doing that, getting it into the engine was a piece of cake and I quickly got to work on my LightEditor component. Here’s what the final result looks like:

There’s currently three lights in a scene, an ambient light, a directional light and a point light. These can be moved around and configured however I like, I can also change the colour of the light source which allows from some pretty sweet moods when paired with the background gradient. 

Pretty happy with this result, I think the next step is going to be getting back to the TileEditor and giving the dat.GUI treatment so that I can create levels way faster. I’m getting a little tired of using the same level all the time so I might try to create a new one with improved editing tools.

Until next time!

This is something I’ve never really had to think about before, so the challenge was real. I’d made some preliminary attempts and got something going that worked most of the time, but it wasn’t fool proof. I needed to make it better.

These thoughts managed to manifest themselves in the form of a fairly significant refactor of how the camera responds to viewport resizing / screen resolution and also the implementation of zooming. It also cleared the way for the current contextual combat UI components to work well at any supported screen size or zoom level.

Scalable Map View

Sometimes called a “Scalable Playfield”, this is a camera technique that is often used by the RTS genre. Basically what it means is that, rather than scaling the entire world to be proportional to your screen size, your field of view simply expands or contracts. If you’re playing at a higher resolution you see more of the map than if you were playing at a smaller resolution. You can see how this is working here.

This was a pretty crucial step for my combat UI. Before this, the world would always scale proportionately to match the screen’s aspect ratio. It worked, but it would mean I would have had to build a UI that would look consistent at every single possible size. I didn’t think it was really feasible and to be honest I couldn’t think of a good way to achieve what I wanted.

This doesn’t mean the world is always the same size visually though. Naturally you may want to be able to see things a bit more close up or from a distance to plan your moves better. For this, I’ve implemented zooming which is currently handled through the mouse wheel.

Enhance! … Dehance Dehance!

Zooming wasn’t hard to implement but it really is a necessary feature for these kind of combat maps. If your default zoom level is quite close, it’s natural for players to want to see more of the map at times and for that you need to be able to zoom out.

It’s also very handy for impactful combat animations. Regular attacks may not use it but some special attacks will be able to zoom the camera in and out to really punctuate what’s happening.

Contextual UI – Radial Actions Menu and Feedback

The radial actions menu was discussed in my previous post, but it’s now functioning a whole lot better than before. From a visual perspective, it’s now sized correctly for all supported zoom levels, it will also remain in the correct position if the screen is resized.

Combat feedback, the text that appears to give the player feedback on what has happened as the result of an action, has also been completely rewritten to support all zoom levels. 

You can read a bit more about the feedback stuff on Imgur.

All this was made possible due to a significant refactor of how I’m handling DOM animations in the engine. Previously, I’d created my own DOM animation class which was a wrapper around animejs to add Promise support. The library supports them natively now though so I rewrote the way I was handling this. Each animation effect is now it’s own sub module inside a component module. This keeps everything neat and localised. Here’s what the directory structure looks like for the Feedback module looks like now

That’s all for this time. October is going to be a cool month as I get stuck into figuring out a way to make the lighting of a scene configurable and saveable.

I had an idea for a completely different (and basically totally unrelated) web application venture around the end of 2014 and had a very busy 2015 where I spent most of my (very little) free time working on that project. With that app gearing up for an alpha launch hopefully in the fourth quarter of this year, I came back to devoting more time to the engine and its first game in 2016. I’ve continued that same work this year when I have had the time.

To be truthful, taking breaks from the codebase has been incredibly helpful. I was able to look at the decisions I made and the structure I implemented with a fresh pair of eyes and from a more experienced vantage point. What is really encouraging though is that, even after a good amount of time away from it, my belief and passion for the project is still as strong as ever.

After returning to the engine, I realised that code wise, everything was mostly fine, but it needed a hefty refactor to really make things robust enough to keep pushing forward. So I buckled down and began polishing the code. I mean really polishing. As a result my change log in between the last updates and now has become gargantuan. This work I’ve put into making the code cleaner and more structured has made it more efficient to add new features to the engine, so it’s definitely been worth it.

I’d split the changes into two categories, features and code. Features are most likely what non-programmers would like to know about so I’ll go through these first. Keep in mind these features are all related to combat which is the first of the three main modes I plan on developing.

Features

AI

The ground work for the unit AI manager and behaviour engine has been completed. This means I have a basic framework which enables me to build different behaviour patterns. Units can have preset behaviours and these can be altered at any time based on situational changes.

So, a unit might have the set behaviour of “Terminator” (destroy the weakest reachable foe) but if they have team mates who are below a certain HP level and they have healing items or abilities, they could alter their behaviour for that turn to “Saviour” (heal injured friends). This is just a simple example but illustrates the flexibility I now have to build unit behaviours which have ranges of intelligence.

Teams

Units on the map can now be split into different teams. There’s currently no limit on the number of teams. Technically there could be a battle between 4 teams or whatever, which has pretty cool implications for encounters that differ from the usual formula. It also opens the door to some really interesting possibilities in terms of network play or PvP.

Maps

I’ve confirmed the validity of my combat level/map building process. This resulted in me removing texture mapping from the engine entirely as this feature is far better handled by third party tools. It simply makes no sense to spend time reinventing the wheel and my time can be better spent on other things.

Here’s a short walk through of how the flow works:

Tile Editor

Here’s an example of a raw map. This has been built within the engine’s toolset. It’s just 3D blocks at the moment with basic materials. Shadows are cast in-engine:

Textured

Here’s what the level looks like after it’s been exported out of the engine, loaded into Blender, textured, exported out of blender as a single mesh, then re imported back into the engine (yeah, the shadows are gone, this is a bug at the moment, something to do with materials):

The new flow involves me creating what are called “base tiles” in the engine where I can apply meta data to them (depth, terrain, traps, treasure etc.,) and modify their vertices. I then export these tiles as a file type which Blender can load. I have no idea about 3D graphic texturing, but with a bit of help and watching some tutorials, I was able to get something done as a quick proof of concept.

To test this I’ve migrated the Dark Orbonne Monastery map, which was created in v0.0.4 of the engine (I’m on v0.0.13now). This took a bit of work as the data for what defines a level has changed a bit since I made it. To make this work, I wrote a simple map migrator tool to deprecate/propagate map properties and then reloaded it in the current version. It worked like a charm!

Depth

Tiles can now have a depth property which will cause units to “sink” a little bit into them. Quite useful for terrain types like water or lava.

Camera

Cameras are hard. This is something I’ve learnt continually throughout this project. I have to give a massive thanks to my good friend Manthrax who’s helped me out a lot here to get my camera code spot on.

So! The camera now has a kind of in built AI. What this means is that the camera will auto position and rotate itself to ensure that the current combat unit is not occluded from the player. This was a lot harder than I thought it would be, but the result is working pretty well now, perhaps a little too well!

Right now each tile has a camera quadrant computed for it on map load. A single quadrant means that the camera rotates automatically very often, it can be slightly disorienting, so perhaps a list of acceptable quadrants would be better. Then if the camera is already in one of these, it can stay put.

In any case this was immediately essential as soon as I implemented AI and the first bits of combat UI.

UI

Radial Menu

Yep, that’s right, I’ve made the first steps towards a combat UI with the implementation of a radial menu for combat actions. I’m pretty happy with this. It’s by no means designed to completion, but it’s functioning well.

However, it raises some questions about screen resolutions and adaptive user interfaces. As a web developer, on the front end everything I do is almost always 100% responsive. Good web applications have to deliver a consistent user experience across a hugely variable set of devices, each with their own screen sizes and resolutions. This is of course true for games as well, but it’s not something I ever really thought about until I tried to make one!

Right now I’d like to be able to deliver this kind of user experience in the engine as well, so I’ll need to come up with ways to do that. I’m not sure right now if the typical web solution of CSS media queries will suffice (but perhaps they will). The radial menu’s ring size, and its icons will need to adapt to the player’s screen resolution so that they remain consistent and don’t hamper the player experience.

Feedback

When units cast effects on other units, the player needs to know what the result of that cast was. In the engine, this is called combat feedback.

There are currently four types of feedback:

1. Info – for informing the player of general things like if a hit roll has failed
2. Damage – for informing the player of the damage an effect cast has caused
3. Buff – for informing the player of a buff that was applied
4. Debuff – for informing the player of a debuff that was applied

I’ve only got animations and styles for the first two right now, but it’s not a lot of work to add more.

Sound

Sound has been implemented, anything in the engine can now trigger a sound to play, combat levels can have a BGM set which will play when the level is loaded. I even made some sound effects and got the track I wrote for the Dark Orbonne Monastery tech demo loaded in as well.

Actions

Previously I had only completed the Move and Wait actions, but now Cast has also been done. Cast is the action used for basically everything a unit can do to another unit in their turn, so attacking, casting spells or using items – these are all casts. The Castaction relies heavily on my promise based animation classes which I talk a bit more about in the code changes section.

Motion

In previous videos you might have seen some awkward jumping animations, back then these were done in a kind of hacky way. Now I’ve implemented proper animations for jumping, hopping and falling with the shadows perfectly matching the surfaces the unit moves across. Once again a big thanks go to Manthrax for the help in integrating linear interpolation to get the movement working smoother!

Toolset

You might notice from the screens that I completely redesigned the toolset interface. The new design looks more like a traditional desktop app with a file menu and toolbar kind of like other editing programs, it also gives me a lot more screen real estate to see what’s going on. This is assisted by draggable dialog boxes which come in handy especially when dealing with an isometric world.

Retina

The engine now supports retina displays. This was a fairly easy thing to implement as Three supports it as a property of its WebGLRenderer class, but is pretty cool nonetheless.

Code

Okay, you ready? Now for the code updates, full of JavaScript nerd speak, you have been warned!

ES6 / ES2015

The entire app has been completely refactored to use ES6 / ES2015 language standards. This is made possible through awesome tools such as Webpack and Babel.

This means that the code style has been updated to modern standards and all linting is now handled through ESLint.

Oh and everything is module based now as well!

React + Create React App

All DOM based 2D UI is now done via React. This has been a massive improvement over what I was using previously (Handlebars). There are tonnes of awesome components to leverage and since I personally love React, it’s been great to work with it on this project.

I’m also using create-react-app as my boilerplate to handle all my Webpack config.

Decoupling game code from engine code

The GoldScript Engine is being designed in a modular fashion. Think of it like an OS which you can install software on. In this case the engine is the OS and a game is the software.

My game package is a separate repository and is pulled into the engine via npm.

So, how are these separated out? Basically the game defines things like combat rules, combat effects, unit statistics and so forth. The engine doesn’t care about any of this. It simply runs the formulas it receives from the game to figure out how an effect cast might turn out. The game package also contains all the static assets (art, level data, sounds etc.,) that are needed for the engine to run the game.

This has allowed me to cleanly separate different kinds of logic and basically means that making different games for the engine should be easy. Simply create a new game package, import that into the engine and, as long as the game has all the required methods, it should run.

Environment

The development environment for the engine is now handled through my NWJS custom command line interface package Northwest.

This tool allows me to run the latest version of NWJS and gives me commands to publish the engine/game for Windows, Mac and Linux.

State

I wrote my own Finite State Machine which basically runs the entire engine now. Every machine is also a container for more machines, it’s basically a recursive pattern.

This has given me absolute control over what user inputs do between every possible state the engine can be in.

Animation

All animations in the game are now handled through Promises. This has given me an awesome, readable API to work with when sequencing anmiations.

My animation class also handles frame based animations, which is perfect for sprite sheets.

Three r69 to r86!

This was massive. For anyone that works with three you’d know that this is a pretty experimental framework. Breaking changes happen all the time.

I jumped almost 20 versions ahead. I know, madness right?

It wasn’t TOO bad… well it was pretty bad. But I got through it and learnt a lot in the process.

Overall it probably took me about a month of part time coding to get everything ported.

It was well worth it though. The latest version gives me access to all kinds of cool new features and improvements, so I’m happy I bit the bullet and got it done.

Wrapping up

I hope you enjoyed this update which was like… 3 years in the making? Sigh.

I will try to blog more often… but the problem is it takes time, which is my most precious resource right now. This blog alone took me a pretty hefty amount of time to write and put together. I do realise it’s important though so I’ll try to make time for it.

It’s been a crazy ride so far, but I’m still having heaps of fun, so I’m not giving up yet!

Next up will be sorting out my adaptive UI concerns, I don’t want to move too far forward without a solid solution for this problem.

Until next time!

While I had showcased a basic version of some of these features in a previous video what you’re seeing here is light years ahead in terms of code and of course, three.js powered, so let me go through all the core points of what’s on display here and tell you a bit about them.

Sprite sheets

Currently I’m using a Geomancer from Final Fantasy Tactics as my test sprite. I created a sprite sheet for the Geomancer’s walking animation, which is basically 8 frames in total and made animation methods to handle the offsetting of this sheet along at specific intervals to create the walking animations you see. This also includes the ‘back facing’ frames, and a nifty bit of code that flips the sprite based on its vector in comparison to the camera position.

The sprite sheets are handled in a scalable manner, all the data is set within the unit’s data object so swapping this sheet out for a custom made sprite is incredibly simple. The only requirement currently is that the sprite be isometric and have forward and back facing frames. Some tweaking may be required in terms of height, but that’s quite trivial.

Another aspect to these sprites is the use of an amazing library for upscaling images – js-hqx which basically allows me to upscale the sprites at runtime if needed. This is a powerful feature for supporting a wide variety of displays.

I haven’t bothered to add jumping frames to the sprite sheet, because this is all placeholder stuff for now, but again adding such things is easy and would just require the writing of a new animation method to slot the sprite sheet offsets in at the correct frames in the animation sequence.

Unit shadows

Okay, I’m not going to lie, this was hard. The truth is that the spot shadows (as well as the sprites) are illusions trying to pull off tricks inside a 3D world. Because of that, you’re always going to run into issues here and there where the two worlds collide. Luckily three.js has a sprite geometry and material type that makes handling them fairly easy, the shadows however are something different altogether.

I’m currently achieving the effect by using a circle geometry that is flattened to the surface normal of the tile the unit is currently on. There’s a bit of trickery going on when jumping or falling to fake the fact that the shadow should stay on the ground but all in all I think the result is pretty good. I’m not entirely sure how other games have handled this feature, but if you want to support a wide variety of vertex possibilities for your tiles, it’s not easy to get this looking right. Using the method I am currently sort of prohibits me from supporting tiles that have non planar top faces. It works, but some ugly clipping happens at times. I can fix this by bumping the shadow up the y axis a bit though, so that’s a possibility for now.

In my opinion, the true solution to this problem would be to have a directional light pointed from above, covering the entire world and directed at a vector of y:-1. Each unit would have an invisible circle geometry attached to it that is always placed at the unit’s waist. This geometry would cast shadows, and would therefore yield actual real world shadows that are responding to light correctly. However, I can’t implement this solution just yet because firstly, three.js doesn’t seem to support multiple directional lights in one scene and secondly I cannot select which light the geometries would cast shadows from, so they would cast shadows from every light source in the scene. Isometric worlds need directional light to give them dimension, so I can’t really take the current one out, but if I decide to bake shadows in Blender then this solution is viable. I’m not far along enough in the pipeline to make that call yet though, so I’m leaving it for now. I’ll come back to it when some actual level design or art assets have gone into production.

Movement & pathfinding

This is the fun part, making the little guys move! There are four basic movement types so far, walk, jump, fall and hop. Each step of a unit’s path sets a movement type is defined by a set of parameters and then performed. I’m currently using Pathfinding.js for my A* algorithm, however I am considering dropping it as it currently does not support cost natively, which is a fairly fundamental feature of any A* algorithm. Each unit has a stride and leap score which determines how far they can move both horizontally and vertically.

Rounds & turns

Programming in a turn based system was really fun and exciting. It made this demo feel like a real game. Let me explain a bit about how rounds and turns work in the GoldScript rule set. Each unit has a speed score, and at the beginning of a round, all units are sorted according to this score. The round steps through each unit, initialising their turn which only ends after they choose the wait action. I plan to implement action points (AP) in my rule set, so each tile move will cost 1 AP, that’ll be the next feature added however, so it’s not shown in this video. All in all the whole process works quite smoothly now.

AI

I’ll admit it, AI scares me a bit. Especially for an RPG where the tactical combat needs to be challenging yet beatable. There are so many possibilities to think of, each unit will have a variety of skills to choose from, and defining which skills which unit will use and at what time is going to be a big chunk of work. Possibly I can funnel this through a path finding algorithm, but I need a process first. What you’re seeing in this video is a very primitive implementation of that process. When the units are loaded into the level, I randomise their stride and leap scores, so each time I run the demo, each unit has a random score for each of these stats within a range. The movement choice and picking methods are then run each turn, passing a random choice from the results which the path finder deems as valid. Directional facing on when the wait action is selected to end a turn is also implemented, although it’s also randomised so they don’t always do it in this demo. Switching between player and AI controlled units is done automatically, if a unit has AI disabled then control passes to the player, simple as that. You can see this in the video when one of the sprites is controlled by me, the UI for the actions menu is 100% placeholder at the moment and is just something I did for testing. I’m still not completely sure on how I’m going to handle it. I have keyboard shortcuts already implemented (‘m’ for move, ‘w’ for wait etc.,) but I’m considering something like contextual radial menus for the GUI. Since the engine is being developed with PCs in mind first, I need something which is intuitive for this audience. FFT’s UI would fail here, but I also would like to avoid having to use a HUD so it’s a tricky one. I’ll probably have to prototype a bunch of options before choosing one. I may even put an online demo up and ask people to help me decide. 

Phew, that was a lot of work. It took me all of November pretty much to implement these features in my spare time. Special thanks go to @MarbleBucket and @Okonomiyaki3000 for their help with sprite directions, shadows and animations respectively!

Next up will be an implementation of an action points stat and factoring this in to movement choices.

To tell you the truth, I’m kind of amazed I achieved it. Before even starting I made a tonne of assumptions about my pipeline that, incredibly, turned out to be 100% true. If you are a programmer, you know how rare something like this can be.

However if you are a programmer, you also know that nothing ever works the way it’s supposed to right off the bat. The video above is the result of two weeks of hard work, understanding and debugging JSON exports from the engine, which were then imported into Blender, and finally back again. It was frustrating at times as Three.js is still a little experimental, especially in the area of exporters and importers. However, with the help of a new friend I met on Reddit, @MarbleBucket I was able to work through all the issues and finally ended up getting a fully retextured, and reimagined Orbonne Monastery working in the GoldScript Engine. 

Oh, I also had to teach myself Blender in about 3 days, which I somehow managed to do. The texturing work is probably pretty crummy from a professional’s point of view, but I was happy enough with the result to feature my mesh in a short tech demo and write a short but deadly sweet piece of music for it.

Textures and music weren’t enough though, so I thought it was a good time to get the particle system implemented. One thing that I think all of Yasumi Matsuno’s games had in common, was an absolutely kick ass implementation of particles. The spells and effects in both Final Fantasy Tactics and Vagrant Story were phenomenal, and have aged remarkably well. To me they still look fantastic, even by today’s standards. A huge part of that would have been the particle system they used, and naturally some uber physics programming. Combining the possibility of effects like this with modern GPUs is something that makes me pretty excited. 

This is a bit of a milestone for the engine and means that in terms of level design, the sky is now basically the limit. Blender is an incredibly powerful tool that allows me to create pretty much anything I want. The fact that I can get those meshes back into the codebase means that GoldScript Engine combat levels can have a great deal of detail and complexity.

One interesting thing to note is that I used pixel textures for the level you’re seeing in this video. However, I also did a version with a bunch of free high resolution textures which also looked pretty good, but I felt didn’t do the concept of recreating Orbonne Monastery justice. I might share this version in the future. 

Next up will be implementing some shaders for movable tiles and targets, so watch this space for more soon. Hope you enjoyed the video, happy Halloween! Special thanks to Sachi Coxon for the speedy Japanese translation.

When it comes to isometric, grid based combat, Final Fantasy Tactics really set the bar high. One feature that was so revolutionary at the time was allowing players to rotate and tilt the camera. Unlike Tactics Ogre and other strategy RPGs that came before it, Final Fantasy Tactics’ combat levels were fully 3D worlds with two dimensional sprites positioned inside of them.

This allowed Square’s level designers to really go nuts and create some unbelievably awesome combat levels. They didn’t need to worry (too much) about units being obscured from the player’s view. Player’s could rotate and tilt the camera at will to view and target units if they were behind or in between level objects like pillars, trees or rocks. They even improved on this for the iOS version allowing almost total control of the camera.

When I first started building the GoldScript Engine, I was unable to do this as I had chosen a cool yet non Web GL enabled HTML5 renderer to do the job. After switching to three.js however, I knew that achieving the perfect blend of 3D and 2D was achievable and were determined to make it a reality.

So after a couple of weeks of refactoring code, here we are – fully 3D rotatable/tilt-enabled combat levels.

In truth, I actually was not aware of how far HTML5, and its ability to create fairly nice graphics in the browser, had progressed.

I was deep in the world of web development, working with front end and back end technologies together with various APIs / frameworks to deliver web development services for clients (which of course, I still do to pay the bills). I was working with HTML5, but not so much with canvas and while I have some experience with Flash and Actionscript 3, again this was for client work.

I got to work with sheetengine, and with a bit of help from its awesome creator Levente, modified the source code in many areas. I built my own ways to add textures to tiles, map sprites to sheet objects (as they are called in the engine) and wrote a json read / write class which combined PHP and JavaScript to read a level matrix and load it based on its data. I developed methods to quickly add blocks of varying heights (there’s no geometry methods in sheetengine, a cube is made of 6 separate objects which need to be positioned individually in x, y and z coordinates as well as euclidian rotations), integrated pathfinding and got a proof of concept done as fast as I could. It was arduous work, but it was pretty rewarding and I got heaps of JavaScript experience points.

But I got to a point where I was pushing the limits of what the renderer could do. There were a few hacks that were necessary to achieve what I wanted, and these were causing other issues. I got a sinking feeing that I desperately needed a different solution, and it was around that time that I began reading up on node-webkit. I quickly realised that this solved a multitude of issues for me

• This meant that my game would no longer need to exist online
• I could now ship the game as an executable for PC, ie., Windows, Mac & Linux
• It meant I had access to the client’s file system, meaning file size limits were now basically meaningless
• Since the WebKit engine was being used, browser differences disappeared and Web GL was now fully available to me

I continued with sheetengine for a little while, developing a new, more refined iteration of the level builder. Soon enough though, I realised that I didn’t need to care about my game being purely HTML5 and with Web GL now accessible, I could basically do whatever I wanted.

Here comes a new challenger! Three Js == Shenglong

So I started looking around for different rendering engines and of course found three.js, which I had known about for a while, but thought was just too difficult for me to learn. Well, it looks like I had levelled up considerably and gained some OP skills, because after a day of mucking around with it, I had an almost identical isometric level created. At that point, I knew that this was the right decision and began, once again, refactoring all my code to work with this new, awesome renderer.

Fast forward to today and we are very close to being right back on track, and have of course added things that were not present in the previous codebase like the ability to rotate and tilt the camera.

While I don’t plan on changing the renderer for this iteration of the engine, I’m trying to make the code as modular as possible so that swapping it out for another would not be as painful as it was before (although in all honesty, it has only taken about 2-3 weeks of hobby-time development to get back to this point). 

The engine is stronger and better placed to deliver games to better platforms now so I’m pretty happy with how it has all turned out really. Just goes to show you that while change might seem scary at first, if you are confident that you are moving towards something that is definitively better, you should probably take the plunge. You’ll thank yourself later (and maybe get some OP skills).

Pathfinding is also shown here, so the units know how to get to where they are going and avoid any obstacles that are in their way. We’re using Pathfinding.js for this, and it’s pretty amazing, definitely check it out if you have any need for a great JavaScript based path finding library. I’m sure the code could be refactored for other languages as well.