Welcome!

•December 29, 2011 • Leave a Comment

My name is Ryan Hickman and I am a Game Designer. I have an artistic skill set with technical understanding that allows me to work and communicate with all disciplines. Please feel free to browse my site as I discuss some of my experiences. Check out my Portfolio for a projects index or Design Topics for a more detailed look into my design process.

Questions or Comments?:

Email: rhickman.design@gmail.com

Advertisements

My Core Game Design Philosophy

•September 25, 2011 • Leave a Comment

1) “The purpose of fun is to have it.”    — Anonymous

2) “It’s more fun when you’re not the only one having it.”   — Anonymous

3) “It costs time, money, and man-power to make a game; it costs absolutely nothing to make something epic.”   – Rob Pardo (Paraphrased)

4) I design for Mom and Dad. It gets everyone to play.

5) Trust your Gut. Believe the Player. Use your Head.

Deity Release Trailer 12 – 16 – 2011

•September 25, 2011 • Leave a Comment

(Lead Game Designer on Deity)

(Pirates of the Caribbean: Isles of War) Combat Balancing – Light vs. Heavy

•August 1, 2014 • Leave a Comment

As part of the strategic depth to Pirates of the Caribbean: Isles of War, one aspect we pushed for was a soft Rock-Paper-Scissors (RPS) relationship between hull class types of the same tier strength. As part of that relationship, the primary classes were Light, Standard, and Heavy. The Light hull class was the typical fast, low-health, low-damage style of play, which could really utilize its speed to either kite or zero in on targets. On the other hand, we had the Heavy hull class, which had large amounts of armor, health, and firepower, but was incredibly slow and hard to maneuver quickly. The Standard class was the jack-of-all-trades style of hull, which had average stats across the board, but did not particularly excel in any one category. In our ideal RPS model, our goal was to make a relationship cycle that supported the following:

rps_potc

The initial assumption I made when attempting to create this relationship was that speed had the highest impact potential in a given combat scenario, as faster speed allowed for both maintaining a steady rate of damage, as well as surviving longer by dodging enemy fire range. Since Light class hulls were intended to be one of the fastest class of hull in the game, I accounted for a high speed stat by lowering the class’s general survivability and maximum firepower. In theory, this made sense, and initial playtesting demonstrated this to be a fair assumption. However, once the game went live, players were ultimately drawn to only the Heavy class hulls, and concluded that both Light and Standard class hulls were ineffective. I realized that this dominate strategy would turn into a long term problem, as it would become increasingly difficult to create desirable new content or prizes, and also reduced the overall strategic depth of the game.

At first I thought perhaps players were seeing the lower health numbers of the Light hull and had not come to terms with how to fully leverage the strength of speed. However, as I began testing with the same cannon load out and Heavy class hulls that players were using against Light ships, I began to realize that there were some additional factors that I had failed to take into account.

In Pirates of the Caribbean: Isles of War, firing range was not your traditional 360 degree coverage, but instead, a cone on either side of the hull, adding unique gameplay, as well as more accurately reflecting how ships battled during the 18th Century. While this was a core pillar to our combat system, it resulted in additional balancing challenges, including time on target. Even with the fastest firing cannons in the game, I found it to be incredibly difficult, with fast moving hulls, to get more than two shots fired per pass at an enemy without taking substantial damage. In other words, the drawback to having speed, as a direct result of our firing range system, was that it was actually more difficult to deal sufficient damage without being overly risky.

After taking time to consider all viable options, and discussing the issue with my team, I came to the conclusion that a new stat needed to be added to the game: Evasion. Evasion would reduce the accuracy of oncoming attacks by X%. By adding in evasion, it would not only add a new way to survive outside of health and armor, but also thematically created the survivability aspect of having speed and agility. In addition to evasion, I gave both Light and Standard more maximum potential firepower, specifically by allowing each of them to hold an additional cannon. This way, faster moving ships could have more shots per pass, and ultimately deal more damage during the course of the battle.

