Dev Blog

BrackenSack: a Dashkin™ Game

Month: May 2017

Bitey Lighty

Posted on May 21, 2017  in Art Updates

Anyone who knows Brackenwood knows that lighting is very important to me. In the Brackenwood movies, almost every colour has at least one tone variant. Grass for example generally has 2-3 colours – a base green, with a darker green for shadow tone and/or a lighter green for highlight.  Of course this also goes for characters; in “Prowlies at the River”, Bitey’s main colours (hair, skin, horn) each have base and tone. Lighting got a little crazy in “Waterlollies” and “The Last of the Dashkin“, where characters had 3-5 colour variations for each base (light, dark, reflect, highlight, line).



The past couple of weeks have seen me working on lighting for Dashkin characters. Painting colour directly onto the character would mean the same lighting direction in every environment. But what if I want Bitey to be lit from the front as he runs toward a sunrise? How about a cavern level where he’s underlit from glowing mushrooms? Would I create a separate hand-painted set of Bitey animation states for each of those situations? Well no, that’s out of the question for pretty obvious reasons.


Unlike the movies, lighting in Dashkin is dynamic, which means that the character is lit by whatever lights are in the level. In the open grasslands this would probably be sunlight or moonlight, but in forests and caverns, there are more varied and movable light sources such as low light (sunset, sunrise), back-lighting, dappled shadows, light beams, glowing creatures and under-lighting.


I’m creating character light maps using Toon Boom Harmony’s light shading, then hooking them up in Unreal. It is a pretty tedious, sometimes painful process but the results speak for themselves. As you can see below, we have variable lighting on the character. In this test scene I’m using a particularly strong, white spotlight to accentuate the effect of the light map.





Month: May 2017

Movement Part 2

Posted on May 14, 2017  in Tech Updates

Last tech update covered how we move along sloped surfaces and dealt with tricky issues such as mantling up and into tunnels equal to our height.  But a platform isn’t about just running along the ground.. its about.. platforming.  That means jumping.

Step 1 : Leaving the ground

With our vector movement based approach it was relatively simple to get our character to jump.  We merely used the existing horizontal velocity along the movement direction perpendicular to the normal of our ground surface and added a positive jump velocity.  We do a quick sweep up to determine if our character has at least a minimum height ceiling above them and switch from ‘ground-mode’ to ‘air-mode’ for our movement.

Step 2 : Air Control

There are many key points for successfully creating jump logic in a platformer.  Our character can influence their horizontal movement each frame in the direction the player holds the d-pad.  This coupled with a jump height ‘kill’ (apply extra gravity when the user releases the jump button) allows the player to precisely control their motion in the air in a way that makes sense.  If the player presses and holds the button they jump farther.  If the player holds in a direction they attempt to move in that direction.  If the player releases all controls the character attempts to stop moving and fall in the current location.  While experimenting with motion it became very clear that stopping the character when no input is received is just as important as moving when a direction is pressed.

Step 3 : Landing

With our analog approach to movement using sweeps landing is accomplished by sweeping in the direction of motion, discovering the normal to the surface, and comparing that normal to what slopes are ‘landable.’  We preserve the horizontal motion of the character, switch to ground mode, and apply any extra time after hitting the ground to smooth out motion when we finally land on something solid.

Step 4 : Wall Hugging, Hitting our Head

Real physics aren’t always fun, that’s why we make fake game physics.  When our character hits their head on a platform above them, we apply vertical and horizontal friction, but do not zero out their velocity.  We then move our character along the ceiling in the direction perpendicular to the normal of impact.  This allows the player to jump against curved ceiling, nudge around platform edges to get on top of them, and keeps motion fluid.  These rules also apply to vertical slopes, so if a player is attempting to move into a wall their descent is slowed while they slide down it.

Step 5 : Playing with Friends

All the rules up until now have applied only to a moving character vrs a static world.  Thankfully the same sweep tests, overlaps, and collisions also work great against other dynamic characters.  By applying our same rules as before and preventing objects from penetrating each other, we merely perform the same logic as with our platforms and our characters can move freely around and over each other.

Step 6 : Rigging all the Things

Finally we’ve completed solving moving our object around our terrain.  The final step is the incredibly tedious process of defining the bounding boxes of all our characters across all of their various animation states and frames.  In order to do this we draw bounding boxes in ToonBoom Harmony and expert them per-frame into Unreal 4.





Month: May 2017

Prototype art tasks

Posted on May 7, 2017  in Art Updates

For a lone developer, there’s no need to spend time on graphics and animation for the game prototype. In Jonathan Blow’s 2007 IGF talk about his game Braid, he said that the prototype “didn’t need production values for people to play it and enjoy it.” In other words, Braid was playable and fun long before it had pretty graphics, indicating to him that he was on the right track and maybe even had a potential success on his hands.


