next »

[Tyrus Peace]

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 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.

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 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.


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.

What I've been working on lately

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.

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.

[Chris MacAdam]

Lmao I love this it looks really great. It seems like it would be very fun to play, and the main character is gold IMO.
Keeping an eye on this for future updates.

[Tyrus Peace]

JULY! 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. Bye!

[Tyrus Peace]

AUGUST!
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 frames 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.

[Tyrus Peace]

"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.

OH NO I CHANGED THE CAMERA.

JARPUG's last demo had a free-moving camera that would slowly scoot along after the pug, teleporting to catch up if it got too far behind. I let players adjust the camera's pug-distance at will. None of the hundred-or-so testers reported discomfort. Yay!

But I noticed that moving sideways led to players spinning around and getting disoriented, especially if the camera had to teleport to catch up. Also, the demo level was relatively small and didn't have cause for backtracking. After testing backtracking out myself, I decided that getting dragged sideways and running a tiny pug through my own head repeatedly wasn't a great way to explore an RPG world.

Lazy Camera, Comfortable Player:



JARPUG's new camera is kind of similar to top-down 2D games. The world is now separated into 8x8 tile chunks with fairly obvious lines between them. The camera stays centered on the current chunk, rather than rubber-banding after the player character. The camera teleports to look at the center of the next chunk immediately once the player gets "far enough" into it. 2D JRPGs often did a fast "swipe" animation for this sort of transition.

That approach is a little too vomit friendly in VR, so I have a highlight that gradually fades out on the previous chunk, helping show where you came from.



The chief hope behind this camera design is that small, explicit level chunks will let players explore without reorienting themselves constantly, especially since they'll know when to expect the camera to move thanks to the obvious boundaries. An RPG map is a big place and I want it to be something the player can explore in a leisurely state. Looking around a JARPUG level in VR is still cool. I just don't need to require it.

OH NO I MADE LEVELS BIG.

Previously, I wasn't sure about how large to make my levels or how to handle camera transitions. I'd been considering a "toybox" style where the player moved from level island to level island, with adjacent areas disappearing whenever you moved. That would have been garbage for exploring and remembering where anything is.

This new camera design allows for large contiguous levels, which will be far more pleasant to explore. Those larger levels also make for a simpler one-dev workflow than a bunch of interconnected island-style levels.



Performance is a concern for large levels, but merging tile meshes where possible and organizing levels into chunks I can hide at will gives me enough flexibility to keep these VR dogs running on potato processors. Hopefully.



Also, I made level building blocks that can be much bigger than the current tile size. Now levels can have a beefy dirt floor without using 500 tiles.



But sometimes you just need a fill tool, so I added that too.

Making it easier to make tilesets:

I originally went with a tiled level approach to speed things up. But JARPUG's tiles aren't simple cubes. They smoothly interlock with each other and can have rounded edges. Each block has four separate meshes: one per corner.



Just taking horizontal neighbors into account makes for five possible corner meshes: corners, inside corners, edges, and middles. But things get significantly more complicated when taking vertical neighbors and hard cutoffs like level edges into account. There are 16 different models for the simple building tileset, not counting decorations like bricks, doors, and windows.



Setting up all of those tiles and their colliders so they match up perfectly takes a while. I needed to make it easier to reuse and alter these tilesets.

OH NO JARPUG HAS TEXTURES NOW.

It turns out having all of the details in the game be mesh-based led to tilesets that weren't especially flexible or reusable. Look at this stupid sidewalk:



It's beautiful. And I made tiles recolorable via UV shifting this month! Now I can have red sidewalk, too. Hmm.

So I set out to make a more generic tileset that I could apply new textures to for various uses. As I'd only been using textures for color before, I had a lot of work to do. UVs had to be rotated and offset to pick the desired hunk of texture for the top and side of each tile.

These tiles are still each made of four parts, so each textured "tile" was actually shared across two meshes.



Sharing one texture for different tiles is very helpful for performance, but colors "bleeding over" from adjacent tiles is a big issue. I added separate configurable "inset" values for each tileset to combat this. The ideal inset value is always "as small as I can get away with". That can vary, depending on the side of the tile and what sort of texture is getting slapped on there.