junk_screenshot

After adding evasion into the live game, I began to see a change in player perception towards non-Heavy hull classes. Players quickly became aware of the strength that evasion provided, especially as they began to have more difficulty winning with their Heavy ships against NPC Light ships. As a result, players debated over what the next best hull class was, and started to use not only Light and Standard classes, but all other secondary classes in the game as well. There was an increase in diversity of fleets, as they became less homogenous, and players began building fleets that were specialized for different aspects of the game. Additionally, new hulls that were introduced into the game, or prizes awarded from events, became highly desirable by all players, and ultimately created far more strategic depth and a richer experience for Pirates of the Caribbean: Isles of War.

(Deity) Level Design Process Work

•May 8, 2012 • Leave a Comment

This is a showing of some of the process work for when creating levels for Deity. Even though there are only 4 levels in the final release of the game, I had built many different levels that were used to pinpoint the most fun aspects of the game. Below is some of the process work that I did when creating levels for Deity:

The video above was Deity during our Alpha phase. At this time, I was experimenting with the idea of allowing the player to pick their own path, and that multiple paths lead to some of the same areas. This worked extremely well on our enemy army level, as it allowed for a dynamic hide-and-seek encounter. However, non-enemy levels suffered greatly from this design, largely due to the fact that players would end up running in circles around the level without realizing it. Since our game wasn’t going to have a minimap, this proved to be a fatal flaw in the level design, and had to be reworked moving forward with the project.

As the team began reworking our game for Beta, I started playing with the idea of having modular rooms layouts. This way, I could have a room that was well put together and still allow for flexible level design. I think had we made the levels be created through a procedural generation method, this level design concept may have worked. However, it was important to the team that we had a unique and interesting experience with each and every level. Therefore, the rooms idea was scrapped in favor of more customized levels.

I ended up studying more isometric games, such as Diablo III, and started to dissect what they were doing for their levels and why they were doing it. I began to experiment with the linear approach to our level design, as I felt it easily fixed the layout problems we had at Alpha, as well as lead the player to the end of the level. As a result, we had the following level types at Beta:

At this point, we had brought the game to PAX and had countless players play our game, which they all really enjoyed. As I was watching however, it occurred to me that some of the elements that we liked about the Alpha level design, such as the more stealth elements to the game, were lost with the new level design principles. After all, how can you be stealthy in a hallway? We found that a linear path worked great for action, but we didn’t want to lose the stealth feel to Deity.

(Level Design concept work to help with path types & look and feel)

At this point, I had to reflect on everything I had learned from both Alpha and Beta. The underlying principles that the Alpha build had brought a fun aspect that the Beta version hadn’t replicated. On the flip side, Beta was much more direct, helping players get from point A to B without much confusion. I concluded that having the best of both worlds was the best way to go. In other words, we create encounters in an open space environment, but there is a specific continuation point at the end of the encounter. From the player perspective, this would read as needing to go from point A to B over the entire level, and then from point X to Y within each given encounter area. Once comfortable with this design concept, I began laying out more specifics of the level design for the end product.

This was the starting point for what became our first level in the final product. When designing this level in particular, I was most concerned with making sure that the player could learn to play the game. I go into great detail about this level in my “Teaching Through Level Design – Level 1: The Invasion”  topic. Out of all of the final levels created, this level remained the closest to the original concept.

This level was intended to be a level where you killed enemies with flags, which allowed you to complete the level. There would be have been a bridge in the middle that lowered once you had killed all of the flag carriers that would open to the second part of the level. In theory, this sounded like a fun level, and I was aiming to take the enemy army level from Alpha and put an updated spin on it. However, after doing a rough block-in of the level, the level became too large and too technically demanding for the time constraints we had. Plus, it just wasn’t as fun as I had hoped for it to be. Ultimately, we took elements of the enemy army level and placed them into a sub-section in the final build of Level 2.

