Behind the Release of Axis Descending: Challenge

Ahh, beautiful. The calm before the storm of soul-crushing difficulty.
I purchased Chrono Trigger and Spelunky from Boss Fight Books recently and had them read by my second day of ownership. While Chrono Trigger was an interesting take on one man's experience and observations with the game, which opened my eyes up to things I never noticed, I found Spelunky to be coincidentally thought-provoking. As I was reading a particular passage on Derek Yu's difficulty and challenge philosophy, I saw a tweet convo between Joakim Sandberg (Iconoclasts and Noitu Love) and Notch (duh)  regarding the same topic that, to me (and I may be reading into this, but play along), contradicted Derek's statements.

"I think that if a dev makes a conscious statement that the games are difficult there shouldn't have to be an argument to put an easy mode in."

When we speak about a challenging game, we are really talking about one of two ends of the spectrum as a consumer of the game's industry. You may be discussing them in a similar fashion. You had been cheated by the game or that something put before you seems utterly impossible. Damn this game, you say, but it isn't always the game, right? You may return to overcome it, or you may not, but in the end you may have been trumped by the design instead of impaired by it. One end is overcoming the challenge because you can, and more often than not, you had not done so because of the factor of player skill (a combo of knowledge and ability to do or perceive). Alternatively, you could not overcome the challenge due to faulty design patterns and practices, placing you in situations that find you suffering from making any progress regardless of your skill level.

When we speak about games and challenge, we often draw upon the era of the Arcade, or one of a select number of high risk/reward games. Dark Souls or Rogue-likes, usually, that stick to implicit narratives, leaving players to discover their own way, and experience moments where things were so tough and high-tension that merely landing a "final hit" became a memorable time-slowing moment worthy of a Let's Play. Games were built to be difficult to feed the machine more quarters in the Arcade days. Now, many indie games strive for a fair, but challenging design philosophy. One that gives players simple lessons with simple mechanics and throws their capabilities with those tools into question with various ramped-up scenarios.

Defeat the basic soldier. Then another. Now you have an archer in front of you with slow, direct, but powerful attacks. Now you face a soldier and an archer, so what do you know? The soldier may chase and use a simple attack, but that archer has slow heavy hitting arrows. What does this mean? The strategy inherently is influenced by more than one agent, but because of your previous experience you have knowledge. You are equipped to handle each one individually. Now the question is how you will juggle these two behaviors/agents in order to persevere. Slay the archer from a distance? Focus on the soldier first? Add another agent, or two, or multiply this in any way and you are severely escalating the challenge level of this scenario.

We're talking about two things now. Level Design. Enemy Design. Scenarios put in front of a player's PVE/single-player path that task them with stopping, evaluating, and acting while reacting based on their position in the environment in relation to the position and behavior of the enemy agents. There is a third thing related to challenge, however. Tools at the player's disposal.

Alex Preston of Heart Machine and Hyper Light Drifter was under fire a bit for a few updates made to the game that modified the player's toolset dramatically. Invincibility frames where there were none, less aftercast with melee attacks, and more changes brought a difficult game to a very different realm of difficulty. Since, another update has reversed and modified these changes to find the best of both worlds. Alex spoke of the Level and Enemy Design in the game with Bryant Francis, noting confidence in using the environment to teach players and allow the world to instruct and teach, instead of holding the player's hand with aggressive explicit narration or non-diegetic dialogue.

Andrew Stewart of Triplevision Games recently successfully kickstarted Mable & The Wood. Back in March he was interviewed by Lena LeRay for a Gamasutra article discussing the changes the game went through from Ludum Dare prototype to a full-fledged experience. There, he notes taking the gamespace from a single environment with randomly spawning enemies to a handcrafted and guided user experience with intended challenges and scenarios. Additionally, the largest change from the prototype is the addition of new forms the player can take to get through the game, potentially opening up challenging and optional content based on the mastery of these shapeshifting forms.

In Super Mario Bros., the tools were power-ups, giving you another layer of health or the ability to sneeze fireballs at enemies. Latter iterations of the franchise produces everything from Boots to Suits to variable character-specific abilities or modifications. Many of these are the backbone of Level Design for environments made in Mario Maker, which boasts a large community of level makers. Polygon has a series called Devs Make Mario, where well-known developers make and discuss their design methodologies.