Each tile has specific ranges of the texture they're allowed to use for their tops, edges and sides. That lets rock and grass tiles share the same material without making it too hard to pick the "right" texture in the editor.

Blah blah blah it was a pain and it works now here's a gif:


While the textures can be explicitly chosen for any tile, there's also code for randomizing the textures on placement to help get things started.

I'm sure I'll make other detailed tilesets in the future. I also plan to make more "base" tilesets for this textured style. Now I can get more mileage out of either.

This took too long to write. Bye!

[Tyrus Peace]

OCTOBER!ish.

DOG FASHION
I started this milestone just wanting one thing: to put a scarf on a pug.



I did it.

Playing with cloth in Unity, and making it performant, took some learning but is easy to get quick at. In Unity, cheap cloth simulation requires that you manually pick a few capsule or sphere colliders for your cloth to collide with. Most of the clothes I made are actually short enough that they don't need to collide with anything. But the dream I had for that scarf on a short pug requires a quick ground test, after which I move a single capsule collider that only the scarf can hit.

More importantly, though:



the scarf fits on the jar.



Each dog has its own offset/scale defaults for each clothing attachment point, as their head and body sizes can vary wildly. Each piece of clothing has its own offset/scale settings that are applied on top of that.

PARTY MENU YEEA-oh not that kinda party

Actually treating this stuff like equipment required adding support for gear. Naturally, this exposed the fact that I'd been happily constructing my exciting new hats-for-dogs feature on top of a tiger pit of not-yet-done stuff:

• I need to have gear alter character stats
• and be able to equip gear in the first place
• and have an inventory for anything that isn't equipped
• and a place to save an inventory
• and a place to save anything at all about the current party
• ... and THEN I'll have the joy of working on all of the UI for that.

I recommend whispering quiet curses before each bullet point to properly simulate my software engineering workflow. Rooting out the true requirements of a milestone's desired progress is always my first step, but the fractal nature of database and UI requirements colliding into this fabulous mess has been... delicious.

Honestly, I was pretty excited for this and working on the UI is a nice payoff. This sort of "party menu" houses the heart and soul of most JRPGs. It's a welcome reminder that I'm actually making a game here. The menu's still a work-in-progress, but equipping works alright so far:



Much of the UI's is based around cascading transitions to go with the "splat" style of interface. It's fun to work on.

Bye!

[Tyrus Peace]

Nov-Dec 2018
The holidays are a rough time for work. Weddings, Thanksgiving, Christmas and New Years: it's been a travelsome couple of months. It's been a delightful couple of months.

The time was sparse on devlogs, but not on dev.

Treasure! Ironing out items and UI.


Pug can now pick up items from containers! This naturally led to a lot of work and fixes to the existing inventory/equipment system. That was kinda the point! I think it's pretty solid now. And I'm slightly less likely to be proven wrong about that the next time I work on it. But also I got to make a treasure chest.


Making a game instead of an editor. GETTING READY FOR DEMO TIME
Showing at an expo was nice and all, but my chief goal for this hunk o' months is to produce a public playable demo so I can get opinions from more seasoned VR players. The biggest step toward that goal is to actually be able to produce content for the game.

The PugEdit level editor works fairly well for producing tile-based worlds, but adding details and hooking up actual gameplay requires a whole bunch of work that, frankly, duplicates things Unity's Editor already does perfectly fine. Connecting object logic chains, making one-off decor, adding cutscenes, etc. I'm fine putting in the work to enable that sort of thing in PugEdit once I know it's worthwhile. Adding that level of guff and cruft to every thing I prototype just ain't worth it.

So I added the ability to preview PugEdit levels from inside Unity's editor, and reworked the general level workflow to allow for standard Unity scenes that load .puglvl files on command. And I can launch the external editor from inside Unity!

The most awkward thing about this is that I have to manually build PugEdit from inside this project whenever I update something that affects it. At least the in-editor preview will always be up-to-date!

Oh wait I'm still working on dumb editor stuff too

Don't worry, I still spent plenty of time fixing boring level-editing stuff! The PUGLVL format has had whitespace added to make it diffable and its key syntax has been shortened to produce 9% smaller files, even with all of that extra whitespace! Exciting.