In Level 3, I had designed this level where worshiping Clerics would travel along a path as they worked their way to the 4 alters. There would be a Head Cleric in the center, who was preaching and doused in light (and therefore impossible to kill under normal circumstances). The goal was to convert all of the alters to blackflames, which would elevate a statue, and cast part of a shadow over the Head Cleric in the middle of the level. If you managed to convert all 4 alters, the Head Cleric would become exposed, allowing you to kill him and complete the level. I really enjoyed this level concept, as it brought a new spin and some diversity to the levels that we had. In this case, I broke my own design rule about open spaces. However, I felt that since the alters would be so noticeable and obvious as to which were converted, that it would be far less likely to actually get lost or go in circles unintentionally.

When it came down to execution, we wanted to have the game still feel cohesive with itself, as well as make it less demanding on the technology. Therefore, the final build of Level 3 has the Head Cleric element, but also has a “library” component where you deal with the Valkyrie. We found this to feel better overall for the level, and made the game have that extra sense of danger and stealth element.

The final level was something the team and I always spoke about. We really wanted to have a gauntlet encounter, as well as an epic battle between the player and the Valkyrie. The layout above was a really rough idea of how we wanted to handle the Valkyrie fight. The idea was that you would leap from torch to torch and trying to avoid her attacks. By turning off X many torches, you would stun her and be able to attack her. While the exact layout was definitely changed, this was a great starting point for discussing how the final level should be handled.

After all the levels were blocked in, the environment artist and I would go through the levels and adjust lighting, add props, and really create and improve the atmosphere of each and every level. This was obviously an important step, and really taking the time to polish each level just elevated the quality of the game that much more.

I think looking back on my process, it could have definitely been improved. Since the game was on a grid system, it would have been better had I made the levels on graph paper to get a stronger idea of scale and level length. However, the work that I did do followed a natural evolutionary growth as the game changed. I was never married to an idea, and was willing to be flexible due to technology or time constraints. I believe that this helped me get to a better end result faster as took the time to analyze our game’s core fun. Doing so aided me in knowing how to build levels to emphasis that fun, which I feel was a successful part of Deity. To see all the final game levels, I recommend you download and play (for free) at http://www.deity-game.com/ or you can watch one of our fans blow through the game in 20 min:

Game Systems (Experience): DotA vs. League of Legends

•May 4, 2012 • Leave a Comment

This is an analytical study and comparison of aspects of the experience systems in both DotA and League of Legends. Analysis and conclusions made are drawn from game specific behavioral observations and the experience systems analyzed. No other systems are directly calculated into the conclusions for the purposes of understanding the impact of the experience system exclusively to each game respectively. The experience values calculated are based on the Summoner’s Rift variant of League of Legends.

— Total Experience Required —

Graphs / Data

The total experience required ratios in both DotA and League of Legends are incredibly similar. Both use a functional curve to generate the total amount of experienced required to level per level. We can assume then that the potential experience rate of an individual player is approximately equivalent in both games.

Short Analysis

What is interesting is that while there is a slight curve in both graphs, the distance between two neighboring points are approximately equidistant from one another. This means that, from exclusively numbers, that the difficulty to level per level is approximately the same.

It is also likely that a given player will level at varying rates, which produces a tug-of-war effect among players when it comes to experience gain and leveling. This creates a more dynamic back-and-forth scenario, which adds to the drama and excitement that a player or spectator might experience as the game goes later into a match. Similarly, a snowball effect is an equally viable scenario since the experience required ratio is fairly unbiased from level to level.

— Hero / Champion Kills Experience —

(S-Curve Model for Champion Kill Experience as explained by Riot Games)

Graphs / Data

The experience curves that you see between DotA and League of Legends are relatively different. DotA relies almost exclusively on a functional linear curve, with some variation depending on level. While League of Legends also uses a linear function for same-level kills, their varied level kills is dictated by an S-curve function. This is a result of their experience system taking into account for more or less experience based on the level of the slain champion.

Short Analysis

