For the Love of Making Games: Ludum Dare 32

Written by ESandra Hollman

Our studio was founded by friends who enjoy making games together. Naturally as an independent studio, we believe in supporting the shared passion of making games. A simple way we can do that is by opening our doors to provide a collaborative workspace for a game jam. And thus, we were happy to do so for Ludum Dare 32!

Game jam headquarters for the weekend.

Game jam headquarters for the weekend.

Seattle has a thriving indie community which promptly expressed interest when our Character Artist, Kieran Lampert, threw out the idea of AtomJack hosting during conversations at local meetups. Just as we anticipated, we had a great turnout. The reserved spots filled up quickly, resulting in the need for a wait list. Although space was limited, we were still able to accommodate everyone for the Show & Tell event after the jam. It was very rewarding to see everyone’s ideas come to life after all their hard work over the weekend!

The theme is announced: unconventional weapon. Let the brainstorming begin!

The theme is announced: unconventional weapon. Let the brainstorming begin!

Kieran joined a team that he found via the Seattle Games Cooperative Meetup group. Being the talented artist that he is, he created all the art and UI assets for their game, Backfire.

Kieran meets his team and they hit the ground running with design discussions.

Kieran meets his team and they hit the ground running with design discussions.

This was my second Ludum Dare and, in my opinion, another success. One of the things I love about game jams is the opportunity to set everything else aside and give yourself a small period of time devoted to exploring any ideas you have, without concern for commercial viability or conventions of normalcy. I think my team had a really interesting, unique idea, and it was a lot of fun pursuing it.
— Kieran Lampert, team member that made 'Backfire'
From concept to completion in 72 hours. Kieran's sketches and art mock-up for 'Backfire'.

From concept to completion in 72 hours. Kieran's sketches and art mock-up for 'Backfire'.

As for the others, there were a few teams and many compo participants. Here are the thoughts of some of the participants following the conclusion of LD32:

It was a great experience and exceeded my expectations! The folks who attended were very helpful, enthusiastic and highly skilled in many areas, and it was definitely an eye opener in terms of finding out what can be accomplished in a short timeframe! Particularly when leveraging the powerful advantages offered by the Unity framework.
— Michael Smith, maker of 'Aeterno: Warrior of Light'
I’ve been to several game jams, but this was my first ever Ludum Dare. Someone, somewhere, offered teams a chance to work with an Oculus Rift, and my team jumped on that opportunity. We wanted to make a highly visual, environment-focused experience that explored the topic of personal anxiety, and to that effect we made our virtual world a dark, glistening expanse with pockets of light for the player to explore. I finally learned how to implement my music tracks in FMOD using Unreal Engine 4, and personally had great fun implementing adaptive music into the scene.
— Evan Witt, team member that made 'Laughter'

(Special thanks to Oculus for providing development kits to use!)

This was my first game jam, and I can’t think of a better way it could have happened. I went looking to meet other game developers and maybe learn a little about Unity. Both missions accomplished! With so many other devs around, I could get answers for all my Unity questions immediately. I was able to get the gameplay working on Saturday, so I could spend Sunday polishing. I’ll definitely want to be back if you guys decide you want to host another jam.
— Peter Hufnagel, team member that made 'Pacifist Piper'
This was my first solo Ludum Dare and I had a total blast. My favorite part was seeing everyone else’s games at the end of the jam and hearing their trials, tribulations, and lessons learnt. A huge thank you to AtomJack and Kieran for giving us a venue in which to collaborate!
— Constance Chen, maker of 'Investigator and the Case of the Unconventional Weapon'

See the Seattle Indies website for links to the games they made with us that weekend.

Pizza! It fuels game developers. (Also coffee. Lots and lots of coffee.)

Pizza! It fuels game developers. (Also coffee. Lots and lots of coffee.)

Collaborating, learning, experimenting and having fun - that’s what it’s all about! We hope to be able to host again in the future. Until then, keep making games, indies!

Animation Blending: Getting Off On The Right Foot

Written by Floyd Bishop

I’ve animated on all kinds of projects, including film, television, web series, and games. Of all the ways animation is used to entertain today, I enjoy animating for games the most! There is a level of empathy that a player has with a game character that cannot be matched in film or on a television show. In a game, YOU are controlling what the character is doing. While you may watch your favorite film three or four times, adding up to maybe 6 or 8 hours for a 2 hour movie, players will be spending many more hours with a game character. As an animator, I want to do the best work possible and make sure the characters are entertaining and I’m not wasting the players’ time.