I'm not trying to break down Joakim or Notch or say anyone was wrong. In fact, I'm glad they had this discussion and brought the contradiction to my attention. I was looking to clarify what my own beliefs were. It lead me to take a look at Axis Descending in a new light, especially after colleagues looked at some of the initial scenarios I've implemented and had things to say about the challenges they perceived. Joakim's statement caters to a user base looking for an experience about his game's world and characters. What happens? is the question that group wants to ask and the answer they want to discover. His statement was a design solution to this problem, meeting the needs and expectations of various players in one fell swoop. Maybe, of course, as it needs validation.

Does that not diminish the capabilities of the medium? If we dilute the experiential in order to attain only mere components of what was intended as a whole, is it still the same? Would a Let's Play suffice, or even a quick synopsis read of a wiki page be a satisfying result? I'm making a giant cake for someone to eat with layers of toppings, ingredients and unknown treats. If I remove some of those layers the cake is no longer what it once was. They won't be able to cherish those ingredients or the harmony of the entire concoction.

Of course, it is up to me as the designer and cook to ensure that cake's flavors, layers and content are all appropriate, but I feel as though that is another subject entirely.

Some games are difficult. Some of those difficult games aren't for everyone, regardless of the elements in addition to their challenges. Yet the tension of the moment, the curiosity of the player, and the reward become so much greater. This is a risk we can take as independent game developers, considering the amount of freedom we have afforded to us. It may seem obvious to reach a broader audience, but do you have to? What are you trying to do? What happens if you do or don't?

Derek's comments on challenge in games were grounded in the understanding that, as he puts it, "We can't be free from frustration and also be challenged. We can't go unchallenged and also feel satisfied with our accomplishments. Mystery, surprise, tension, challenge, and a real sense of accomplishment always come at the cost of feeling uncomfortable. Given the opportunity, many of us would rather take the easier road, but that's usually the less rewarding one."

Behind the Release of Axis Descending: Getting Out There

There is a hurdle that many of my students encounter during their studies in game development. Through an exploration of everything game creation and design, marketing, and salesmanship, they train themselves to execute their leap successfully. Well, potentially. After creating their concept, presenting core mechanics and establishing themes and styles, and iterating and validating their intended user experiences, it is time to show the game off to the public beyond Lawrence Tech's campus. Their project becomes more than just a student exercise. It becomes more than a grade. As it should be, the project becomes real-world and industry-applicable. While their efforts are grounded within the structure of a safe academic environment and platform, their success goes beyond meeting course competencies and objectives. Their success can become entrepreneurial and profitable. Such is the industry, enabling the individual or individuals with a fun and engaging game product game to become their own publisher, tapping into tools, documentation, and business channels that are widely available.

Getting there, to getting work out there, is not the simplest of processes. Students are learning how to do the work itself, which means at times they will fail. Students are learning how to collaborate with others of varying disciplines, which means at times they will fail beyond their control (or not). Without sounding too repetitive, their experience is all about being bad enough times to get good. Their failures lead to successes and understanding. I speak of this generally, mind you, as these failures are not just within the realm of development. They will fail socially. They will fail professionally. They will make bad decisions regarding time management, presentations, or posting their work on studio walls. They will disregard internship opportunities, dismissing it for a number of reasons, or turning them away because they feel unprepared or inept. They must learn how to communicate their ideas, concepts and selling points. They must learn to act, take risks, and hone instincts telling them to do something instead of being dismissive. They must learn to engage and remain engaged.

They must learn to be good students, professionals, coworkers, and adults simultaneously.

Initial passes of an intro cutscene. This should provide players with the understanding of the game world, its history, and where they fit in.

The significance of some of the exposition is expanded upon as the game and plot progress, unveiling secrets to the player through cinematic in-game narratives.
A number of LTU seniors attended GDC 2016 this year. One of them, Brett Gregory, has been developing a slick RTS game called Disunity for his capstone project and received a good amount of encouragement and validation from developers he met there. He has woven all of his course studies into aspects of the game's development, like a directed study to examine and iterate upon its interface design and a capstone course to oversee the development more generally. When asked about his work, he always has content to show despite all of his responsibilities. His Tumblr is updated regularly, he is working on a trailer, and is engaging social media soon to spread the word.

