Our first update is going live tonight 1/6/2018 at 8PM PST.
– A brand new level ‘Midnight Ridge’ is now available!
– Massive performance improvements
– Fixed crippling client & server performance-over-time issues
– Ball indicator improvements
– Control improvements
– Massive performance improvements
– Fixed crippling client & server performance-over-time issues
– Ball indicator improvements
– Control improvements
– Shift and control keys mappable
– Graphics issue with outline in darkness
– Emissive color not working in level
– Audio still plays when focus lost
– Z-fighting with player & ball sprite
– Make wall jump easier (jump will auto-wall jump you)
– Left & Right for menu nav
– Make bots not talk
– Reset player when out of level
– Remove antic from jump
– Greatly increase back to splash time
– Controller only works when window has focus
– Issues with start button on post-game screen
– Issues with button presses tripping next screen input in UI
– Change UI for controls to be ‘face button top’ etc
– Remove fading for level start / end (perf issues with UI)
– t-key etc for chat switching
– Remove HUD elements in training level
– Infinite login issue
– Twitch logo is wrong in stats UI
– Audio sometimes doesn’t play on level join
– Client performance degredation
– Server performance degredation
– Disconnect flow not working properly
– Physics material specific angular damping
– Fix arrow keys moving selection in text fields in UI
– Ball indicator speed
– Ball indicator shake
– Ball indicator hit color
– Midnight Ridge map
– Goal-specific FX for score
– New ball hookup up
– Download links on redemption page
– Optimized foliage
Well here we are. I’m writing this on the eve of launching the very first full Brackenwood game and I am pretty excited.
The two of us have spent the past 12 months working hard in weekly sprints. As well as talking constantly every day over Discord, each week invariably begins with a video call and screenshare where Kirk and I do a retrospective analysis of the previous week’s achievements/failures and then plan the week ahead. It’s also in these meetings where we raise new ideas, discard shitty ones and lock in any good ones. Whether we stick to the current plan, or decide to switch things up or adjust the schedule, I’m proud to say that the communication, planning and decision making has been fully documented and absolutely consistent. I like to think I’m very well-organised in my work but Kirk’s organisational skills are god tier. That’s why tomorrow, we’re releasing a game we’re proud of and I’m not here writing some delay apology/excuse.
Tomorrow, as per my usual weekend schedule, I’ll be live streaming on Twitch. We’ll be asking our viewers to register their interest for game codes. From there Kirk will be sending them out to the lucky chosen players. Once you have a code, you’ll be able to install the game and play immediately with options for solo practice, multiplayer against bots, set up your own server for your friends to join directly, or play on our dedicated servers in USA, Europe and Australia.
For us, the hard work starts after tomorrow, because this Early Access launch will be followed by a few months of fortnightly updates, including bug fixes, improvements, new levels and character progression. Kirk has also set up telemetry tracking everything that happens on the servers. If any alarms go off he’ll be alerted.
What’s kind of cool is that we’ve managed to get this far with me working full time (I’m an assistant director on Bob’s Burgers) during the week, then doing around 35-40 hours of game work on top. There are times when I feel a little burned out but the second half of this project has seen cool new feature added after cool new feature and it’s just amazing to watch it come together. I can also look back on the mountain of art I’ve created in the past 12 months, not to mention the new software and skills I’ve learned along the way, including Photoshop, Maya, ZBrush, Substance Painter, UE4 materials and lighting. I mean holy shit I can even write HTML and CSS now! Whaaaat??
OK I gotta go do some more illustrations, ball animation and marketing. See you tomorrow!
Bitey is an opportunist, stealing food, dominating smaller creatures and treating them as playthings. It’s not that he’s really a bully; he simply has no sense of empathy because he has grown up alone and wild. Some of the most entertaining moments in his story are when he is punished for this behaviour – Bitey of Brackenwood, Prowlies at the River, LittleFoot, Waterlollies all have this karmic thread ending in satisfying retribution. To most of us it’s a little sad watching him be cruel to little creatures.
So in BrackenSack we have a problem. You play as Dashkin, beating the shit out of a poor innocent creature who is obviously alive and making efforts to escape. But there’s no consequences. Without payback it’s just cruelty.
I wrestled with some story ideas and justifications for using a live creature as a ball. There’s one where I thought maybe fatsack creatures require hard impacts to reproduce. With such impact they release spores into the air which are inhaled by female fatsacks, leading to fertilisation! Genius huh?
Well as much as I like that idea (it may even be the justification for a mini-game in the single player) I finally settled on this origin story:
The Origin of the Ball
Originally it was played with waterlollies which break after a few heavy impacts. The game rules were simple – hit the ball until it breaks. Whoever breaks the ball is rewarded with a refreshing explosion of water. Game over.
The Viccans love the spectacle of Dashkin games; they were thoroughly delighted by the acrobatic skill and speed of play. In order to prolong games, they crafted a new, more durable game ball for the Dashkin and called it a BrackenSack. With a durable ball, the game rules evolved to include goals, generally hollows in trees or simple woven hoops. This added ball control and accuracy to an already thrilling game. Taking it even further, the Viccans even imbued the occasional ball with a wild, unpredictable magical force, causing it to wobble through the air, altering its trajectory and requiring an extra level of skill to control.
Pretty sure I know what you’re thinking, and the answer is yes – I want BrackenSack to have various ball types for different game modes – including waterlollies. SPLOOOOSH FX. I like animating water.
If you know anything about our project, you’d know that it started out as a single-player, story-based platforming game. And if you’ve been watching it evolve on Twitch over the past 6 months, you probably know that we changed direction, focusing instead on a smaller game that is a multiplayer team-based ball & goal game.
How did this happen?
We decided to go this route after a couple of marathon whole-day meetings, the core of which was agreeing on our definition of success or “DEF-o-SUCK” as I like to call it. We agreed that a single player “Last of the Dashkin” style game with all my crazy ideas will be at least 2 years of hard work, with no assurance that it’ll ever be successful. Sure we could commit to finishing it. Brackenwood fans would probably buy it, play it and maybe even like it, but would anyone else? Would it have any replay value? Would it be talked about for years to come? Because all of these are in our DEF-o-SUCK.
The final decision was to start small. A more modest first project would allow us to set up the pipeline, the character, the world, the aesthetic and importantly, ship a product before the end of the year. Along the way we’d be watching and gauging the reaction from fans and gamers. A success would be our green light to proceed with the larger single player project, which would have all of its systems, aesthetic and movement in place. With a success under our belt, we plan to recruit a few more people and make a bigger, more ambitious multiplayer racing game. Only after those successes do we think we’re ready to commit to a single player.
So we had our 2D Bitey running around in the level, jumping on platforms and over obstacles. Planning a possible fatsack mini-game, we gave Bitey punches and kicks. In testing the movement and responsiveness of the controls, we gave Bitey the goal of getting fatsack up onto a ledge, or into a hollow log. You can see where this was headed. In order to test our movement and controls, things were beginning to point to multiplayer. That worried me. Lots of dashkin playing against each other? argh, that is NOT the story of Brackenwood.
Or is it?
Bitey of Brackenwood grew up alone in the world with only vague memories of his people. But they did once exist in Brackenwood along with the flying people – that is canon. So why can’t we have many dashkin in a Brackenwood game? Why can’t this be a prelude, a prequel, even a dream or memory?
In coming up with a name for our first Dashkin game, I decided to recycle the name of the very first BrackenSack made in Flash in about 2004. It was a solo mini ball game with click-to-move controls.
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.
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.
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?
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.
One of the biggest challenges associated with development is figuring out how you actually get work done. This becomes much, much more complex when you have people not only in different time zones but also halfway around the world.
Version control systems store your game assets and code securely so that everyone can work on the project at the same time. We’ve gone through quite a saga with zeroing in on the correct solution. First we started out with git hosted on github. This worked just fine until we needed to store large assets (like uassets in unreal 4). We tried throwing git-lfs (git large file storage) at this problem, but found that none of the toolsets supported it. This became a gigantic headache as I had to debug git commandline issues with Adam over voice chat. If you can imagine fighting a tiger with a blindfold on while googling how to compile ubuntu.. it was something like that. We then switched to the tried-and-true perforce. We were using hosted perforce on assembla, but when they raised their prices to over $200 a month for our services, we needed to pull the plug. We are now hosting perforce on our own t2.micro on aws and its been working out fantastically. We pay <$5 a month for this and it works great even though I’m in the US and Adam is in Aus.
All told we’ve migrated source control systems 4 times!
I don’t know how many indie studios have nightly builds, but we sure do. We’ve got a build machine setup under my other desk running Jenkins which builds all versions of the game nightly. It’s hooked up with its own gmail account and wakes me up at midnight if the build is busted (its always my fault). Having a build system which automatically builds our systems has caught so many boneheaded errors that I *HIGHLY* recommend any dev setup a build system even if you don’t think you really need it. All the software for Jenkins is free, so if you’ve got a spare machine sitting around you can set it all up for free in a snap.
Version control is good at storing source code and big assets, but what about temporary work or files that don’t work well with source control (I’m looking at you ToonBoom Harmony!)? We tried various solutions such as dropbox, share drives over VPN, and others.. but nothing has come close to the speed and just plain ‘works’ as Resilio Sync. Its a torrent-based file transfer system which syncs file systems asychronously. We just leave the build machine always on as a peer with automated nightly archives onto our NAS and we’ve got versioned backups as well as always-available secure peers for fast file transfers.
Tools and Scripts
Creating easy-to-use development tools can be very tricky even as a small team. Telling someone to go run ‘GenerateProjectFiles.bat’, sync down the latest on p4, run the sync tools for unreal dependencies, build the editor in ‘development’ mode, run the code generator, and run the newly built editor is a huge pain. In order to simplify our workflow we’ve created a master helper batch file which we both use. If one of us creates a new tool we just add it as an option and check it in. No more ‘oh yeah.. sorry Adam.. I totally broke all your stuff.. so.. here’s a 12 step process … Adam? Are you there? …..
Debugging crashdumps from C++ applications can be a gigantic headache. To solve this we host a symbol server on our shared NAS which our build server updates. We use srcsrv & symstore so when we get a crashdump all we have to do is double-click the files and it syncs down the files from p4, grabs the symbols from the Z: and we’re fixing bugs before we realize it.
*a quick hint for those troubled by p4 srcsrv requiring identical hostnames and not playing well with proxies, just edit p4.pm so it doesn’t include the host.. then tell developers to make sure p4v is open on the right server and it’ll automatically grab your correct files
Tools and scripts : Java / Python / Batch scripts
Version control : Perforce self-hosted on AWS (free for <5 users)
File share : Resilio Sync Pro (secure folders ftw!)
Debugging : Srcsrv & Symstore
Total cost per month : $25
If you’ve got any questions you can hit me up on twitter @ambientenergy_0