Introduction

Howdy! I’m Measured Moth, returning to YOU to go over some awesome new developer news surrounding the one, the only, the very very silly… Toons!

More specifically: The work that has been done with Toon rigs, and a bunch of fun technical stuff that gives us more opportunities for customization. And who doesn’t love customization?

You might remember not-a-long while ago the post made discussing how we are able to set up Cog rigs for animation support, getting rid of those nasty old rigs we were originally stuck with. We hinted towards our developments regarding Toon rigs, and if you thought our work on Cogs was quite the change, then sit back, grab a snack, grab a drink, grab a pillow to lay your head on, and whatever else that makes you comfortable, because there is a lot of changes we made for Toons that will get you excited!

Our New Rigs!

I won’t bother going over the general concepts that allowed us to make the new rigs, that is already explained in the Cog post. What I will go over is what changes we made to the Toons that you’d care about. To start, the change we made to make Toons a little more… bendy.

Bendy Bones

Lets go over a well known rigging tool: Bendy Bones**.** By default, bones are naturally pretty rigid. For most models, mainly humanoid ones, this makes sense since that is how arms naturally work! But, our Toons are no normal critters! We want them to have more wacky, rubber hose style movements to make them really stand out. Bendy bones are for just that, by having a single bone mimicking as multiple bones, you don’t have to keep track of 30 individual bones for a more flexible limb.

One setting available is easing in/out. What this does is have it set that the bendy bones along the main bone will bend so that they will curve into to the tail of the bone. This gives us a more of a rubber hose effect if it ends up high enough:

Using this, we were able to apply it to our Toon rigs. By taking the bones, adding bendy bones to them, and setting the ease in/out to a acceptable amount of wacky, Toons get not just a new look, but a entire new way of moving their arms and legs.

This change makes Toons way more animated then before, and closer to that cartoon feel we want to come from them!

Easier Accessories

One other thing that came from our new Toon rigs was having the option to improve the ways accessories are placed onto the Toon. Normally, accessories had to be manually adjusted to fit on a Toon’s body for objects like backpacks, hats, and whatnot. This increased the time to add a single accessory, and limited on exactly where we could put them.

Now that is a thing of the past, being able to add joints ourselves to certain parts of the model, we can give all kinds of options from backpacks, arm bands, glasses, hats, watches, bandanas… you get the point.

But, A Bit Of A Bummer…

I do want to mention something that might irk some. If you remember, Toons typically had their torso and legs be separate so that you could customize between the two sets for short, medium, and tall Toons. While this made them quite silly, this did cause various clipping issues, and supporting this needed quite a lot of code bloat.

The Toons have been reduced to only 3 body types. Tall, medium, and short that use their respective torso and leg models together in one. I know some people might not be a fan of this change… so I hope the reason for the change more than makes up for it.

Who wants to talk apparel?

Clothing!

Some background knowledge: Toons in ToonTown: Online had 2 different models for every body type between the torso, and legs for both skirt, and shorts. This means by default its very difficult to add different clothing models, as they are by default exported with the Toon models. Additionally, since Toons were separated by two different models, it meant that certain pieces of clothing couldn’t be done reliably, like pants.

These two roadblocks made it difficult to implement completely unique clothing, as the application of it would be a huge hassle both asset, and code wise. However, since we have full control over how our Toon rigs operate, we were able to come up with a completely unique system so that we can virtually do any, that’s right - any kind of clothing we want to create.

The Overlap System.

What we did was first take our Toon model, and remove all of the clothing present so we are left with a “base” rig.

Then, we export all of the individual clothing options (short sleeve, shorts, skirt, pants, long sleeve, etc.) as rigs that have no animations exported with them, but still using the Toon’s skeleton.

Why are we doing this, you may ask? Since we took our clothing, base Toon and separated them, we know can simply overlap the clothing on the base Toon model. This works because the Toon rig and the clothes rig are the same! So any animation we play on one plays on the other at the same time!

