Tyrus: posts

“September” Devlog. Ideally this would go up nearer the end of September than the middle of October. SEPTOBER IT IS. I was supposed to buckle down and work on JARPUG’s level editor. And I did!

But my game design and development workflow changed. My todo list got swole.

Also I got so mad at tumblr I made a new website for the devlog.

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.

This month I wanted to ensure that JARPUG’s battle mode worked well for multiple player characters. That required work on a few different things.

Character design for a new dog! GREYPOUND / BOLTHOUND

Like JARPUG / PUGJAR, this brave dog can shift between two different stances, wielding a car battery and sturdy antenna to get violent things done in an exciting variety of ways!

These characters have variable shoulder positions and widths as they’re created by a fairly flexible character creator. That makes two-handed weapons a complicated thing to animate! I ended up programming a weapon holding system that aligns my dogs’ noodly arm bones with bezier curves ending in the desired hand positions.

It’s no cure-all; I still need to be careful that the meshes following those bones don’t get mangled by these relatively arbitrary arm lengths and positions. But now I can share weapon animations across a wide array of dog shapes and sizes!

Battle design: Bending time, scampering dogs

In JARPUG you run around between turns before choosing the actions for your next character. It feels actiony and adds a nice layer of positioning strategy for avoiding attacks, grouping up for defensive spells, etc.

Running around in a turn-based battle is simple with a single character, but things get complicated with multiple characters. How do I ensure every character has enough time to run around between turns? How do I keep things from being too slow when every player character has move turns and performs actions in battle?

Most JRPGs with this sort of “run around on the field” battle action solve these issues by giving the player control of one character while AI teammates run around and choose their own actions in real time. That gives the games an actiony MMO feel. That’s not my goal for JARPUG.

In JARPUG I want players to run around between turns without giving up explicit control of their party. But I don’t want it to take forever or leave characters standing around hapless and helpless while you’re controlling someone else. I implemented new battle time and movement systems get that done.

Battle time system

To ensure every character gets a good amount of time to move without freezing the action, a new battle time system figures out turn order based on character stats and then adds gap times between turns.

So while the characters are all scampering and dodging in real time, they’re also guaranteed a minimum amount of time between turns for moving. I think it’s a pretty simple and intuitive system for players. Hopefully they won’t notice it much at all.

It sure was a pain to update everything from the old “active time battle” style system, though.

A nice bonus of this is that I’ve got an easy way to calculate the turn order for the next several turns and could show that in UI somewhere. That’s a personal favorite strategy element of mine in turn-based battles.

Battle movement system

Thanks to the new battle time system, I always know which party member is “next up” in the initiative and can give the player movement control over them until it’s time to choose an action. During that time they’re directly controlling that character’s movement and can also command their teammates to group/scatter.

The AI for teammate movement is as simple as I can manage. I want it to feel fast and predictable for the player. It’s not as accurate as individual joystick controls would be, but it’s simple and gives you quick ways to move teammates out of harm’s way.

I’d like to name those commands “shoo!” and “here doggy!”, but keeping this readable for VR necessitates things be clear without extra explanatory text. UI design is heartbreaking sometimes :(.

While it’s tempting to force “hard strategy” on the player by adding friendly fire for area attacks or “hazard zone” style attacks, the team movement controls probably aren’t going to be precise enough for that to be fun. Just avoiding enemy area attacks and trying to stay in “buff zones” should keep folks busy enough!

New battle background

The old battle background was tiny and complicated. I simplified it while making things more circular and spacious. I’ve still got some decisions to make about camera distance and battleground size, though. The current up-close camera feels great in VR, but it could complicate strategizing.

I think next month will also be spent working on battle stuff, with a dash of character stats injection. I’m hoping to create actual unique attacks for each player character and start doing a better job of differentiating their different stances, both in UI and gameplay.

Oh, first blog post! This is about my dev work on JARPUG. JARPUG is a JRPG starring a pug with a jar on its head, made for VR. Here’s some old footage from LVLUP Expo in early May:

That expo served as an excellent deadline for focusing on controls and gameplay after piddling around with various back-end systems for months before. My friends drove over from Phoenix to help, and people liked the game! I was able to make big tweaks to gameplay and get fairly immediate feedback. It was good.

Also, Japanese Curry Zen’s in Vegas. Jeez. Any excuse for that. A Japanese curry house is a wonderful thing and they’re the best I’ve been to.

About that game though

JARPUG’s gameplay style paddles in the same pool as many Japanese role-playing games. The player explores the world to find things and progress the story. They’ll run into occasional turn-based battles. JARPUG applies a bit of an actiony tilt to these ideas.

In JARPUG’s exploration sections, you’ll be able to jump around to explore the world and solve puzzles.

You can swap your brave pug from JARPUG to PUGJAR mode. At LVL UP Expo it was mostly useless while exploring, but now you can use it for various jar-based challenges!

Things like rolling down ramps to launch over gaps, floating through water, or just rolling over spikes. Standard jar stuff.

In JARPUG’s battles you can run your characters around to position them and avoid attacks.

A battle menu pops open when it’s time to do some moves. You can quickly tap your controller to use them or poke things with your VR fingers if you’re feelin’ wild. You can also swap to PUGJAR mode for a more defensive move selection.

It’s been like two months so

In the last month or so I’ve been working on things to improve puzzles in the world. Things like spikes, ramps, switches, and water are all new since May and should be a big help when trying to design interesting challenges for the player.

But the most important thing I made lately is a bunch of tools that make it easier to generate INFINITE DOGS.

Myriad puppers is certainly an appealing thing on its own, but it’ll also make level creation quicker. I’ve made things like dog size and dimensions editable, so I can generate those long dogs you crave.

I’ll try to make devlogs a monthly thing, but feel free to check my JARPUG tweets for more frequent, tiny updates.

Obviously things are very early, but I’m several months into this project. I’ve spent a lot of time working on back-end stuff like level editing tools and character creation. I’ve got other big editor tasks ahead of me still, but I plan to spend much of the next month working on improving battle mode. The current prototype is encouraging, but I want to be sure I can expand on those ideas and keep things fun with multiple player characters.