Behind the Release of Axis Descending: The Sketchbook

Behind the Release of Axis Descending: I / II / III


Lately, the potency of a physical sketchbook and a digital notepad has been on my mind. A few times this week alone students looking to get out of additional class-related tasks because they know everything students have been looking for an explanation regarding the weekly 5 page sketchbook/note requirement for relevant courses. I have engaged in a number of discussions about this so far, but I am not convinced the concern is entirely alleviated. It only makes sense, then, to explore this topic even further for this month's Axis post and how it relates to the project, its process, and how I am able to make it all happen given a full-time four-fold schedule. Asking an art student why they should have a sketchbook is a silly concept. The answer is more than obvious. It is almost primeval it is so primal. Given the questions I have received this week, or the gossip related to demanding sketches and notes I have overheard through the grapevine, I have to beg the question: why is this even being questioned? Asking a game art/development student why they should have a sketchbook should be no different.

In the early stages of Axis, and my development experience in general, I didn't sketch anything. I jumped right in to the project software and went at it. I made art, I made things move, I crafted code and made mechanics work. I pushed myself into it to finish it quickly under that guise of a "two week thing". I got carried away because I didn't examine the idea's potential, or how it could be more than what it initially was. I jumped right in without researching a thing, internally or externally. The art was ill-conceived, the animation was rushed, and the code was haphazard because I didn't take the time to do what a sketchbook or notepad does best: it allows you to explore. That is what it is about, after all. Not busy work. Not perfection. Not a container to have to fill each week for a grade. In a way, it is not even about practice, since that emphasizes repetition so strongly. It is exploration that allows you to avoid ill-conceived art, take the time to understand the principles of motion and spatial relationships as they apply to animation and its principles, and it gives you the forethought, preparation and hindsight to plan ahead with code. It allows you to work out some of the details you simply cannot while in production mode in the software. It can be asynchronous, available and sitting idle and ready for you to tap into its potential by your side while you work.

"We find you need to make a game wrong at least two or three times before you find the right path. ... We took a lot of opportunity to design and explore, knowing that a lot of it would be thrown away."
Ken Wong, Lead Designer of Monument Valley via Gamasutra (over 24 million users have downloaded the game as of January 2016)



The sketch/notebook acts as a collective compendium of your mind. A lexicon of potential thought, exposed on paper as the profile of a human face or a misaligned list of things "to-do". If it is left in the mind, it will inevitably be forgotten. On average, people can hold around seven things in their head at once. Anyone involved in production should take note of things, even if they seem unimportant or innocuous. By doing so, you will be surprised by how many tidbits of information have since left your mind when you revisit pages that were recorded on months ago. The act alone has numerous universal advantages, but this should be obvious.

For those seeking employment, or making any attempt at communicating their capabilities as an artist or designer through critiques, reviews or interviews, this tome is an utter conversation starter (look for page 41 in the link). Every prospective Game Art student at Lawrence Tech has to submit an electronic portfolio .pdf to the admissions department (hi Adam!) which is inevitably approved or denied by me. It is abundantly clear when someone takes the time to draw, take notes, and simply reflect in their spare time with a piece of paper. When I review portfolios for National Portfolio Day, same deal. When I get applications for roles within grant funded projects or Infinite Machine, the same. The exploration pays off. It becomes experience, not of technical know-how, but fundamental knowledge. It denotes an understanding, an ability to plan, an ability to communicate, and an ability that exceeds all others: the ability to think things through, which makes the creator desirable and more relate-able for employers.

My schedule is by no means uncommon. As the Director of the Game Art program at Lawrence Tech, a Father and a Husband, it can be difficult to find time for the demands of Independent Game Development. Last year, as I was completing my Masters in Experiential Design and adjusting to the changes associated with having your first child, my schedule was even more chaotic. I simply couldn't do anything productive with this line of work at times, rightfully so, but I was able to simply write things down for later. This has proved invaluable for times like this, even now, and has encouraged me to keep a notebook handy wherever I go. At work, it isn't far away. Seeing the work of peers and students inspires the most left field concepts related to my own work. Without writing it down, knowing me and my memory, it would be lost in time. I know I'm not alone on this.