His process is not unlike the process I am following with Axis Descending. When you work on a project solo you accept responsibility for every part of its development. As I've noted previously, indie developers duck dive and dodge their way through the process, taking things as they come and working as many hours as possible. It is important for my students to understand small-scale development and the relevance it has in the industry today. It is also important for my students to understand that working alone is not working alone. You do the work alone, but without users, testers, purveyors and so on no potent connection can be made with our little pocket of game space and the outside world.

Lucas Pope. Alexey Pajitnov. Ede Tarsoly. Eskil Steenberg. Nelson Sexton. Luke Hodorowicz. Robert Pelloni. Brian Provincianos. Jasper Byrne. Derek Yu. Daisuke Amaya. Eric Chahi. Markus Persson. Joakim Sandberg. Zoe Quinn. Jonathan Mak. Tom Francis. Terry Cavanagh. Alex Lanzetta. Anna Anthropy. Mitu Khandaker. Sophie Houlden. Erin Robinson. Paulina Pabis. Brett Gregory. Mars Ashton.

Solo indie developers. All working within the limitless potentialities found within today's industry. Want to make games for a living? Show. Tell. Talk about it. Engage with others. Develop a community. Get your work out there. Most importantly, have a way for people to keep coming back to it. Show enough, work enough, sell it enough and you will find fame or infamy.

I watched The End of the Tour recently, in which writer David Lipsky looks back on an interview he did with novelist David Foster Wallace. While based on a true story, I'm only commenting on the drama performed by Jason Segel and Jesse Eisenburg, playing Wallace and Lipsky respectively. During their brief time together, the two writers became very close, but their egos weren't always in alignment. They fought over the attention of multiple women, fought over the potential perspective of Lipsky's story, and fought over the fame and success that Wallace had and wanted more of, but that Lipsky didn't have and merely desired. At times Wallace notes how he becomes extremely reclusive and isolated during his writing process, struggling professionally, but more so personally, as he was his biggest critic. He tells Lipsky at the end of their time together that he wasn't entirely sure Lipsky would want to be in his shoes. This struggle with the ego, creating content that is so deep and empirical and locking yourself away to do so, is not uncommon.

Imagine working on a project for an entire year solo. This is the most personal, professional, deep-rooted struggled you've had with anything you've done in your entire life. You finished it, even though it feels unfinished or surreal to have it completed. And people love it. And people buy it. And you're suddenly getting phone calls, emails, and offers. Would it validate you? If you were told you're one of the most innovate designers, educators, artists, writers, or whatever of this century, do you think you would feel it to be true?

From a young age, I spent the majority of my time in my room engaging my own creativity and entertaining myself with games of all kinds. I emulated the styles of my favorite game characters. I built everything from vehicles to environments with Legos until I was 16 on a table in my room entirely dedicated to the hobby. Recently, my Mom discovered boxes of my notebooks filled with sketches, notes and ideas from my childhood. I am an introvert, through and through, so when I found myself in college culture, it was a bit of a shock. Presenting in front of others left me with a hurdle to jump over. I needed to learn how to be confident about what I was talking about, which meant being informed and responsible for what I said. Considering my grade school history, including not graduating high school and earning my GED to get into college as soon as I could, my skillset was limited. I was not involved in team sports. I only had one or two close friends growing up. Most of my social experiences involved a girlfriend or two and the circle of friends they introduced me to during those relationships. However, I had a few friends online that I spoke with on a regular basis. In a way, they fulfilled the social aspect of my life I never had throughout high school.

The program held an annual conference called Interfaces that brought in some big names and companies. I remember spending plenty of my time then working through the Creation Kit for Fallout 3, modding and familiarizing myself with the tools. At the conference, Chris Avellone, who was working on Fallout: New Vegas, attended. I did not introduce myself. I didn't even know the opportunity that was placed directly in front of me. I did not inform myself. I didn't know his work well enough, his business, and I surely didn't see myself making the cut to get on the team shortly afterward when I found out what I missed. I regret that, and never wanted that to happen again. So, I had to learn how to talk to people in the same room the way that I spoke to my friends online. I made mistakes. I said the wrong things at times. As my studies went on, I was learned how to be a good student, professional, coworker and adult.

Through academics I've pushed this concept. I've placed many opportunities directly in front of students, only to have them bail at the first possible chance they can get to do so. I see it, I make them aware of it, and hope that they see the result of their inaction and move forward with a stronger dedication to not only the craft, but the social aspect of the business. You aren't just trying to make great work, you also need people to like you and become interested in you as a professional and coworker. You don't need to be loud and outgoing. Just be interested in what other people are doing.