When animating for a game, aside from the needs of the character, you also have to consider the needs of the game. The first thing I do is talk with Design to find out what kinds of things the player will need to be doing with a specific animation or movement. What is the character all about? What will they be doing? What kind of personality do they have? Are they confident, scared, silly, etc?

The Robot needs to look adventurous and active, but also needs to walk and run at a very specific pace. He has some very mechanical features, and should look heavy yet athletic when he moves around. He's strong, but can hustle if he needs to. With all that in mind, I can start to flesh out our Robot character.


I usually start animating characters by beginning with a stand animation. Robot_loc_stand was the first game animation created for this game. The file name starts with the character's name, then the type of animation (a locomotion in this case), then the name of the action. File naming is important for all kinds of reasons, most importantly for the game's code to know what animations to call for what actions. If a file is named wrong or placed in the wrong directory, the game cannot see it and therefore cannot use it. Keeping consistent filenames and directory structures across all characters helps to keep development going smoothly.

A stand animation is perhaps the most iconic animation a character has. The player will see it a lot, so it needs to look great. For the Robot's stand, I wanted him to look powerful and ready to move. Even though he's just standing there, he's got to keep moving. I have his eye looking around a bit, and added a blink to help keep him alive.


Design wants the Robot to run at a rate of 9 units per second. Now that I know how far the Robot should be able to travel in one second, I can start animating a run. I start my animation by keying the Robot at the origin on frame 0. I then slide the Robot forward on frame 30 to a distance of 9 units. When I play, I see the Robot moving forward at the speed requested by the designers. Now I need to animate the character running at that pace.

All animation in the game happens at the character's origin. The root of the character is then moved through the game world by code. As a result, the animations where the character moves through space have to be counter animated so that the character doesn't actually move. Think of a person running on a treadmill. They are running at a specific speed, but aren't really moving through space. This is what we need to make in order for the engine to have what it needs.


The Robot walks at a rate of 6 units per second. The walk was animated after the run. Yes, we literally ran before we walked on this project. The walk is important because sometimes the player may want to approach something slowly. Maybe they are inching forward on a ledge, or creeping up on an enemy? A run wouldn't really be what the player wants in these situations. It also helps make a nicer blend between not moving and the speed of a run.

There is more to it than that though. The animations have to blend together in a way that makes sense.

In Unity, we have complete control over how long it takes for one animation to transition into another animation. We can also control what part of one animation blends into what part of another. We need to make sure that we don’t get any stutter steps or awkward movement when we go from a walk cycle to a run cycle. The way we do this is to get the legs to match up. If a left leg is moving forward in the walk cycle, we want the blend to happen when left leg is coming forward in the run.

Hopefully you’ve learned a little bit about how some basic game animations are used, and understand how one animation is blended into another in order to make a seamless experience for the player.

One of the hardest parts of working on a game is not being able to talk about all the cool and exciting stuff you get to see on a daily basis. I look forward to being able to show off more animation as more of the game gets shown to the public. I’m anxious to meet you at upcoming events and of course, when you get a chance to play the finished game.

Thanks for reading!

GDC 2015 Recap

Written by ESandra Hollman

The dust has settled from the whirlwind of a week that is the Game Developers Conference and the few from AtomJack that were able to attend are looking back at the highlights and takeaways.

Photo source: Official GDC (edited)

Photo source: Official GDC (edited)

While the rest of our team was holding down the fort and working hard on our pre-production prototype, Kari (Producer), Kieran (Character Artist), Allen (Executive Producer), and I represented AtomJack by learning from our peers and connecting with some of the game industry's brightest. After taking some time to let this year’s GDC soak in, the AtomJack away crew collected our thoughts on what we agreed was time well spent.

Here is Kari's recap:

I always look forward to GDC because I get the chance to hear from other teams about their processes and learnings. It’s also a great place to reconnect with industry friends and make new connections. I attended a lot of great talks this year! My favorites were: "Revealing the Gaming Habits of Teenage Girls" (Ashly Burch, Rosalind Wiseman), "The Vertical Slice Challenge" (Greg Donovan from Volition), and the "#1ReasonToBe" panel (Brenda Romero, Leigh Alexander, Constance Steinkuehler, Elizabeth LaPensee, Adriel Wallick, Sela Davis, Katherine Cross, Amy Hennig). You’re also pretty likely to run into industry veterans at GDC, and while fangirl moments are rare for me these days, I happened to run into the co-creator of one of my favorite childhood games, Toejam & Earl. Shoutout to Greg Johnson who didn’t run away in terror when I approached him to proclaim my undying love for his game. His team at Humanature Studios is currently running a Kickstarter for their new Toejam & Earl game here.