I also drastically improved the performance of bulk-adding tile blocks. For those times when I want a level to have more than one block in it. Just in case.

{BORING OPTIMIZATION DETAILS} Tiles updated their neighbors when they were placed, since neighbor info, and even secondary neighbor info, could affect what meshes should build a given block. That's exactly correct for adding one block at a time. It is prohibitively expensive and stupid when you're placing a hunk of 512 tiles all at once. I'm fairly certain I've seen that hit infinite loops. Embarrassing.

So I added the ability to delay that update 'til later and pass in an external list to track updates and skip unnecessary churn. I still need to update the full chunk of new tiles twice: first to make sure they all have correct neighbor information and a second time to actually update all of their meshes based on that. It's okay. Computer don't mind. Thanks, computer. {/BORING OPTIMIZATION DETAILS}

I only need one update for bulk deletes, though. Oh, I added bulk deleting! Yay.


Unity 2018.3
NESTED PREFABS. Totally worth updating Unity mid-project. I wanted to wait for the official release, and that finally happened in December! The update wasn't that difficult according to my diff logs, but I remember it taking a day and offering a painful pile of problems.

Git only remembers the thing that worked at the end. It doesn't remember the pain it took to get there. Maybe I should be more like git.

Now that JARPUG's levels load more dynamically, nested prefabs are a big help. I can have one big "game core" prefab that I load on start without nuking all hopes of future organization. I can manually place and preview buttons but still have them be prefabs! I can more easily share a dog model between multiple prefabs!

a cool door


There's probably an actual word for this but I made that load-a-new-area gate thing and I hope it looks okay without anything behind it.

toon glass


Basically every screenshot/gif of the pug has been suffixed with "yeah I'll make a shader for some good looking cartoony glass later" for the last several months. I've got a list of backburnered things that need to be finished before release. This was at the top.

It uses rim highlighting logic to also increases the opacity of the lit edge, making for a cartoony shine that highlights edges in an appropriately unrealistic fashion.

January
I've got an outline of the planned script for the demo side-by-side with the technical requirements each scene will introduce. It should help me home in on what's actually important to add for that silly little "actually release a thing" milestone. Bye!

[Tyrus Peace]

CATCH UP REVIVAL THREAD.

Oops nine months huh? Sorry peeps here we go.





JARPUG came out on early access in June! There's a free demo and the game itself is super cheap because I don't want to charge more than it's worth at any point.

So to get there I had to:


Design the style/transitions for indoor areas!


Make some more monsters!


Implement a story script reading system!


MAKE SO MANY MENUS.

SKILL GRIDS.UI IS LIFE.


Make save points! And, uh... saving in general. Dang.


GROCERY DUNGEON.

Also I made some special dogs for people that beat the demo.

[Tyrus Peace]

CATCH UP REVIVAL THREAD: 2/2.

oops I forgot to mention that we had our second son born right when I was originally planning the Early Access Release and that was kind of wild. The release came out a month or so later than planned.


Luckily we got the ghost dog out of him.

And here's some other work highlights from AFTER the early access release!


SCOOTY BLOCKS. With relative child movement, path model building, and the best in dog-crushing-avoidance technology!


STATUS EFFECTS! Some golden oldies like poison, other more unique repositioning stuff for JARPUG's more movement-focused combat!




GHOST HOLE. I may have gotten carried away.


GHOST LABS. Exciting story stuff for the VR player's origins! Freight elevator doors must open vertically. I made a cutoff shader for it.


BATTLE SHOUTZ. And better battle movement! Players can now move through other characters during their move turn. They get scooted out of overlapping colliders at the end of their move phase.


ITEM SLINGSHOT! Items in JARPUG are shot into battle while time is frozen. So I had to make all of this animation/physics stuff work while Unity's deltaTime was set to 0. It took some effort.

I am still pondering how to balance item use in-battle vs. in-field. Since the number of characters you can use items on is variable in battle based on aim, I'm tempted to make items always apply to your full party out of battle. But then players may just hoard their items for out-of-battle use only. Dang.

Sorry for the kinda rapid-fire list of changes, but it's been a while! I'd be happy to go more into depth about anything folks find interesting.