Below are a few noteworthy points of interest for this "getting out there" endeavor. I've tapped into many of them. Maybe you should too.

Boston FIG
Ludum Dare
Global Game Jam
SXSW Gaming

Behind the Release of Axis Descending: Scope Creep and The Unbeaten Path

The Nexus before/after. At times color choices alone take a fair amount of time to decide.
My general development methodology and process is not unlike the way people tend to traverse levels in games with an occasional optional path or two. Providing deviations from the core linear path taps into the curiosity of the player, ideally rewarding them for exploring and making them wonder what was missed if they chose to ignore it. At times, you find nothing at the end of a long pathway and feel frustrated as you hoped to find something useful, new, or fun. Over the last few weeks I've been developing the first two levels of Axis Descending and crafting the tutorial/introductory experience. After finishing the first level, I deviated, doing some exploring of my own in an effort to fix bugs, modify some narratives, or iterate on art/animation. Most of the time, I did fix those bugs and I felt happy with my iterations. Other times, I found out that bugs were not entirely fixed, and needed more of my time to resolve, or that my iterations weren't quite what I was hoping for. Like a spiky-haired hero in a JRPG, I sometimes find myself discovering a measly Potion instead of a new weapon or key item. Yet, when I land that path that shows me something new, I can't wait for more.

Typically, these new paths open up my mind and introduce all forms of Scope Creep. In general these moments are said to be avoided, but like a monk meditating in a waterfall, you can become one with the stream, be unphased by the rushing current, and simply become a part of it. These moments can offer some fantastic insight and retrospect that benefits the project in the long run, or blindly encourage the unprepared and lead them to dismay and destruction. You can choose to ignore the potential creep, but if you follow that path in hopes of finding some treasure you're taking a risk. Even with careful management and planning the new idea may derail and never work out. Is it worth the time?, you may ask, but it never becomes clear. Experience and knowledge with provide you with the confidence needed to know when it is done, but that only comes with time, practice, and above all the exploration of what you're trying to dive into.

My Grandfather, who spent much of his free time woodcarving, creating and painting small-medium scale plane models and painted regularly on canvas said this about art: "A good artist knows when to stop". Much can be said about that statement and what can be derived from between its lines. I don't remember many of the things my Grandfather told me while I was growing up. Between that and the story about how he was called a "Cherry Boy" during the Korean War by natives because he had a lady waiting for him back in the States, I may have one or two stories. They probably involve binge watching television with him. Iron Chef and Law & Order SVU, specifically. Over the years I've argued for and against his statement, but now my perspective on it has changed. You can argue it this way and that way, but if we're talking about it and considering it, we're doing something right. We are evaluating ourselves and critiquing our time management and ability. We have to embrace doing the wrong thing sometimes, but we only know it was wrong in retrospect.

Don't be afraid of Scope Creep. Embrace it without fear and use it to your advantage. All it is doing is giving you insight and an opportunity to analyze your progress and take steps necessary to make informed decisions. See also: Epiphany.

Axis Descending is a Metroidvania game with Action, RPG, and Rogue-like mechanics weaving a narrative about a man trying to fix something. He made some mistakes and is going to slash, dodge and double jump his way through his enemies, collecting their loot to upgrade his gear. If defeated, he retains everything he has looted, but will have to redo the levels he had completed.

After completing the tutorial levels, you are given access to "Drop 1", which consists of 5-8 randomized levels resulting in a boss fight level. If you perish in level 3, you'll return to your player ship where you can do "Drop 1" once again. Each time you access a "Drop Sequence", level 1 may be one of 3 areas. It may be an enemy airship you have to infiltrate and destroy, it may be an enemy fort on a floating island, or it may be a rare friendly ship with a quest to locate a lost item found elsewhere. To avoid the frustration of reaching a boss fight, dying, then having to restart all of those levels again, there is a potion that can be made in the game that acts as an "extra life", Making this potion is done via fishing, which was the result of traveling the unbeaten path. Earning it through alternative methods other than the core gameplay mechanics is an appealing change of pace for players and something you'll be able to experience in Beta 3.

