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
The past few weeks have seen steady progress in both technical and art sides of the project.
In preparation for the prototype, I’ve been making rough assets, including fatsack and Bitey animation. Not only is a lot of animation layer/node organisation required, but designing that organisation – that is, deciding how best to lay things out so it’s readable/usable – took half a day and still evolves with use. In the image below, there are two main sections. Left: states that happen on the spot. Right: states that happen at speed. The red areas below those contain finished states, the states in progress are in the centre.
Except for the top two, each red block contains several individual animation states. Each state consists of a 5 main nodes. At the top of each is the animation itself – a grouped hierarchy of embedded layers, including separate head, eyes, arms, deformer curves and collision rigging. Underneath that main group are two composite nodes and two display nodes. These are for working and exporting, respectively. In this screenshot, there are almost 50 states. I would estimate there’s at least another 50 to do. It’s also worth noting that this is only Bitey’s animation. This will need do be done for every creature and character in the game.
As anyone who watched my Twitch streams would know, I initially found it frustrating to rig fatsack and Bitey, struggling along slowly adding collision shapes to each state. Additionally, due to the frame-by-frame nature of this game, many animated states require splitting into various sub-states.
For example, the jump animation consists of 5 sub-states: spring, rise, hang, fall, land (see below). Having these all separate on their own layers (instead of all together in one sequence) makes it difficult for me to see the animation working as a whole action. It’s something I can get used to over time and I’ve developed a workflow but it hasn’t come easily. That said, this is the first character (the main player character no less) and once these initial teething problems iron themselves out and things will move more smoothly for the other creatures.
Rough animation is a very fast process for me and most of what you see above was animated in a couple of days. There’s plenty more to come yet so if you’re interested in seeing it take shape, you can find me working live most weekends on my Twitch channel. Once Bitey is done, I’ll be creating some very rough collision and terrain assets and looking further ahead, more creature animation.
Here we are! A few weeks ago on 12th March I announced live on my Twitch channel that Dashkin, a new game from the ground up, is in full time development. This neatly coincided with me landing a partnership with Twitch so they gave me some front-page time for the announcement which was a huge boost for us. Dashkin developer Kirk Sexton (ambientenergy101) was in the chat answering questions while I demonstrated our tools and process. He’s also the guy who set up all the sites here so he’s behind the scenes making everything work. You’ll see him around the place answering technical questions but we’re also compiling a FAQ on the Wiki.
The week after announcement, I continued my work on story, which I’ve split into five acts. By the time you read this I hope to be finalising Act 4. It has certainly been a challenge; telling story through game play is very limiting and games often use cut scenes to help drive the story forward. I need to avoid too many story-based cut scenes though, partly because it slows the game down (not good when our game has a “high speed” theme) but also because animation is a lot of work and I doubt I’ll have time to animate more than a minute or two of cinematics for this project.
I’ve also been working on rigging up sprites with collision geometry and exporting sprite normals from Harmony. This makes all my 2D animation ready to import into Unreal as flipbooks. So in this weekend’s streams I’ll be doing more animation and testing some stuff in Unreal. Drop in and say hi!
This past week was our websites week, with this blog and community sites. Kirk set everything up, I’m still working on customisations. So come check it all out! Join the forum, customise your profile, click around, explore, find broken things, ask questions, request features and tell your friends. We’ll be posting weekly updates from here on in and making any big announcements here first.