For a solo developer it’s efficient to quickly prototype using placeholder assets. But we’re two people working full time; the tech guy and the art guy working concurrently, albeit on opposite sides of the world. So while Kirk is laying the code foundations, it makes sense for me to lay the animation foundations.


For this reason the Dashkin prototype doesn’t have your typical placeholder sprites. Even though they look like rough pencil sketches as you can see in this throw state, there’s lots of drawings and smooth movement. As an experienced frame-by-frame animator familiar with my own characters, I can nail this rough movement pretty quickly, and when it comes time to clean up all of this rough animation I’ll have a head start on it.



With so much animation complete, my current tasks are all about backgrounds. Backgrounds aren’t entirely necessary for a playable prototype, but these are in preparation for the latest phase; the “beautiful corner”.


The term is new to me. According to Kirk it is the stage of a project where you begin to define the visuals of the game in their final state. The beautiful corner itself is a short section of a playable level, arranged like a diorama of elements in their finished style. In this game, I’ve started working on our beautiful corner with some fully rendered skies, mountains, forests, terrain, the player character, some creatures and even an animated waterfall. This past weekend I’ve begun arranging these final assets in the prototype level.


The process is very similar to how I’d be doing it in one of my Brackenwood movies. Sky at the back, mountains, then forests, all the way forward to the character and foreground foliage elements.



From the beginning I’ve been anticipating this stage of the project where art and code come together to form what looks and feels like an actual game. Up until now there’s been a pile of code over here and a stack of art assets over there, but last week we saw things become an actual playable experience. Even though there are still a ton of rough assets, and lots of tweaks and polish to come, we can now build levels and run through them, overcoming obstacles, platforming and dashing. AND, thanks to the way Kirk has set things up, we can do that as any character, so it’s totally within the realm of possibility that we can play as fatsack, a prowlie or even the Yuyu cloud. Fatsack Exploration Adventure anyone?




Month: May 2017

Movement Part 1

Posted on May 1, 2017  in Tech Updates

Dashkin is all about platforming.  Anyone who has ever played any platformer knows that movement is basically.. the entire game.  This past week I’ve been exploring solutions on twitch to figure out how we’ll be doing this for dashkin.


Step 1 : Build Fatsack a test level

The first thing I did was create a simple level in Unreal 4 in order to test edge cases with collision.  We made stairs, vertical walls, walls with tunnels, and a few giant ramps into space that we can run along and make sure our fatsack can into space.  The idea being that if fatsack can traverse all the test objects properly in a horribly constructed danger zone, that he’ll be able to do so in a real level that we put together later.


Step 2 : Think a lot

Next I started drawing out all the cases I could think of and figuring out how we’d move our fatsack through the world.  We went through an entire day of vector math drawings, hypothetical teleporting fatsack wormholes, and random tangents complaining about floating point to settle on our basic plan.  We’ll be using sweep & overlap tests in unreal in order to move our object in an analog fashion (so not tile-based collision) through the world.  Basically we sweep fatsack perpendicular to the normal of the surface he’s standing on, check for collisions, then resolve those collisions based on the situation.


Step 3 : Moving along the ground

In the simple case fatsack moves by nudging out of the ground by a tiny amount and sweeping forward in constant time along a vector perpendicular to the normal.  If we run into an object we move to the point of impact and nudge out from that object by a small amount normal to the surface of impact.  After we do this, we attempt to snap our fatsack to the ground.  This allows us to run up and down slopes even if there are seams in the ground, as long as we don’t stub our toe into the ground.


Step 4 : Stubbing our Toe

The first issue with the motion is if we run into a piece of geometry which sticks out from the floor.  A person in real life would just step a little higher and traverse over something like this (or they’d trip and fall on their face).  In this game we want our characters to nicely glide over small seams in the geometry without any issue.
In order to do this we :

— Sweep in the direction of motion

— Move to the collision point with the sweep

— Raycast to discover a ‘mantle’ destination

— Sweep perpendicular to the impact normal

— Sweep along the perpendicular to the normal of the discovered mantling destination


Step 5 : Tunneling

One issue with mantle destination discovery is that we need to ensure that we can ‘step up’ into a hole that’s the same height of our character.  In order to accomplish this we iterate in steps by our character’s height up the wall we’re climbing, move in the inverse of the impact normal, and again trace inverse in the perpendicular to the impact normal to discover the mantling point.


Conclusion Part 1 :

So far this method of movement has allowed fatsack to successfully navigate the ground in the test level!


Good Job Fatsack.