This is perhaps the largest difference between DotA and League of Legends when it comes to the experience system. In DotA, each kill is a flat amount of experience gained, based on the level of hero killed. Additionally, based directly on numbers and player experience, DotA provides far more experience per hero kill, which could result in multiple level-ups depending on the situation. This allows for snowballing to occur more easily while being able to progress the game at a faster rate.

For League of Legends, the philosophy of this game is demonstrated with their experience system. With this system, varied level kills are more accounted for and tailored to a more casual experience. Since the experience system is derivative of an S-curve, the amount of experience gained for killing lower leveled players is less, and kill higher leveled is more. Fairly simple to understand, however, there are few implications with using this system.

The first is that games will naturally become longer provided players kill other players frequently. Since there isn’t a flat amount of experience gained per level of player, then the experience rate is not constant, and therefore unreliable, resulting in longer games. Additionally, snowballing should be less likely, due to the drop of experience that a player can receive per kill (depending on the situation).

The second notable influence is that this system attempts to promote the killing of higher level players over lower level players. Numerically speaking from the experience system exclusively, this would be a logical conclusion. As a player however, I don’t believe this to be the case. This is due to the fact that a player who is alive, getting gold, and is able to contribute in a team fight (no matter how large or small), is better off being dead than alive as an opposing player. Regardless, the experience system itself does support the notion of killing the higher level players over lower levels.

— Hero / Champion Assists Experience —

Graphs / Data

DotA provides experience to any allied player within 1000 units of an enemy killed, regardless of contribution. This experience is split among all allied players within the specified range. Simply, the more heroes that were in the area of a kill, the less experience each allied player receives.

League of Legends provides an allied player with an assist if a given player has contributed to a fight and was within the last 10 seconds. A player who has earned an assist will evenly split the total experience awarded from the slain enemy player. You must be part of an assist to receive experience.

Short Analysis

This is an interesting distinction between DotA and League of Legends. By DotA providing experience to any allied player in range of a kill, it allows for players to more easily level up, as well as give reward to those players who may have influence a fight without actually fighting (such as blocking a path).

League of Legends demonstrates the concept of rewarding action, so only players who actively participate in a fight, within a specific duration, are rewarded experience. This makes leveling as a group slower while promoting individual contribution through direct action. Based on theory and observation, this difference could be a contributing factor towards seeing better team plays in DotA compared League of Legends.

The Future of Narrative in Games

•April 27, 2012 • Leave a Comment

The subject of narrative and story in video games has been something that has evolved over a lifetime.  Games have become a medium of art that expresses a way of not only communicating, but allowing the player to live experiences that the artists want to share. I believe this, in many ways, makes the potential of story in games incredibly more powerful than movies. Don’t get me wrong, movies are great, and are amazing at sharing experiences in a creative way. However, movies can’t do what makes game so magical: viewers can’t interact with movies like they can with games.

In modern games, you commonly see story or narrative presented in one of two ways: to tell the player the story (Final Fantasy) or to have the player influence the story (Mass Effect). However, I believe there to be a third type, and perhaps more meaningful way to present story, which is almost entirely unique to the new generation of games and technology.

Before I go any further, I want to talk about . Now, I’m sure a majority of people are familiar with social networking sites and all of the unique experiences that those provide. After all, with the click of a button you can follow the life of friends, family, or acquaintances that you wouldn’t have access to otherwise without speaking to them face-to-face. With Facebook however, it goes a step further. You’re not the only one who gets to voyeur in on the life of a friend. Your friend’s friends and their friend’s friends can also see these experiences. They can “Like”, comment, or share the same experiences. This is the defining point of Facebook, and the glue that holds the whole system together. In essence, people sharing experiences with other people.

You actually start to notice the trend of people sharing stories with each other with online games. A lot of the time, player’s aren’t saying, “OMG DID YOU SEE THAT DEMON SHRED THAT GUY IN TWO?!?” As cool as that may have been, more often than not, players express their own individual experience that they had in the game. Let me give you a story of my own to illustrate this point:

