ALNEXUS
Devlog: ALNEXUS Simulacrum




Alnexus Simulacrum Devlog 01

Exhibition release!







Why this?

I wanted an engine that is focused on turn-based combat.
I am a big fan of turn-based RPGs. One of the favorite game series growing up, Final Fantasy, always stuck with me because of how simple and intuitive combat can be. It’s what got me into games and into game design.

There was just one problem.
There’s no easily accessible game engine that is dedicated to simulating combat.

One could argue that RPGMaker is tailor-made for this, but I’ve found that it’s mostly focused on the exploration aspect of RPGs, focusing on easier map-making rather than easier combat. I wanted a combat-focused game engine with stats, damage calculations, and turn ordering ready to go.
I wanted to make something I can use over and over again.Before Simulacrum, I have had a background making JRPGs in websites and one of my school projects, “Dream Arena”, was an earlier iteration of that idea.  At the time, I made it so I can finish the project as early as possible and submit it, as most students do with their assignments.

The problem about this is that I didn’t have the insight to make it as a project that I can look back and build upon. I made them with the mindset that they are assignments to be passed, not as projects that can be continued.

I wanted to build Simulacrum as an ongoing project that can be built upon as well as something that can be referred to to build something else.

“Dream Arena”
“Unorthodox”
“Melvin v. Picollo”

I wanted to blend the feeling of playing a game with making a game.When one thinks of game engines, one may think of Unity or RPGMaker. These are powerful engines, yes, but with that power comes with it a huge amount of complexity.
I’ve come to understand that systems that look daunting off the bat are not unnavigable, and a lot of exposed screws and buttons means its developers can customize whatever they want. There’s power in navigating complexity.
But there are people that like playing games and want to delve into them, but find the complexity of the user interface impenetrable. It can discourage them from getting into game design in general.

I wanted to make the approach more “enthusiast-friendly”, by mixing the aesthetics of the game with the user interface to make it look more familiar and be more intuitive.

Brainstorming in paper!


I got on this project knowing that it will be a huge time-consuming undertaking. I have had a bad streak in project planning where I aim for something good and ambitious in little under three months. “Dream Arena” and “Unorthodox” were unfortunately one of those projects. I have learned from these that, since I mostly work on raw Web-based code and not a dedicated application, making an operational and editable combat system and editor in a website in such a short amount of time would be laughably impossible.

But you have to start somewhere.
So I brainstormed.

When I work and brainstorm, I find it easier to draw ideas down on paper because I get to write and draw whatever comes to mind with no inhibition. My initial concept was more detailed functionality-wise, but for something just sketched in less than five minutes, it shows what my ideal version of Simulacrum would look like. I find it better to look back on it sometimes, thinking on what details I can add to my polished prototype next.  I harkened back to “Dream Arena” with its four-player setup. 

With visuals sorted out and with feedback from others, I then simulated battles that could happen in the game also in paper, starting off with a simple “here’s a player, here’s an enemy, player attacks enemy” and going off to more of the combat’s particularities like specific equipment and actions. The goal of these paper simulations is to find out the repeating formulas and structures I find myself writing down through these simulations. Those repeating portions of the paper simulation would become the foundational functions and objects in the digital program.

Drawn UI concept art of the website’s “Edit” mode, with displayed stats and equipment of a selected actor
Drawn UI concept art of the website’s “Playtest” mode 
A sample written simulation
Resulting paper cards, reflecting the contents of the simulation

My PC game’s stuck in console (log)



Graphics for the first digital iteration of the Alnexus

Transferring from paper to digital was not how I expected it to be. Transferring combat from paper to digital, I knew I had to make sure functions were working as intended so I tested it by outputting its results on the console log, refining them until they work as intended. Unfortunately, by the time I had to first present this work, I was focused on the proper function of the battle system that I neglected the aesthetics.

I also focused on showcasing function for the visuals. However, one problem I had was working with p5.js. I was  confident on using it to create the website, but it wasn’t made for something as extensive and multi-faceted as a game engine. A file that uses p5.js outputs a canvas element, so its output is one huge interactable canvas element. You can’t specify a certain item is being pressed easily making interactability more complicated. I used HTML buttons to create the basis for the UI, but it is limited to being the box and not the images I wanted up there.

Feedback was sparse, but ultimately as a school project I had to cut down on some mechanics to ease myself for the final draft and get the visuals going.




Divine aesthetic


It was obvious I had to make the visuals next. Initially, I wanted to reuse the “Dream Arena” assets for this project which meant using the same four players in the party, but a suggestion from someone in feedback paved the way for me going for a different approach to the visuals.

“Lean into the magicky divine aesthetic.”

I have had a penchant of drawing “the divine” before.  Throughout my artistic journey and in my process as a worldbuilder in high fantasy, I drew many iterations of gods and divinities before, mixing multiple inspirations from the scientific and the technological, to the surreal and otherworldly. 


I alluded to it before when I brainstormed the layout for the website with the initial backdrop being something that is tied to the otherworldly. Tying Simulacrum’s aesthetic with what I was already drawing before would be simple. I just needed to push it into the forefront of my project.

Planning out UI through a 24x18 grid of squares on CLIP STUDIO PAINT
An earlier iteration of the UI in-site, looking for function.
Creation process for Iota, one of the playable characters. It is a straightforward process for one of the first characters I wanted to draw.
Creation process for Katharyn, one of the playable characters. Hers was a more nebulous process that built off of prevous illustrations and sketches.


It also gave way for a challenge for me. Simulacrum as a combat RPG simulator has little to no story as you play. This is intended. It is in the player’s power to create and customize whatever battle they want to make. What I can provide as the developer are default assets for the playable characters, the enemies, and the background: all of which are visual components. In a “game” with little to no story, how can I set the setting of a story through the game’s visuals?

The best way I could go through it would be how the enemy designs and playable character designs look in relation to each other. I also put some flavor text alongside the characters that people can read, should they be willing to.

The Floating Throne and Iota, side by side on the default background.
The two Nephil enemies and Erae, side by side.

Building cogs



A machine is made up of multiple cogs and gears, turning to create complex motions out of simple rotations.
You don’t need to make the cogs inside the machine to see if it would work. You can get the cogs outside of the machine and configure the cogs there.

Why am I saying this?

In programming this, especially due to the multiple functionalities such a website would have to do, the program ended up having ~3,000 lines of code which was becoming harder to harder to parse through. I had to find a way on how to add more and more functionalities without having to comb through lines of code and CTRL+F every time.

That’s where the cogs and gears analogy comes into play.

I realized that I don’t need to pile in more and more lines of code inside this program to see if a certain functionality would work. Instead, I can make a mini-program focusing on that functionality, seeing if that works, and then transferring its code on the main program and adjusting as needed.

What’s better about this workflow is that these mini-programs are much easier to look for in the future. If I need a certain functionality I used in one big program, I don’t need to comb through it to find how it works. Instead, I can get it from a mini-program!

Sinusoidal functions for images fading in and out
Testing animation objects and functions
Testing slider objects


What’s next...?



This started out as my thesis for my graduating year, but I don’t intend for Simulacrum to stop at just that. It is a project I would love to use for my worldbuilding project so people can tinker and toy with the characters I have drawn up. However, I would also love to open 

There are exciting ways I could expand on Simulacrum. A mixed board-and-computer tabletop game? A full-on virtual game with tinkering the game state as the mechanic? A more educational website that helps developers finetune and balance their combat systems?

I honestly can’t wait for the future of Simulacrum and the whole ALNEXUS project!