I had a great time exploring the city and attending talks with my team members from AtomJack. We also found the most delicious boba tea on Earth.

When the first person in the group receives his refreshing Boba Guys tea, those still waiting are stricken with boba envy.

When the first person in the group receives his refreshing Boba Guys tea, those still waiting are stricken with boba envy.

And Kieran’s recap:

This was only my third GDC, but each time I attend I’m reminded why this is my favorite game industry related conference. It was great catching up with friends I hadn’t seen in a while, and the more I see of San Francisco the more I enjoy the city, but the panels are always what excite me the most. A few of my favorites involved developers talking about their processes: James Benson gave a great talk reviewing his animation process on Ori and the Blind Forest; Jane Ng showed off some of her beautiful environment art for the upcoming Firewatch, and explained some of the tools used to achieve their look; Ray Crook reviewed some of the challenges he faced with animating 2D characters in 3D for Double Fine’s Broken Age, and how they were able to solve those problems. I also really enjoyed another session - affectionately titled the “Failure Workshop” - in which three indie developers spoke of times in which they had missed the mark and what they learned from their failings. My favorite presentation of the three, Ben Esposito, touched on cultural appropriation and the moral obligation to let people tell their own stories. I appreciated the overall core principles of the session, as well - the notion that failure is a natural part of the process, and how we often learn more from failure than success.

Campo Santo created an immersive environment for their Firewatch Demo Day.

Campo Santo created an immersive environment for their Firewatch Demo Day.

As for me, this was actually my first GDC. From a first timer's perspective, it was every bit as inspiring and exhausting as I anticipated. Two major pieces of advice I heeded and will gladly pass on is to wear comfortable shoes and bring a battery backup for your mobile devices. Conference highlights include the Community Management Summit on Monday, along with the slew of other great talks I attended, plus the cool new games and tech I was able to try.

As Community Manager, naturally my entire first day was spent here.

As Community Manager, naturally my entire first day was spent here.

The Community Management Summit in particular made my week. The talks were very informative with specific tips and tools up for grabs: "Strategic Community Communication: Managing your Channels Without Running Aground" by Maurice Tan (Deep Silver) gave a practical breakdown of the different social channels and how/when they should be used; "Steal These Templates - Creating a Community Plan the Easy Way" by Stephanie Bayer (Insomniac Games) lived up to its name and provided templates to determine your community goals and jump start your strategy; "Straight Talk About Community Manager Tenure" by Nova Barlow (University of Washington), Troy Hewitt (Motiga), Jorg Koonen (Bigpoint GmbH), and Jennifer Paige (Microsoft) thoroughly outlined the Community Management career track, expressing the importance of Community Managers paving a two-way street between internal and external communities. Other helpful presentations I attended throughout the week were: "Everything You Need to Know about YouTubers But Were Afraid to Ask" by Alex “Baer”Larrabee (YouTube Personality, Twitch Broadcaster), "Office Spaces: Do’s and Don’ts of Game Development Workplace Design" by Demetri Detsaridis (The Leisure Committee), and "How Youbers and Twitch Streamers Can Help Sell Your Games" by Mike Rose (tinyBuild Games). Thank goodness for the GDC Vault, because I definitely want to be able to reference these again, not to mention all the other presentations that I wish I could have attended.

Aside from absorbing copious amounts of information, we were able to do other fun activities like demo games. I even seized the opportunity to try VR for the first time at the Oculus/Women in Games International GDC Party.

Considering my susceptibility to motion sickness, VR was actually way more enjoyable than I expected!

Considering my susceptibility to motion sickness, VR was actually way more enjoyable than I expected!

Oh, and Allen? Well when he wasn't in meetings, he was catching up with the rest of us to have artisinal toast and coffee.

It was nice to step away from bustle of the conference to regroup over a coffee break at Blue Bottle.

It was nice to step away from bustle of the conference to regroup over a coffee break at Blue Bottle.

That was our GDC 2015 experience in a nutshell. Until next year!

Making Progress!

Written by Allen Murray


Hey everyone, it’s been a few months since we’ve given an update on our progress. If you’ve been following the blog you’ve seen updates on our robot designs from art direction to modeling, an article calculating jumps and the process of building tools to support the team. It’s safe to say that we’ve only shown you a tiny little bit of the characters you will meet (and play) along the way - and we have so much more to share over the months ahead.