Some friends of mine were playing World of Warcraft with me. We were in the same guild and part of the same raid group. In this particular case, we were on our conquest through Firelands, a place with vast area of volcanic activity, erupting fire, magma, millions of enemies, and epically giant bosses. We had been working for couple months trying to defeat this particular area, and eventually got to the final boss. We prepped ourselves, read the guides online, and discussed strategy for our own group composition. We felt completely ready and charged in, guns blazing, ready to annihilate this final boss.

We died. Over and over. Endlessly. Every fight was the same. We would walk up to this massive fire elemental with a giant hammer, he would give his speech about how the world was doomed and our lives would be destroyed, and then began wrecking havoc on our group. The boss would then cast a giant fire trap for our team to trigger, along with minions, fireballs, flame trails, and meteors. This scripted event never changed, and we would die all the time to these various mechanics. After countless attempts over the course of several months, we finally defeated the boss and got the epic loot that we had all worked so hard to achieve.

Afterwards, we spoke about our experience. Not once did I ever have someone say, “Yes! We beat Ragnaros! We saved the world! But what about Deathwing?! What happens now?? What does Thrall have to do with all of this?” Those scripted events, the drama leading up to the final boss, the pivotal point in the story: none of that mattered. You know what the players really told each other? In Trade Chat, for all other players to see, my guild members wrote out, “Yeah, we just smoked Firelands. One shot everything; piece of cake. I can see why people would think that’s a hard fight though. But our skills and reflexes were so good that Rag died in like 2 seconds. Now I have epic loots and am one of the most badass players in the world.” As you could imagine, this sparked huge drama over the server, and I had my own personal soap opera for the next hour and half.

This brings me to my point though: players make and share their own stories. It doesn’t matter how crazy or realistic it is, how long it took for something to be achieved, or even what the game story was about. All that mattered was that the player was able to live and experience, and thus creating their own personal experience, and sharing that new experience with others. This makes a lot of sense when you think about it, and people have been doing this long before modern technology existed. Technology simply made it far more accessible and exposed then it ever has in history. It’s the word of mouth phenomena in the 21st century.

So what is the third narrative type in games? I call it the Everliving Narrative. At its core, the Everliving Narrative is the telling and provided experience of a story to a player through other player’s experiences and stories. I’m not simply speaking to the idea that the game world changes based on collective player decisions. While part of the equation, the Everliving Narrative takes story to the next level. Rather, as part of the actual game system itself, allows for players to experience and absorb the stories of other players in a meaningful way, even if those players no longer play. Imagine a game where every person creates a web of intricate stories that collides with other webs, creating a road map for a narrative that never ends. Players continue to write their own stories while experiencing and influencing those of others along the way.

Given the right circumstances and execution, an Everliving Narrative driven game could easily become one of the most compelling and addicting games of all time. Therefore, I believe that this story type, above all else, is worth exploring and experimenting with as a designer, artist, and developer. This would be a game changer to games as we know it, and usher in a new level of games that would define future generations to come.

Flash Development Index

•April 22, 2012 • Leave a Comment

Please click a link below to view a Flash project. I highly recommend  full screen mode when  viewing the projects from the hosting site.

>> Engine – Colored Coin Mania!

Utilizing a component based grid engine, developed a basic platformer, with the objective being to collect all the coins while not getting destroyed by falling meteors. Uses a particle system that takes in a texture as its display. Spacebar to start the game from the title screen. Once in the game, WASD to move and Spacebar to jump around in alternate gravity. Have fun!

>> Particle System

Developed a Particle System that could generate various patterns through an algorithm using exclusively colored pixels. No art or textures were used. Pixels get smeared as they travel along their generated path. Pixels have a random lifetime.

>> Combo Calculator

Designed, developed, and artistically created a themed calculator in the spirit of an arcade fighting game. Use the given numbers to “combo” into ones that are unavailable (i.e. – 3 + 6 = 9). The joystick changes the operation and the coin slot performs a clear. Have fun!