My sketchbook has inspired some of the most well-received mechanics within the game. It has improved the polish of my art, my animation, and simply stimulated production at times when it otherwise would not have happened. In many ways I don't even sketch a thing. I work out my thoughts in visual form to try and just get them out of my head. For character designs, they act as my reference for initial silhouettes, outlining, and the filling in of flat color that leads to the shading and polish of a finished NPC. For enemy design, I get to flesh out their behaviors, attack patterns, and weaknesses without touching the software whatsoever. For the world and level design, I demonstrate a feeling or theme to the best of my ability and place the initial lay of the land. I list objectives. Crafted items. Crafting requirements. Quest objectives. Story beats. Things to do. Things to fix. Things to make. Things to rock.


Some of my favorite things about the game have come from my lexicon. If it were on Yelp, I'd be a regular and give it 5 stars with a raving and down-to-earth review. Huey, the friendly sparring partner of Axis who grants a few skins and power-ups to the player originated as an exploration of potential NPCs. I made familiar faces and colleagues. I made people I happened to cross paths with. It made me curious about their purpose and role within the game's world. Who are they? What do they do in this world? This consideration will be evident in the final product, even in Beta 3, and I guarantee will be a selling point with the product.

To summarize why students and creatives in general need to utilize a sketchbook/notepad, or tl;dr if you're nasty:
Provides Exploration of Concepts
Enables Planning of Goals
Acts as Physical Record Keeping
Encourages Clarity of Thought
Stimulates Growth

And for students still contemplating this come on, the 5 page requirement isn't even that bad.

Behind the Release of Axis Descending: Iteration & Testing

Behind the Release of Axis Descending: I / II / III

I have spent many hours running Axis across the deck of this ship, testing and iterating.

For the second part of my 12 part series, documenting the journey behind finishing the most personal project of my life, I want to discuss some of the most important methodologies I aim to teach my students. Through iteration and testing, you can find success. Through these two terms: iteration and testing, numerous subtopics can be explored to break down some of the most fundamental lessons that have been bouncing around Gamasutra for years. For seasoned developers, they both serve as reminders and a metaphorical reflecting pool for current and future endeavors. For students, they provide the guidance and structure necessary to reinforce a productive learning environment.

One of the biggest lessons I have for my students is understanding that game development takes time and it isn't as glamorous as some commercials make it out to be. Failure and self-teaching are integral to the process. You will create work that is bad. You will make mistakes. You will fail. All of this allows you to grow as a maker. I regularly meet young folks looking to dive into the world of game development. Discussing how to get into the industry, why students should participate in Lawrence Tech's Game Art program, or simply trying to point talent in the right direction leads me to a common question. "What is the one thing you would tell an aspiring developer?". To that, I say fail hard, fail fast, and you'll succeed furiously. The last bit may be a bit overzealous, but when I say this I like to imagine those moments when someone resolves a problem in code or puts that final touch on an art asset. After struggling with something for so long, which I see often in my own process and the process of my students and friends, there is an air of defeat and silent determination.

I recently spoke at this year's Game Arts Conference about getting into the industry.

At times, you hit a wall in a project. We've all been there. It happens, and how we react differs depending on the day. Maybe the struggle is more frustrating than it really needs to be. Maybe the difficulty is veiled by something else in the work environment or in your own problem-solving state of mind. So you take a minute, you google the answer, you phone a friend and hope that this determination pays off sooner rather than later. You do not stop. You may take a break. You may take a break for far too long in retrospect, even, but you should never stop. The solution is there. Figure it out. Consider new angles. Considering the constant flux of Star Wars media and my family watching the original trilogy it is hard not to quote Yoda. Do or do not. There is no try. I am not a fan of organizing things mentally in a binary way, but in this case the only answer is to continue. Insert the coin, hit Y, and don't let the counter time out.