Examples of upgrades and skins currently available. More will be added before Beta 3 goes public.
On a side note: Setting foot in an area unlocks that area to be explored directly from the player ship, allowing backtracking without the annoying task of repeating Drop Sequences for the chance you get the intended area to appear.

Below is an example list of tasks, things to consider, and goals for Axis Descending's Beta 3 and beyond. All of these are taken in my "AxisTodo" notepad++ file that acts as my project doctrine and management sketchbook. By arranging of all this, it helps me prioritize these ideas, be it Scope Creep or fundamental tasks, and compartmentalize things to aid in development.

Beta 3 Core Goals (To be added before public beta)
  • Intro Cutscene
  • Inner Monologue "Ghost Axis" Controls Tutorial
  • Villain/Nexus Tutorial Levels
  • Port Severn/Rinpoche Levels (Quests, NPCs and shops/Player Ship)
  • Drop/World Map Select

Beta 3 In-Development Update Goals (To be added during public beta)
  • Wardrobe UI (Swapping weapons, armor, helms)
  • Fishing (How to get HP, MP, Revive Potions)
  • SFX by Dylan Packard
  • Dual Weapon Type (Dual daggers, dual swords, axes, etc. with rapid strikes)
  • Polearm Weapon (Staff, Lance, etc. with enhanced reach)
Level Design Notes
  • Axis' jump height without High Jump is 1sq (tile)
  • Axis' jump height with High Jump is 2sq
  • Pinnacle platforms must be 3sq wide minimum due to Wall collision getting sassy when side by side one another
  • Avoid generating "steps" of tiles to ascend in early levels, as you constantly have to jump up over every step and that is NO FUN
  • Ground tiles are wider than 1sq to avoid straight up falling between sq or skipping along them
  • All Wall tiles must extend an additional sq down to avoid Axis from diagonally cutting through the world collision
  • More destructibles, people love breaking stuff
  • More interactables, like ropes and grass that gets pushed around
  • Jump + Dodge gives added horizontal distance, use this as an intermediate gating mechanic
  • While close to a wall, dodging away from it gives you a huge horizontal distance boost, fix this bug/transform it into another intermediate gating mechanic for reaching hidden areas
  • More hidden/expose-able areas in the environment, like bombable walls and walls destroyed by tools/abilities
  • Hookshot Claw can grab wall clippable objects and pull Axis to them
  • Hookshot Claw should be able to pull boxes or other objects to Axis as well
  • Utilize Axis' lightning abilities to interact with machines, charging them up, activating them, or shorting them to solve puzzles
  • Tilesets: Airship, Nexus, Grassy Isle, Sandy Isle, Winter Isle, Port
Quests & NPCs
  • Jahn in The Pit, nearby the world map/level select area, emphasizes conveyance for player's lost on what to do
  • Art Collection Quest, giving players a scavenger hunt and reasons to jump back and forth between NPCs and various locales in the world
  • Bosses are immortal and return if you repeat a drop, unless a specific item is used, which activates Hard Mode for that encounter and allows you to earn pieces of Axis' Relic Armor
  • Once all Relics are collected, Axis gains access to a new set of armor and special bonuses
General Mechanics
  • Introduce two camera modes: Combat and Exploration, that either center the screen to focus on combat and avoid jittery movement due to Axis' dodging, or Exploration that shows more of the screen ahead of the player's current direction
  • Implement a potion that acts as a one-time Revive. This will avoid frustration for players who are quite a few levels in and want to avoid the Rogue-like "reset to hub level and lose level traversed progress" mechanic, while additionally giving them a goal to pursue with the item/materials to create them.
  • Implement a Camera Shake to be used for tension, effects, and so on
  • Main Menu options for Quality, Resolution, etc.
  • Fishing game on the Rinpoche (player ship) that provides materials used to make health/mana/revive potions.
  • Fishing poles and lures can be found and swapped, changing 

As a solo developer, I'm not managing a team of people or planning around dependencies. I'm developing a game straight-ahead, handling everything at once while only being able to focus on one thing at a time. This requires going through the iterative cycle a few times whenever I implement something. Realistically, I'm going to be spending a lot of time on some things. At times, those things will not have been worth it, but if we consider how necessary it is to explore within our designs, we'll find merit in failure.
    Axis will be able to get his haircut! Also, helmet, hood and masks skins will be available to collect.

Behind the Release of Axis Descending: The Sketchbook

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

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

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.