>> Haunted Creature Pong

Designed, developed, and artistically created a themed pong game with fun paddle creatures that you would expect to see in an old wooden haunted house. Exclusively a 2 Player game. To play, each player clicks on the image of the paddle they want to play as (the feedback is a little lack luster for the selections, and for that I apologize). Once you’ve selected, right-click the flash application and select “Forward”. Your paddles will be selected and the game immediately begins! There is no point total victory.

>> Westworld HUD

Designed and implemented a basic shooter HUD for an imaginary “Westworld” shooter game. The mouse will move the gun, left clicking will make a shooting sound, and mouse wheel will change the weapon type icon. Esc will bring a WoW-style menu. This was used to get my feet wet with working in Flash and ActionScript 3.0.

User Interface Design – Tablet MOBA

•April 16, 2012 • Leave a Comment

I thought about how impressive Infinity Blade II was on the tablet, and I dreamed up the idea of having other high quality games on tablets, especially starting with the iPad 3. I thought about how unique the tablet interface was, and wondered if it were possible to create a user interface for a “gamer’s game.” I thought about what kind of game might be possible with the technology, and concluded that a simple MOBA may be possible. The big issue with a MOBA however is the flow, control, and interface need to be precise and easy to understand. With a tablet, this proves to be difficult because your fingers aren’t always as accurate as mouse precision. Regardless, I thought it would be a fun challenge to dream up a potential starting point for an interface for an imaginary MOBA that could be played on a tablet.

(My Designed UI Tablet Quick Mockup – Game Image, Minimap, Portrait, and Team bar are from DOTA2. Item icons from League of Legends. Click image for larger viewing.)

The image above is a rough HUD template that could be used as a starting point. I didn’t want to the interface to feel any less like a computer-based MOBA just because it’s on a tablet. Granted, this took several iterations to actually design a feasible interface, as I constantly ran into a variety of issues that a MOBA on a computer never had to deal with. For example, in a traditional MOBA, players tend to micro-manage their character’s movement by rapidly clicking on the map near their character. For any hardcore gamer, this is incredibly important, and needed to translate smoothly to a tablet interface. Obviously, you could allow the player to tap on the map and the character moves, just like you would with the mouse. While this should be allowed, by having the player constantly tap on the map, their hand would cover a fair portion of the bottom corner of the screen. This opens the player up to being killed (ganked) by their opponent, seeing as the player’s hand could block line of sight from that direction. This seemed really unfair, making tap-to-move reserved for special situations, such as moving to a specific point across the map.

(Image reference for how a gamer may hold their tablet during gameplay.)

To solve this issue, I designed a virtual pad in the HUD, which would react similar to a pad or joystick on an Xbox controller. This way, the player could still micro-manage their character, but their hand wouldn’t always be in the field of view.

Another major issue with a MOBA is camera control. In a MOBA, you can control the camera by locking it to your character, click a location on the minimap, or move your mouse cursor to the edge of the screen (with the camera moving in that direction). Of course, since a tablet doesn’t have a mouse per say, the edge screen movement would be far more difficult to use, as well as potentially creating the same hand-blocking problem as before. The screen edge problem could be solved however through the tablet-specific functionality of dragging your finger. By dragging your finger across the field of view, you can move the camera a short distance in the direction you dragged. Theoretically, this would produce a similar effect that screen edging would provide. Taking from the standard MOBA, you could relocate and even lock your camera by tapping the character portrait in the main HUD, as well as moving the camera through the minimap by dragging your finger to the location.

(DOTA2 reference for standard ability icon locations on a computer platform.)

The last major issue was how to use abilities. When you look at a standard MOBA, the abilities are located in the bottom center of the screen. This is great if you have a mouse or keyboard, but having to stretch your thumbs across an entire tablet could become tiresome. Aside from having the abilities at the bottom edges of the screen, which is already being occupied by the minimap and virtual pad, the best place to have them was on the side of the screen. This allows for quick and easy access to each ability, provided they are slightly transparent, and creates visibility on the screen.