After resolving the issue that determination pays off, all is well in the Mushroom Kingdom, and you move on with a rush of dopamine. Great! Good job! Only later on in the project you realize all that work you did may be going to waste. Hypothetically, your art asset is getting scrapped. Your mechanic your were implementing? Too complicated for your player. This moment finds us all, often, and is entirely necessary to success as furiously as possible. Like the light and dark sides of the force providing a balance in the universe (if you believe it exists only in a binary way), both the successes and failures of the craft have to be experienced to grow and create polish. Do not be afraid of these moments.  By all means be frustrated and vent if need be, but never disregard the fact that this is entirely natural in design, in business and in making.

You will fail. You will redo things. You will make mistakes. Good for you! You should be!

Discovery is learning. Good or bad, the experience provides supplementary knowledge for future design choices. Through the iterative design process and project management like Agile/Scrum, all of this is inherent. Want to make games? Be prepared to make some terrible ones first. Many, many times. This same logic can be applied to most trades and careers, really. My Father is involved with heating/cooling/electrical. Every system he worked with had a design that he needed to understand enough to break apart, restore, and improve. Through a diagnostic approach, he would "try it" to see if his fix worked. Did that work? No? Try something else. Get it validated. Push it.

You can always try Wikipedia too. I found this image there.

Iteration is key. It encompasses and guides the intent of the designer the whole way through a project. Axis' run cycle has had numerous updates and tweaks over the years. His ground attack combo is an even better example, undergoing constant revisions, timing tweaks, adding and removing the ability to chain into other attacks, and more. Like many developers, I spent an immense amount of time in the last few years just getting the feel down for certain things. After so many modifications, I feel good about the decisions I made and the time spent on it. If time allowed, I would work on it for another year just to improve it but, like my Grandfather always said, a good artist knows when to stop. Prioritizing what you spend so much time cycling through the process again and again is important. All of this time and energy spent on the look and feel based on my own perspective is almost null. None of it matters unless we have the validation of the user experience to light our path.

I'm pretty sure this isn't even the latest version of it.

Test as soon as possible. Test individual mechanics if possible. Test when possible. Your goal is validation and observation.

Through testing, you will have decisions acknowledged and supported or disputed. Through testing, you will observe moments where players are confused, challenged, entertained, or immersed. Whatever decisions you have made about your primary and core mechanics, they need to be backed by the user. If players are having a difficult time jumping in a platformer you have a problem and the earlier this is resolved the better. It provides the chance to make that jump function and become a part of that entertainment that will lead to your intended experience. Make the jump feel great. Make the weapon feel good to use if that is your core mechanic. Whatever it that the player does frequently and often, you don't want it discouraging the player from continuing to play in any way. Focus on the feel, but not just the feel you experience. Game Design is human research. Testing is where your hypotheses are explored.

The first alpha test with Axis was ill-conceived. In many ways I wouldn't consider it an actual alpha test. I originally set out to fix bugs, not validate and observe. I submitted a Flash .swf embedded in this blog as a way to play and test the build I had, which offered little to no gameplay. It was a series of mechanics that simply did not play off of one another and provided zero context for who you were, what you were supposed to do, and how to do it. A student of mine, who I knew from my PSP homebrew days working with SmashGP, gave a review on his own blog that perpetuated the link and offered some insights. Like his post, other testers noted bugs. I failed by not asking the right questions. What made this fun? What are you supposed to do? Who is the player character? What 3 things make this great? Nothing from this "test" provided me with the knowledge I needed to accurately plan ahead and tackle my user experience challenges. After dabbling with this build for a period of time, a conversation in passing with a less-than-friendly ex-colleague proved to be more beneficial. As salty as it was, his disapproval and dismissive comments made me change my perspective and lead me to explore a few things that proved quite beneficial.

The game changed dramatically for the better.