The team recently finished an early milestone in preproduction and we’re heads down over the next couple months, creating our playable prototype that showcases our gameplay systems as well as bringing all of the beautiful art, animation and cinematics into the game engine. Even though everyone has been working hard the past few months the work has largely been on concepts, tools, engine and gameplay systems - everything under the hood and not much on screen. Just recently have we been able to see the fruit of this labor as all of these pieces come together and it is amazing. This is that dark tunnel of game development where you have ideas and plans and you start building, layering on all of this work that is being done in parallel. It’s messy and oftentimes things are horrendously broken. But you work together, grinding it out and as you progress you start to see the light at the end of the tunnel - or in this case characters and environments come alive on your screen.


It’s still very early in our development cycle, but it’s moments like these that make us proud and we’re proving that our core gameplay works and is *fun* and becoming more and more confident in our plans for production. 

And one of the reasons we have been able to make such progress is the addition of our new Gameplay Programmer, Greg Brown who joined us this winter. Here is a little bit about Greg in his own words:

Greg Brown

Greg moved to Seattle from Salt Lake 11 years ago with a BA in Sociology and French no clue how one might use those professionally. He landed a game testing job at WildTangent and began working his ass off to expand his limited programming knowledge into something useful. While there he met a number of people who he would go on to work with at Flagship Studios’ small Seattle office on project called Mythos. After the collapse of that studio and the loss of their project, that team stuck together and form Runic Games in 2008. While at Runic, Greg worked on Torchlight, Torchlight II, and the publicly available content authoring and modding tools for those games. Recently, Greg was seeking something new and different (and not a Hack-and-Slash RPG) to work on and found it at AtomJack. Outside of game development, Greg loves language study, traveling, showing his age through his love of 90’s indie rock, his two cats, and learning how to dad.


Make a game with us

We recent starting hiring for a new position and are looking for a very talented painter to join our team to help paint all of the lush 2D environments and backgrounds for our game - as well as assist with additional concepts. If you or someone you know is interested, please check out the position here: Environment / Concept Artist.

It’s an honor to share these updates with you and we’re excited to show you more over the next year! Thanks again for taking the time to keep up with us at AtomJack and check back soon for more updates.


Modeling a Stylized Character

One of the many reasons I enjoy making character models is because the process is a bit different each time. Similar to people in our everyday lives, each character has its own unique quirks, presenting its own set of challenges and puzzles to solve. So I wanted to share with you all an overview of the process by which I brought our Robot from 2D concept to 3D asset.


This particular model started with a pretty clear-cut concept, and even before then a well established outline of what we wanted the character to be. Depending on who you work with, sometimes your art director gives you a fully completed concept like I had for our Robot. Other times, though, you may just be given a rough sketch, and your teammates are looking to you to pour your own influences into filling in the details. I’m lucky enough to be working with some pretty talented folks here, so the concept I was given by our art director was already imbued with a ton of appeal.

Here at AtomJack, we’re a pretty small, tight-knit group, which makes it much easier to throw ideas around and come to a consensus on things. Upon receiving the concept, I sat down with our art director, animator, and lead designer to get an overview of the character and specific needs for the model. How do his leg joints connect? What are the extents of his movement range? What material is this made out of? The discussion continues until we all feel like we’re on the same page, at which point it’s time to dive into production.


The exaggerated nature of our game’s art style was utilized in the Robot’s design to push the traits of his character. For example, the Robot’s large torso, shoulder pauldrons, and hands exude strength, but his color scheme and wide, green eye belied a nature that is more curious than menacing. The design David came up with already provided so much definition, so my task became ensuring that as much of the character as possible was maintained when transitioning from 2D to 3D.

When it comes to actually constructing the model, I tend to make two general passes. The first pass is centered entirely around trying to nail down the feel of the character. At this stage I’m not worried about any technical limitations, but instead focus on major design elements: silhouette, exaggeration of important features, overall aesthetic appeal, and so on. My goal is to make sure the 3D version looks and feels as much like the 2D concept as possible, while still maintaining the physicality of an object in three dimensions. Since I’m not concerned about restrictions, I tend to go back and forth between Zbrush and Photoshop, sculpting in high resolution and comparing to the concept as I go.

An early, high-poly pass on the Robot model in Zbrush.

