This month I worked on a lot of UI and stat storing stuff. So it was a kinda rough month!

JARPUG needs a sturdy foundation of numbers and stats to play well, and it needs plenty of UI, too! But I’ll try to share that schedule space with something that’s a bit more fun to work on in the future, because ouch.

Battle UI improvements!

I wanted a more hand-drawn style for the battle UI. That meant making a font out of my own handwriting, making hand-drawn nine-part button art, and implementing a wobbly line renderer!

Wobbly lines are implemented by scrolling through rows of a blurred noise texture and perturbing vertices accordingly. The blur serves as a baked interpolation between frame and adjacent vertices!

I ended up using Calligraphr to make separate fonts for text display and JARPUG’s very own icons font for stats and stuff.

The UI for picking battle skills is now about stances first, as all skills are specific to the character’s stance, any way. I hope for this to make that connection more obvious for the player, and it also serves as a spot to highlight the stat bonuses provided by each stance. I was nervous about having stats change based on stance as it could be restrictive. I’ve decided it’s worth the depth to try. It might work well with the right character/stance designs!

The battle menu also now stays within a maximum range from the player, so they can always read and poke that menu’s buttons in VR. Players still need to pan the camera to target enemies if they’re far from them, but can now stay focused on targets instead of physically scooting back and forth between menus.

I also implemented a battle initiative “next up” UI. This was a great way to find annoying bugs in my actual battle initiative logic. I spent a lot of time fixing those.

I made a little headshot system for taking photos of each character at the start of battle. It was a fun solution to the problem. I also plan to differentiate similar enemies with glamorous decor in the future. Then those headshots will make for a clearer UI!

RPG STUFF! Separating stats and skill code from characters

In the initial prototype, character skills and stats were separate classes from the actual character, of course! But skills and stats were still manually entered into the character, and JARPUG needs them to live in their own database that can be updated when players level up, progress in skill trees, and change their equipment.

So there’s now a separate “CharacterData” class for storing stats, skills, and eventually equipment. That’ll be punted around as needed to get characters ready for battle, populate menus with the correct stats, etc.

I plan to make this serializeable to json like much of the rest of JARPUG’s stuff, for save files and future mod-ability. I’ve kept their contents simple and numeric for that. Right now it’s just a pile of ScriptableObject assets I edit in Unity to define the default stats for each character.

I also updated stats to support any number of modifiers applied to them by character stances, skills, and equipment. And while I haven’t yet designed the leveling system, it’ll also be much easier to level-up and save stats now that they live in their own database.

I feel good about the decisions and systems I’ve made, but I’ve really slowed down in the last couple weeks. It’s tough for me to put in a lot of continuous time on design work. My schedule makes that physically difficult and that long design work feels more like staring into space than work. I move on to other things.

That’s dumb and bad.

When code design is hamstrung by game design

I can often get away with prototyping my way through the design of things I’m unsure of in game dev; especially in something more actiony and less numbers-based! But these are early days and this is the backbone of JARPUG’s logic and design. If I don’t design this, there’s not much else to do.

Design paralysis is at its worst when features require interlocked systems to operate properly. And there are many systems that hunger for crunchy algorithmic design in a JRPG. Stats, damage, leveling, skill trees, equipment, and all that other magic RPG sauce. That’s a lot of decisions that all interact with each other in fun ways.

From a design standpoint it’s also a lot of systems that could depend on each other in ways that make them difficult to change. Assuming I’ll make some bad design decisions is my usual approach. I make all of these different systems relatively modular. Then I can change parts of my design later if it’s not fun.

While throwing away things that don’t work is great, a discarded implementation still takes a lot of time and effort. One of the nice parts of working alone is that other people aren’t waiting on my design work. I can use this modularity to delay the implementation of huge scary tasks, like skill trees, until I’ve got time to make a good design.

And then I’ll sit down for those long hours and stare at the page, the scribble, the scratch, until it’s done.