The first beta was handled more appropriately. By embedding the game in HTML available for anyone with a Flash-friendly browser and a computer, I made the venture more accessible. Additionally, I provided a few links to a questionnaire and a bug report system through Google Forms that created quantifiable data, visual graphs, and a means for players to communicate with me regarding the game at any time, unlimited by a site-specific focus session. Updating these forms and providing new versions of the game build with additions, bug fixes and more keeps the feedback loop going. It also helped to build a small following and interest in the game. Players felt connected with the development process and were excited to see developments happening each and every day.

I cannot recommend Google Forms enough for your feedback questionnaires.

My questionnaire was trying to create a conversation with the user. I may have asked them to give a 1-5 rating, but the most important written questions related to what they took away from the experience. What were three things you loved about the game? This question alone tells you most of what needs to be known. Even if your test only gets a dozen or two responses, if the majority of that small group are saying you should increase your jump height then you should increase your jump height. That response will be there, most likely, whether you get 12 responses or 12,000.

The bug report form had only seen a handful of responses, but if major complications arose they could be addressed, transferred to a bug spreadsheet to prioritize and organize the information, then resolved if they were something I could reproduce.

Moving forward, I am aiming to take a few notes from Dan Felder's Design 101 entry on Testing. Specifically, Scattershot Testing.

Beta 2.0 was intended to be a more finalized "this is the game" experience, but was operating under the structure of a Masters course project. One of the biggest hurdles in the development of the game, appropriate screen scrolling, was simply ignored to finish up all of the content I wanted to create for the course. I spent much of my allotted time just building 30+ levels without justifying any of the choices I was making. Each level was split up into 10+ non-scrolling screens, making the fast-moving Axis jump between screens rapidly. 2.0 is jarring, to say the least, and the way the environment was implemented does not encourage the sense of exploration I want to achieve. Despite rushing under the restraints of time, the iteration provided me with an immense amount of insight into the process I will be using in 3.0's scroll-friendly environments.

2.0's rooms often felt like stunted corridors with forced encounters. Many of them, like this one, were in need of clutter or purpose.

Some of the areas in 3.0 are still static, but only if they are appropriate. The tight and cramped barracks for Axis' crew makes sense given the context, but also provides a great point of view for sparring with our friend Huey here.

Through Scattershot Testing, the next beta will be focused on the mechanics, not so much the final intended product. Once I have my validation and observations, I will have the tools I need to get that final polish. I am currently working on a tiling system for level generation to save time, avoid bugs and oversights, and establish a clear sense of "this is ground, this is a wall, this is a clingable wall" and so on.

If you take anything away from this post, trust that failure is a natural part of design, growth, learning, and success. Embrace it. Strive to learn from your experiences Make. Focus on the feel. Iterate. Fail hard. Fail fast. Know when to stop.

Behind the Release of Axis Descending: Introduction & Origin

Behind the Release of Axis Descending: I / II / III

Axis 3.0

About seven years ago I was fresh out of a BFA program in Game Production, teaching Game Design courses, and reeling from a failed student project I had taken on. I was beginning a new stage in my professional life not only as a game developer, but as an educator teaching college courses and developing my skills as an instructor and presenter. While the education career would allow me to continue learning as a designer and satisfy my need to pay the bills, my extracurricular activities began taking form as development practice and applied research. One of the first projects I decided to work on, Axis, was a self-directed solo-developed two week venture that has transformed into a seven year development cycle filled with year-long hiatuses, adaptation to industry trends, and a fair amount of stubbornness in avoiding certain trends. In the next year Axis will be released as Axis Descending on Steam Greenlight. This post, and others to follow it, are a documentation of this journey's iterative process, ups, downs, and outcome.

The primary intent behind this series is to help my peers, my students, my friends and family, and my social media following understand:
  • How the project has changed throughout the last seven years and why
  • The personal importance of the project's vision
  • Individual metaphors related to the game mechanics and character/world design
  • Design choices related to the limitations primarily imposed upon myself by myself
  • An in-depth analysis of the project's journey while it commences
  • Do's and Don't's for independent game development