Once I’m happy with the feel of the character, it’s time to switch gears. As I mentioned before, each character tends to be unique in its creation process, but one aspect all of them share is the need to find a balance between form and function. Games, though constantly evolving, still come with a fair amount of restrictions. For example, most modern games strive to maintain a runtime speed of 60 frames per second. For those who may not have experience with the inner-workings of game development, this means the game engine is gathering all information from the player (inputs to your gamepad or mouse/keyboard), as well as anything else happening at the same time (physics, graphics, animation, etc.), calculating all these interactions, and rendering all the results on your screen, 60 times every second. If you’re not mindful of the way you’re handling your systems and art assets, these calculations can quickly get out of hand and interfere with the players’ game experience, whether it be lag, lowered frame rate, game crashes, or any number of other problems. This is why balance is so important. I can make the characters as beautiful as humanly possible, but if the game doesn’t run it’s all for naught.


My second pass, then, becomes one of feasibility. One of the questions answered in the initial discussion between myself, the art director, and our designer is the estimated size of our polycount budget for the character. Polycount refers to the number of polygons - usually triangles - that will be used to construct the model. Each polygon adds to the calculations that need to be made on the model when it’s being rendered in the game. So, generally speaking, the lower the polycount, the lower the stress on the engine. In games where there are potentially a lot of characters on the screen, it is important to be economical in the way you distribute polygons amongst your characters.

I use TopoGun to create a low-poly model from the high-poly Zbrush sculpt. There are many programs that allow you to do this, but Topogun is easy to use and produces great results.

I usually do a straightforward retopologization of the model in Topogun, trying to be efficient and economical in my distribution of polygons. Sometimes, however, I still end up over the polygon budget and need to go back and strip out polygons. The tricky part comes in how many polygons to cut, and where to do so. To make this decision, I usually stick to three criteria:

  • Silhouette - Are the polygons in question helping to strengthen the silhouette of the model?

  • Deformation - Are the polygons in question required to allow for smooth deformation when the model is rigged, skinned, and animated?

  • Ease of Texturing - Will these polygons make it significantly easier for me to hide texture seams or differentiate between different parts in the texture?

If the answer to these questions is “No,” then the polygons are removed. I continue to cut polygons until the model falls roughly into the budgeted polycount. Since the Robot is a main character - and therefore spends a lot of time on screen - and quite large, we allowed him a much higher polycount than we’d give other character models.

After modeling, the polygons are divided into parts, laid flat on a 2D plane, and painted over. The resulting 2D image, known as a “texture map,” is then applied to the model.

In addition to polycount, I need to consider how much texture space to allow for the character. Depending on your game engine and what the rest of your tech is like, textures can often be a larger tax on processing power than the amount of polygons in your scene. To determine the size of the texture I’m going to use on a character, I again weigh the costs and benefits of form versus function. I can free up a lot of processing power by making the texture maps smaller, but how large of an impact will this have on the fidelity and appeal of the character model (and ultimately the overall aesthetic appeal of the game)? Again, with the Robot, his size on screen and role as a main character gives him priority. This simply means that if resources are tight, corners will have to be cut in other areas. Not necessarily a problem, but something to be mindful of all the same.


Again, given the stylized nature of the game, some distinct choices were made in terms of the textures and materials on the characters. The Robot, as with our other characters, is using an unlit surface shader, which means it derives its color and lighting information solely from the texture and is not influenced by lights in the scene. This comes with its own set of challenges, but what is gained is the ability to completely control the hue, saturation, and value of the textures to help them more closely match the concept (and, more importantly, its surrounding environment in-game).

The diffuse (unlit) texture being painted in Photoshop. The concept art is kept open for quick reference.

Lately I’ve been using a program called 3D-Coat to paint our character textures - along with a slew of other features, it allows you to paint directly on the model - but the Robot was one of our first fully textured characters and was painted in Photoshop. During the painting process I’m frequently comparing the concept art with how the textures are looking on the model. In addition, I’m trying to be mindful of how the Robot is looking in the in-game environment, even if it means simply overlaying a render of the Robot on a piece of environment concept art. It’s incredibly easy to become too focused on how a model looks in isolation, only to find out it sticks out like a sore thumb when placed in the engine.

The Robot model, before and after the painted texture map is applied.


I should mention that, throughout this entire process, I’m constantly checking in with the art director and making minor adjustments based on feedback. This ensures that the model is staying on course and remaining true to the initial concept. At the end of the process, it’s good to gather everyone and give the model another final once-over, just to make sure everything is as it should be before the model is handed off to the animator.

The model is complete!

The model is complete!

Having maintained the course, and suffering no major catastrophes, the Robot is finally all modeled, textured, and ready for animation!