This means that the process of adding a new piece of clothing is as easy as modeling, texturing, and exporting it. We don’t even have to touch the base Toon to do it! There isn’t any real performance difference between this and the original way since, in both cases, we still had to render two pieces of clothing at any time. This really opens up our ability to add all kinds of stuff to wear!

However, this still requires code in the game to set this all up, and if you know anything about how it was originally implemented… it leaves much to-

OKitjustreallysucks.

New Clothing Dictionary

For any game that customizes clothing, it needs to make use of some kind of system to get the model and textures needed to fit on a character. Ideally this system uses IDs to reference clothing information, and is neatly organized, easily re-usable…

Oh. I don’t think you need to be a professional game developer with years of experience to know how bad this looks.

The way it was originally done required new clothing options to be added completely manually, with unreadable parameters. If you didn’t have previous experience with the system and knew what the numbers even meant, it was easy to screw up, and difficult to tweak clothing.

Instead, we are replacing that system with instead one using the flexible JSON data format. JSON is commonly used, extremely simple, and easy to modify. Inside of defining clothing inside code, we instead use JSON files, and have the game build the clothing table automatically with no need for a developer to do it themselves.

We use a style file that determines what types of clothing there are, where they fit on the model (are they over the top of the toon, bottom, feet?), and where the models are stored. Then, each individual clothing item is defined inside of resources where all the models, and textures are stored. Adding new clothing has never been so easy!

This reduces the work that has to be done to change Toon’s clothing, if you would like to know: over 1000 lines of code were reduced to this method. Now, all Toon clothing is done in a single function.

sniff. sniff. It’s so beautiful… and with all these changes it should be way, way less of a hassle to add new clothing in game technical wise, reducing the amount of headache that would normally occur.

DNA Changes!

Clothing isn’t the only bit that got a huge technical upgrade. If you don’t know: “DNA” is the term used for Toons, and Cogs that determines how they are generated so they can be easily stored in code, or on a data base. Toons need to store a lot of info in the DNA for all the customization they have, but it was poorly maintained, and just like clothing: not fun to work with. Not to mention how hard it was to modify the DNA to add new features, with the requirement of migrating older DNA to a new format.

Thankfully, our genius coder Wizzerinus decided to cook up an easily applicable DNA system that changes the game for us.

Bytestring Parser

Toon DNA is stored as a bytes. Keeping it easy, its the simplest form of information you can get. The idea being that you combine a bunch of these bytes together to form a DNA string (clever naming right?) that can then be easily modified, read, and saved to a database in a compact format. It also means that if you want to add a new feature, you need to migrate older DNA strings so they don’t cause problems when read. Problem is that this requires a lot of code to get right, and our original implementation had a lot of bloat surrounding it.

Instead, we made and used a Bytestring Parser (which is publicly available here!) that handles all of that for us. Getting a string from our bytes is done automatically, less chance for silly mistakes. Migrations to newer versions of DNA is better on the eyes then the previous version which made use of a single huge chunk of code to handle all migrations. This means that changing ToonDNA has never been easier, and cleaner!

if you want a comparison, here is what the the code for ToonDNA looked like from 2022 to the current rework.

With a reduction of about… 3000 lines. Talk about a downsize! Changing around, and adding new customization options has never been easier. Thanks Wizz!

Conclusion…

We have done a long list of work to get Toons in a spot we are happy with. Tweaks are still needed ‘til we are 200% happy with the final product, but this is generally how we plan to show them on release. This has been a big task, even bigger than Cogs! But it was well worth the effort to get everything working.

We still have some ideas for further customization of Toons, and we’re experimenting with even more potential options to make your Toon even more personalized!

Even then, what if we were stuck with everything I just described? We would have easily plenty of room for clothing, accessories, colors, and so much more so that you can be the Toon you always wanted to be.

Shweet.

Ahem. I’m Measured Moth, and I hope you will stay tooned to see what else we have in store with Toontown: Event Horizon.

…See ya!