We'll begin with an introduction to the game, how it came to be, and why it has gone through 3 phases and rehashes.

Like all of my heavier personal projects, Axis began with a session in front of Flash listening to music. In particular, a few key tracks have inspired the development of the game and kept me in the zone while working on assets or scripting within Actionscript. After working so heavily in Flash throughout my BFA experience and beyond, I had a strong understanding of the software tools and what they could produce. I also had a particular look to my work that I wanted to evolve and extend that derived from a failed course project, a capstone project and mentorship via Floyd Bishop (which was amazing), and a failed indie development project post-graduation. The look was easy and natural for me to produce but still needed the time it takes to refine and define an art style.

Aegis Steelfleece's base design was used to define the tall and slender proportions used throughout Axis Descending's character designs. On the right you can see the evolution of the forward-facing sprite and the current one.
Aegis Steelfleece's base design was used to define the tall and slender proportions used throughout Axis Descending's character designs. On the right you can see the evolution of the forward-facing sprite and the current one.
The original concept for Axis 1.0 included puzzle platforming through shifting between a light and dark version of the world. The dark world would be broken and in ruins, whereas the light world was intact, vital, and colorful (not depicted in the example whatsoever).

My love of desaturated tones and a deep desire to have blue hair (totally owned it during high school for a short period of time) resulted in the core scheme of "Axis Kailash", but the majority of the design was influenced by other characters, Ko, Aegis Steelfleece, and one of the first 3D modeled characters I created, also named Axis, who defined the new character's history. The original design was influenced by these characters in a number of ways.

The 3D model Axis was influential mainly from a story standpoint. Axis' background as a swordsman who has a war-torn history, coupled with experiences with the world's afterlife or "dark world", framed the new character's history. This history has been manipulated, scrapped, written and verbally communicated in a number of ways. Currently, Axis' relationship with spirituality on a physical and intellectual level are at the core of his past and present. Originally, this manifested as the primary game mechanic within the first prototype in the player's ability to shift between light and dark worlds, causing new pathways or items to appear depending on the current world. This mechanic was by no means new, and has been used manymany times.

Ko's blue hair, energy, and stoicism are a large part of Axis' look and personality. His glamour rock haircut, similar color scheme, and movement have sparked many discussions about whether or not Axis was "Ko's Dad", or "Ko all grown up". Similarly, the weapons and mobility mechanics in the game reflect the mechanics in the Aegis game. The evolution here is intentional for a few reasons. Axis' mechanics were an extension of the mechanics within the Ko game, but due to the project's failure and involvement of peers within an educational setting, it was inappropriate to continue building upon that original world. This new character would be a muse for a new universe, a new beginning, and a new adventure. The design mirrored my own experience with these projects and my intent moving forward.

Axis 3.0, showcasing combat and the player's ability to dodge.

Axis 1.0 prototype screen grab. Photoshop backgrounds, primitive vector objects and animations.
An evolutionary prototype between 1.0 and 2.0, showing progression of environment designs and the exodus from using bitmap background art.
Axis 2.0 beta prototype. An explicit set of directions were provided for the beta.
Axis 3.0. Not much has changed in the interface, though scrolling and improved art passes have evolved the art style in subtle ways.

Axis Kailash. The character's name is heavy with metaphors related to the 2.0 version of the game's concept. The Axis Mundi is the center of the world, often depicted by a tree, spire, or staircase in numerous mythologies. This verticality is represented by the levels in Axis Descending as the player freefalls from level to level, descending further and further down to the lowest point of the world. This lowest point is also the most challenging and may represent the world's version of Hell. Axis is the central focus, whereas Kailash comes from Mount Kailash, which represents the meditative home and seat of power for certain Eastern deities. This represents Axis' rank as a leader within the world and how he is acknowledged by its inhabitants, but also the player's relationship and ownership of their home base. The airship Rinpoche (Tibetan for "precious one", "gem" or "jewel") is this home base. It rests high above the world's shifting floating islands at a "peak" in the metaphysical gamespace, serving as your respawn point and access point for fast travel, crafting, and swapping weapon loadouts.