**Note: I believe having a righty / lefty option for players to choose from for HUD directional layout would improve player experience.

———————————————————————————————————————————————————————

Below is a list of interface actions that I designed based on the anticipated needs of the players who would be playing this imaginary MOBA on a tablet:

– Player Movement –

1) Tapping on Map in Viewport – Move character to tapped location.

2) Dragging on Virtual Pad – Constantly moves the character relative to the finger location on the pad.

– Player Actions –

1) Tapping Enemy Unit – Auto-attack tapped target.

2) Tapping Single Target Ability + Unit – Use the selected ability on the tapped unit.

3) Tapping Area of Effect Ability + Viewport

– Step 1: Tap AoE ability icon.

– Step 2: Tap location in viewport. An AoE circle / icon would appear at tapped location. This could be repositioned as many times by the player as they feel necessary.

– Step 3: Re-tap the initial AoE ability icon. The AoE ability now activates.

4) Tapping an “On-Activate” Item – Activates the item ability.

5) Tapping Teammate Icon – Targets / Selects unit.

– Camera Control –

1) Dragging on Map in Viewport – Moves the camera slightly in the direction dragged.

2) Dragging on Minimap – Drags viewport around to current finger location.

3) (Single) Tapping Character Portrait – Returns viewport to character.

4) (Double) Tapping Character Portrait – Locks camera to character.

5) (While Camera Locked) Tapping Character Portrait – Unlocks camera.

– Miscellaneous –

1) Tapping “Stats” box – Shows more detailed stats window.

2) Tapping “Gold” box – Opens up shop window.

3) Tapping K/D/A – Opens gamewide K/D/A window.

4) Tapping Minimap – Pings minimap at tapped location.

(Deity) Teaching Through Level Design – Level 1: “The Invasion”

•April 13, 2012 • Leave a Comment

(Level 1 Playthrough on “Look at That Free Game”)

The level design theory in Deity consisted of two major ideals: to create high-tension moments, even in a low threat environment, and to always have the player feel as if they are moving forward. These played a huge role in how we approached each and every level, and looked to add as many fearful or anxiety moments as possible, while still allowing for periods of rest between each major challenge. Additionally, I found that having the player start in a bottom left corner on the map and move to the top right corner provided the best sense of progression for the player. I found this to be especially true from the isometric perspective, seeing as the angle best promoted directional flow.

When it came to Level 1: “The Invasion”, the team and I recognized that this level would be the very first impression of the game for the player. This meant that we needed to make the level fun and engaging almost immediately, while still allowing for the player to learn how to play in a low threat environment. As a result, pacing became incredibly important, and took a few radically different approaches and iterations to get to the desired result. The biggest issue was making sure the timing between each new piece of information was a graceful transition in order for the player to not feel overwhelmed. This was solved through the concept of bundling key information with subset information with a time delay between each. For example, in Level 1, we teach the player how to use Chain Rift. We let the player experience how to use the ability, but then afterwards, during a period of rest, we explain that activating Chain Rift consumes all your chains. This proved to work because, after doing testing with other methods, we found that telling players how to do something, and at the same time tell them the consequences, caused a lot of confusion or lack of memory retention for the player. By doing a bundling method with a time delay, you allow for the player to experience what you’ve taught them, and after a moment of action, continue to teach. This allows the player to remember more key aspects to the game.

(Level 1 Player Experience – Learning & Intensity)

In terms of how pacing and intensity were handled, the graph line above roughly demonstrates what the player experiences as they progress through the level. Each time we went to teach the player something new, we created a period of rest where the player could take the time to learn and have an isolated experience with the new mechanic. Afterwards, we would increase the tension and general threat levels by adding enemies and more challenging paths. In this way, they could not only use what they just learned, but what they had learned in the past, and use everything together. This way, we created an isolated-collective pattern that we could utilize throughout the entire level, and by the end, the player would have a firm understanding of how the basics of the game are played.