While there are heavy folklore influences, much of Axis' relationship with other characters in the game and their designs are influenced by my own personal experience. My wife is represented by the blacksmith on the Rinpoche who provides Axis with the ability to grow stronger and upgrade his equipment. Similar to the relationship I have with my wife, as any marriage should be, I rely on her as she relies on me to grow as an individual and grow as a partner. Through the mechanics acting as a metaphor, this is strengthened and the player who has nothing to do with this relationship of mine is assuming that role. Many of the other characters Axis is supported by or competes with represent friends, colleagues, and family.

A collection of characters used within 2.0's prototype.
Axis freefalls from level to level. The shifting islands and flying vehicles in the world provide context for the randomization of the game's numerous environments as you descend further and further. 

A chart depicting the level flow within 2.0, albeit horizontal. The final 2.0 prototype featured 30 drops. Each drop put the player in one of a handful of potential levels, randomizing the experience and incorporating rogue-like elements.

The origin of Axis Descending's vertical level structure comes from discussions and feedback related to the game while it was treated as my graduate thesis project. After 1.0's lack of progress due to lack of interest, and major changes in my life, I was afforded the opportunity to earn my Masters in Experiential Design. Through the program's Thesis course, my interest in the project was reignited. The second version of the project was born and the result of 16 weeks worth of research and studio time can be played here. An emphasis was placed on my research topic, Narrative in Games, and how I could benefit both of my chosen career paths as an Educator and as a Game Developer. Development-wise, I would be able to secure a prototype of a project I had been working on and off with for years. It would lead to the eventual release of a game and profit, of course, but more than that it meant the end of almost a decade's worth of time and effort. My graduate paper Defining Narrative Devices in Digital Gamespaces resulted in a guide for students and developers alike to follow to make informed design decisions when communicating with the player and helped define my identity as an Educator.

Completing my Masters left me in a situation not unlike what prompted the original "two week long" project. My progress is entirely self-directed again. After the birth of my son and a brief hiatus over the summer, progress is remaining consistent and the plan to campaign and release the game on the PC platform is moving along. While this post was merely informational and divulged the history behind the project, future posts in the 12-post series will highlight key methodologies, like playtesting, my creative process in Flash, designing the levels for the game, marketing it, and more.

If you have any questions, you can contact me most easily via Skype under the username: nujakjata.

By The Light Development

Play the game here.

 Spatial instructions help define the "what" and "where" when it comes to direction.

 Custom particles.

Interactive panels that light up when activated, triggering doors to open.

Orange indicator near character's right shoulder (your left) directs the player to the Lantern when it is set down.

Subtle hints regarding a fateful encounter.

New look for the enemy Seeker shadows.

Working on feedback particles and effects to make hits feel good.

Some enemies come from below!

Some encounters are triggered by entering specific areas.

Darker ambience, updated textures/shaders during the first major pass.

The sword and shield are illuminated similarly to the lantern to create an association of light.

Initial stab at a swinging trail, courtesy of Melee Weapon Trail.

The player also has a light, colored blue contrasting the lantern's orange, that represents his health.

Just getting the lantern mechanic down, well before updating the character model and environment assets.

Narrow path near the entry point.

Bridges throughout the level represent pathways that have collapsed due to some event.

Establishing a sense of direction within the environment's context. Follow the tracks to success!

Comp of the final model used in-game.

Wireframe comp.

Mid-Spin Attack

Idle poses.

Quick rendering showing symmetrical/asymmetrical discrepancies.

A quick mood sketch, Mordigaine's color palette, and the reference used for the 3D model.

Pre-production sketches in Flash, utilizing symbol graphics to duplicate and easily modify individual shots. A great way to quickly provide some visualization for a project.