FROM THE ASHES (Sole Programmer)
Game Summary
From the Ashes is a first person platformer in which players take on the role of Arlo, a scout who is finishing his training under the tutelage of his older brother, Marcus. The two brothers live in a broken world in which the earth was shattered and civilization was destroyed. The world is now composed of shattered islands that float in the sky high above the clouds. From the ashes of the old world arose a new, brutal society comprised of moving, flying cities that search the skies for resources to harvest and cities to conquer.
The most feared of these cities is known as "Leviathan." This city is where the brothers call home. As Arlo finishes his training, the two brothers find themselves facing the greatest threat Leviathan has seen in centuries as major upheaval and strife begin to tear apart the remnants of their society.
The most feared of these cities is known as "Leviathan." This city is where the brothers call home. As Arlo finishes his training, the two brothers find themselves facing the greatest threat Leviathan has seen in centuries as major upheaval and strife begin to tear apart the remnants of their society.
Role & Responsibilities
Team Role: Sole Programmer & Team Lead
Team Size: 4 Developers (designer, programmer, artist, animator)
Genre: First Person Platforming
Engine: Unreal Engine 4
Development Cycle: 8 Weeks
Programming Responsibilities:
Team Size: 4 Developers (designer, programmer, artist, animator)
Genre: First Person Platforming
Engine: Unreal Engine 4
Development Cycle: 8 Weeks
Programming Responsibilities:
- Jumping & double jumping
- Wall jumping & wall climbing
- Edge grabbing, shimmying, and pulling up
- Zipline & cannon system
- Player acceleration & momentum conservation
- Grappling hook and swinging physics
- Networked cooperative play
- Custom companion NPC AI scripting elements (UE4 Blueprint nodes)
Creating a Smooth Player Experience
A big component of working as a gameplay programmer is being able to work with other developers across disciplines, especially design. Since gameplay code is what the closest to player feel in game, it is imperative that I am on the same page with the designer to create the best player experience possible. As such, I worked closely with the designer to co-design the game's systems and mechanics.
A major goal for the project was to make the player experience as smooth as possible. What this meant from a development standpoint was trying to reduce sources of friction.
As I was tasked with implementing player movement and abilities, my primary concern was to make sure that the controls felt smooth, natural, and intuitive. A significant goal for the gameplay code was that it should predict and handle the player's intention when interacting with the world, especially with regard to wall running and swinging. The sections below detail my approaches to solving this problem.
A major goal for the project was to make the player experience as smooth as possible. What this meant from a development standpoint was trying to reduce sources of friction.
As I was tasked with implementing player movement and abilities, my primary concern was to make sure that the controls felt smooth, natural, and intuitive. A significant goal for the gameplay code was that it should predict and handle the player's intention when interacting with the world, especially with regard to wall running and swinging. The sections below detail my approaches to solving this problem.
A Feeling of Physicality And Motion
The Question of Acceleration
A big challenge in the project was making the player feel like they were moving with a physical body, as opposed to feeling like a floating camera. Initially, our movement system felt like the latter, which works fine in genres such as First Person Shooter. In our game, it felt stiff and unnatural due to the fact that the player character moved at full speed the moment the player input anything.
The key to handling the issue was handling acceleration. The above example of stiff movement happened because the character essentially did not having a meaningful acceleration value and made it to top speed almost instantly. Popular platforming characters such as Mario and Sonic have distinct characteristics in their acceleration. To make the character feel physical, while also feeling satisfying to control we tuned the movement to add acceleration values for all states. We had to adjust the acceleration several times to ensure that the player never felt "drunk" due to long acceleration times, but they also felt responsive without removing acceleration entirely.
Momentum Conservation
When a character has significant acceleration then an additional player objective is implicitly added: keep the speed you've gained. Once players get going quickly, they enjoy the challenge of keeping that speed by smoothly traversing the environment . As such, I added the momentum conservation feature, which allows players to move faster than their top speed on the ground if they build up speed from swinging, wall running, or other actions. Their "bonus" speed that they earn slowly dwindles, which encourages players to continually wall run and swing in combination to keep their speed up.
A big challenge in the project was making the player feel like they were moving with a physical body, as opposed to feeling like a floating camera. Initially, our movement system felt like the latter, which works fine in genres such as First Person Shooter. In our game, it felt stiff and unnatural due to the fact that the player character moved at full speed the moment the player input anything.
The key to handling the issue was handling acceleration. The above example of stiff movement happened because the character essentially did not having a meaningful acceleration value and made it to top speed almost instantly. Popular platforming characters such as Mario and Sonic have distinct characteristics in their acceleration. To make the character feel physical, while also feeling satisfying to control we tuned the movement to add acceleration values for all states. We had to adjust the acceleration several times to ensure that the player never felt "drunk" due to long acceleration times, but they also felt responsive without removing acceleration entirely.
Momentum Conservation
When a character has significant acceleration then an additional player objective is implicitly added: keep the speed you've gained. Once players get going quickly, they enjoy the challenge of keeping that speed by smoothly traversing the environment . As such, I added the momentum conservation feature, which allows players to move faster than their top speed on the ground if they build up speed from swinging, wall running, or other actions. Their "bonus" speed that they earn slowly dwindles, which encourages players to continually wall run and swing in combination to keep their speed up.
Wall Running
Preventing Tedium in Level Design
Given our small team size, I had to be careful with adding any additional work to the level design role, given how tedious the job can be already. What I wanted to avoid in particular was requiring the level designer to place additional "nodes" or information that designates a piece of geometry as being "wall runnable" and on what faces of the geometry, in addition to placing the geometry itself. My goal was to have the level designer just place geometry as normal, and I would determine if a surface could be wallrun based on its surface/collision and traces. As such, I had to address several factors below.
Iterations of Wall Running & Wall Climbing
The first iteration of the wall running simply had players sent along the wall in the direction determined by their velocity.
Given our small team size, I had to be careful with adding any additional work to the level design role, given how tedious the job can be already. What I wanted to avoid in particular was requiring the level designer to place additional "nodes" or information that designates a piece of geometry as being "wall runnable" and on what faces of the geometry, in addition to placing the geometry itself. My goal was to have the level designer just place geometry as normal, and I would determine if a surface could be wallrun based on its surface/collision and traces. As such, I had to address several factors below.
Iterations of Wall Running & Wall Climbing
The first iteration of the wall running simply had players sent along the wall in the direction determined by their velocity.
Early version of wallrunning sending a player slightly upwards
|
Early version of wallrunning sending a player down sharply
|
The issue with this system was that it was simply too sensitive. In our game, players can initiate a wall run from jumping, falling, or swinging. Expecting players to precisely control their velocity in all of these cases proved to be a stretch for all but the most experienced players. We eventually determined that most player's intentions with wall running were fairly straightforward: they either wanted to climb straight up it, or wanted to move along it. For this reason, we defined two discrete cases: moving horizontally (wall running) and moving vertically (wall climbing).
The current wall running/climbing system
A slight curve was added to horizontal wall running to help convey to players when their wall run was about to expire. The next major challenge was to determine when players wanted to wall run or wall climb upon impact with a wall
Determining If Players want to Wall Run or Wall Climb
A significant challenge upfront was determining which action players wanted to take upon impact with a wall. In this scenario, I looked at the most relevant information that I had when two objects collided.
Looking at the list, I found the last item particularly important. I've observed that in most first person games that players will almost always look at where they want to be travelling. For this reason, I found I could have a good idea of what the player actually wanted to do from the camera. However, just the camera was not quite sufficient.
A notable exception to my rule of players looking where they want to go is strafing. This case becomes especially relevant when players are looking at their objective, when that objective is the *next* move instead of the immediate move. This case results in the player semi-strafing into the wall while they look at where they intend to go after the wall run has finished. As a result, I also had to factor player input.
Juggling several factors by themselves was proving difficult, so I looked for a way to better focus my comparisons. I determined the "ideal" values for each case
Encouraging Use of Wall Running
Wall running has a lot of inherent potential to be fun for players, but we wanted to make sure wall running was encouraged beyond that. We decided to add a speed impulse upon initiation of a wall run so that players could use the geometry to actively speed themselves up. Before the change, we found players could become uninterested in wall running if it felt "slow." After, wall running now became a much more critical mechanic for multiple player objectives, beyond simple traversal needs.
Determining If Players want to Wall Run or Wall Climb
A significant challenge upfront was determining which action players wanted to take upon impact with a wall. In this scenario, I looked at the most relevant information that I had when two objects collided.
- Hit Normal
- Player Velocity
- Player Input Direction
- Player Camera Direction
Looking at the list, I found the last item particularly important. I've observed that in most first person games that players will almost always look at where they want to be travelling. For this reason, I found I could have a good idea of what the player actually wanted to do from the camera. However, just the camera was not quite sufficient.
A notable exception to my rule of players looking where they want to go is strafing. This case becomes especially relevant when players are looking at their objective, when that objective is the *next* move instead of the immediate move. This case results in the player semi-strafing into the wall while they look at where they intend to go after the wall run has finished. As a result, I also had to factor player input.
Juggling several factors by themselves was proving difficult, so I looked for a way to better focus my comparisons. I determined the "ideal" values for each case
- Wall Running (player looking along the wall, pushing along the wall)
- Wall Climbing (player looking up, pushing directly into the wall)
Encouraging Use of Wall Running
Wall running has a lot of inherent potential to be fun for players, but we wanted to make sure wall running was encouraged beyond that. We decided to add a speed impulse upon initiation of a wall run so that players could use the geometry to actively speed themselves up. Before the change, we found players could become uninterested in wall running if it felt "slow." After, wall running now became a much more critical mechanic for multiple player objectives, beyond simple traversal needs.
Swinging Gameplay
Why is swinging fun?
I believe that players find swinging fun due to the fact that most players simply find physics fun. Swinging is a special case under this umbrella because it is something that a huge portion of the population has experienced through rope swings over a lake or a swing set on the playground. Swinging has a unique arc motion that is hard to use well, but is fun for players due to its speed and familiarity.
Why is it Hard to do well?
For this project, it was a significant challenge given that we wanted to do actual swinging instead of using more common grappling types (such as the Batman style reel-in, or a "tractor beam"). A big problem is that if the swinging isn't "canned" then the amount of potential failures for the player increases drastically. For just the implementation, there were a several factors that I wanted to address and improve.
Make it Feel As Real As Necessary
Most players find physics fun. With swinging, most players know exactly how it feels in reality due to rope swings and swing sets. For this reason we didn't want to "can" the sequences. The difficult aspect with realistic physics is that it can compromise the gameplay due to difficulty.
The Problem of "Hidden" Slack
A problem existing in many games with grapple mechanics is an issue of visual conveyance. Unless the rope/wire is modeled with much more realistic with visible slack, most grapples are drawn essentially as a straight line from the user to the grapple point. If a grapple is drawn just as a straight line but has more realistic physics, then the problem of the hidden slack can become apparent if there is slack "under the hood" without visual conveyance, especially if the player is moving.
I believe that players find swinging fun due to the fact that most players simply find physics fun. Swinging is a special case under this umbrella because it is something that a huge portion of the population has experienced through rope swings over a lake or a swing set on the playground. Swinging has a unique arc motion that is hard to use well, but is fun for players due to its speed and familiarity.
Why is it Hard to do well?
For this project, it was a significant challenge given that we wanted to do actual swinging instead of using more common grappling types (such as the Batman style reel-in, or a "tractor beam"). A big problem is that if the swinging isn't "canned" then the amount of potential failures for the player increases drastically. For just the implementation, there were a several factors that I wanted to address and improve.
Make it Feel As Real As Necessary
Most players find physics fun. With swinging, most players know exactly how it feels in reality due to rope swings and swing sets. For this reason we didn't want to "can" the sequences. The difficult aspect with realistic physics is that it can compromise the gameplay due to difficulty.
The Problem of "Hidden" Slack
A problem existing in many games with grapple mechanics is an issue of visual conveyance. Unless the rope/wire is modeled with much more realistic with visible slack, most grapples are drawn essentially as a straight line from the user to the grapple point. If a grapple is drawn just as a straight line but has more realistic physics, then the problem of the hidden slack can become apparent if there is slack "under the hood" without visual conveyance, especially if the player is moving.
This becomes very confusing and frustrating because there is no visual indication of what is happening. For players because it usually happens when they are past the object. In first person perspective, it is very difficult for players to keep track of things out of their view, so the end result is that they feel they are being yanked back arbitrarily, which compounds the problem.
To solve this problem while allowing for Smooth swings regardless of the player's speed and distance from the attached object, I looked to the design of a device I use every day: a seat belt. In the case of rapid deceleration such as a crash, the seat belt's retractor mechanism prevents the seat belt from becoming any more slack. I realized that this sort of selective retraction could be used to make swinging smooth with this case.
To solve this problem while allowing for Smooth swings regardless of the player's speed and distance from the attached object, I looked to the design of a device I use every day: a seat belt. In the case of rapid deceleration such as a crash, the seat belt's retractor mechanism prevents the seat belt from becoming any more slack. I realized that this sort of selective retraction could be used to make swinging smooth with this case.
Although this system is "unrealistic" in a sense, and was not explicitly explained in the game, players didn't notice anything felt unnatural, primarily because their swinging was smooth regardless of their speed, and because the visual conveyance now matched the actual state of the grapple.
Air Control
This is another case where I had to divert from more realistic physics. With no air control, swinging becomes incredibly challenging (Spider-Man is super for a reason). Experienced players can maneuver without air control, but to allow for improved movement in general, while making the game control better for less dexterous players, we added a degree of air control.
Grapple Start Speed
While swinging is fun, nobody really enjoys swinging very slowly. As a result, we wanted to make sure swinging was always fast and fluid. As a result, we added some subtle but effective boosting when a swing starts to ensure the player moves quickly. We likened this mechanic to a parent giving a kid an initial shove on a swing set.
Climbing Back Up
A persistent problem in games that feature grappling is the issue of climbing up an object when the player grapples onto something above them, but does not have any significant speed. This case is extremely frustrating for players because if they can't climb back up they start to feel helpless. In addition, this case can result in players having to turn the camera straight up, an uncomfortable orientation in first person games.
This is another case where I had to divert from more realistic physics. With no air control, swinging becomes incredibly challenging (Spider-Man is super for a reason). Experienced players can maneuver without air control, but to allow for improved movement in general, while making the game control better for less dexterous players, we added a degree of air control.
Grapple Start Speed
While swinging is fun, nobody really enjoys swinging very slowly. As a result, we wanted to make sure swinging was always fast and fluid. As a result, we added some subtle but effective boosting when a swing starts to ensure the player moves quickly. We likened this mechanic to a parent giving a kid an initial shove on a swing set.
Climbing Back Up
A persistent problem in games that feature grappling is the issue of climbing up an object when the player grapples onto something above them, but does not have any significant speed. This case is extremely frustrating for players because if they can't climb back up they start to feel helpless. In addition, this case can result in players having to turn the camera straight up, an uncomfortable orientation in first person games.
Player's natural instincts in this case is to "pendulum" back upwards (like a kid trying to get higher on a swing set), but this process can be incredibly tedious if the player does not gain speed fast enough. To solve the problem, I had to factor in cases where the players ability to affect the swing became limited under normal circumstances. The case where the player's input becomes ineffective is when the player is on the same plane as the object they are attached to
As the diagram shows, the player's movement cannot & air control cannot affect the swing further, since their movement is perpendicular to the movement allowed by the rope. This case happens because the players movement is restricted to the X-Y axis (assuming Z is up). Fortunately, this case is straightforward to detect, so I was able to add influence along the movement path
Hitting the Wall
Given that swinging movement path is "fixed", it can be hard for players to avoid objects such as walls that would kill their momentum upon contact. This problem was actually conveniently solved by the wall running and wall climbing mechanics, which sped up players significantly upon initiation. As a result, hitting the walls on a swing could be a good thing, but in any case it would not bring players to a dead halt.
Given that swinging movement path is "fixed", it can be hard for players to avoid objects such as walls that would kill their momentum upon contact. This problem was actually conveniently solved by the wall running and wall climbing mechanics, which sped up players significantly upon initiation. As a result, hitting the walls on a swing could be a good thing, but in any case it would not bring players to a dead halt.
Auto-Grappling System
Reason for Creation
In order to make the player experience as strong as possible across all platforms, I looked to improve the experience of players using gamepads as opposed to mouse & keyboard. An inherent difficulty with manual use of the Grappling Hook is that players must aim it in order to use if precisely.
On top of the base aiming requirement, players are also required to aim in ways that are not typical. In a standard First Person Shooter for example, enemy players are usually close to the same "plane" as the player, meaning that most of the aiming players perform is left/right instead of up/down. By nature of the game and the grappling hook, significant verticality is introduced, which requires significantly more up/down aiming.
Players who use mouse & keyboard tend to adapt much better, but using a gamepad presents significant difficulties. Gamepad looking in general is slower and not as precise. In a game that requires a degree of precise aiming, usually while moving, continually missing the target can result in an exceptionally frustrating experience for less experienced or dexterous players.
Implementation Observations
For this reason, I added an option for players to use "auto grapple." The auto grapple system aims for the player, using a system to score possible grapple locations based on their proximity to the player, and the max potential of their swing from that point. Given that the system was automatic, it was imperative that it work correctly, because they player has no agency to fix problems with it in this case.
Given that swinging is a very specific type of locomotion, I had an advantage in that I knew how to get a "maximum swing" from two points. I came to this conclusion after thinking about firing a projectile to maximize distance, which requires a firing angle of 45 degrees. I realized there was also a "best value" for getting a full swing, which was having two points at the same elevation as far apart as possible.
In order to make the player experience as strong as possible across all platforms, I looked to improve the experience of players using gamepads as opposed to mouse & keyboard. An inherent difficulty with manual use of the Grappling Hook is that players must aim it in order to use if precisely.
On top of the base aiming requirement, players are also required to aim in ways that are not typical. In a standard First Person Shooter for example, enemy players are usually close to the same "plane" as the player, meaning that most of the aiming players perform is left/right instead of up/down. By nature of the game and the grappling hook, significant verticality is introduced, which requires significantly more up/down aiming.
Players who use mouse & keyboard tend to adapt much better, but using a gamepad presents significant difficulties. Gamepad looking in general is slower and not as precise. In a game that requires a degree of precise aiming, usually while moving, continually missing the target can result in an exceptionally frustrating experience for less experienced or dexterous players.
Implementation Observations
For this reason, I added an option for players to use "auto grapple." The auto grapple system aims for the player, using a system to score possible grapple locations based on their proximity to the player, and the max potential of their swing from that point. Given that the system was automatic, it was imperative that it work correctly, because they player has no agency to fix problems with it in this case.
Given that swinging is a very specific type of locomotion, I had an advantage in that I knew how to get a "maximum swing" from two points. I came to this conclusion after thinking about firing a projectile to maximize distance, which requires a firing angle of 45 degrees. I realized there was also a "best value" for getting a full swing, which was having two points at the same elevation as far apart as possible.
The maximum swing case
Another factor that helped me narrow my search for good grapple points was the simple fact that players almost always look where they want to be going in first person games. After observing this behavior in players, then I improved the scoring system by adding a score factor calculated using dot products to see how directly the player was looking at the object in question. The best grapple location was determined by picking what point scored highest.
Players tend to want to grapple where they are looking
While this system worked well initially for smaller structures, a problem arose when we began using large structures. With the smaller structures, I had been taking them into consideration as a whole and shooting towards the center of their collision. With very large objects that would not be valid. Given the above vision preference, I decided to solve the problem by casting a small "net" of capsule traces in front of the player. Any points that were hit by the net were added to the list of grapple locations for consideration and scored.
The "net" (green) has added two new points for consideration from the large structure
Scoring was adjusted to tune the system further based on the player's state. For example, if the player was standing on the ground, grapple points scored better as they were higher up compared to the player to help the player get off the ground in that first swing.
Marcus AI Scripting
After looking at the design requirements for the companion character, it was determined that he would not need a full pathfinding system, as he was used as a tutorial example for the player to follow and learn from by example. What I needed to implement was something that was cost effective and straightforward for design to use, while still granting the AI all the abilities that the player can use. This was key because the AI was the player's teacher, so the physics for the AI had to match the player's.
First, I constructed the AI to derive from the same base class that the Player does, in order to grant both of them the exact same abilities. The way I build the abilities was based on the state of the player's input. I decided that I could expose scripting nodes to allow design to simulate what the AI's "controller input" was, so that the AI would play the level as a player would.
For swinging, which was a more complex action, I made a scripting node in which the designer could specify what actor to fire the grapple at, and what actor to try and move towards (usually a note or otherwise invisible actor). Since we had given players significant air control while swinging, the air control also made the AI much more capable when swinging to target locations, regardless of turns or direction changes.
First, I constructed the AI to derive from the same base class that the Player does, in order to grant both of them the exact same abilities. The way I build the abilities was based on the state of the player's input. I decided that I could expose scripting nodes to allow design to simulate what the AI's "controller input" was, so that the AI would play the level as a player would.
For swinging, which was a more complex action, I made a scripting node in which the designer could specify what actor to fire the grapple at, and what actor to try and move towards (usually a note or otherwise invisible actor). Since we had given players significant air control while swinging, the air control also made the AI much more capable when swinging to target locations, regardless of turns or direction changes.
An example of the custom AI swing nodes in the Level Blueprint
Ultimately the system worked well, but it wasn't without its drawbacks. From the designer perspective, the system could be tedious if a lot of small adjustments had to be made to the AI's movement/position to complete a maneuver. The most persistent issue was having to deal with "chaos" in the system. For static environments, the AI moved fine, but issues arose when moving platforms were added to the equation. Since the AI would have to wait for the player at several points, the position of moving platforms could be highly varied, which could affect how the wire pulls the AI when grappled. This variance caused a domino effect that could cause the AI to fail jumps and wall climbs.
To solve the issue, we had to try and make sure that the AI was at "known" points along his path where we knew he could reach his target. Doing so involved controlling his swing velocity by having the AI "input" slightly backwards to slow down, and utilizing double jumps to course correct. Fortunately this issue was very limited due to the design of the levels, and we were able to get each difficult case working correctly. Had there been more sections with significant movement that the AI had to traverse, then I would have needed a more elaborate solution, or I would have potentially needed to introduce more "cheating" in the AI physics.
The end result was that the AI performed its job well, to the point where players found a lot of enjoyment in racing him.
To solve the issue, we had to try and make sure that the AI was at "known" points along his path where we knew he could reach his target. Doing so involved controlling his swing velocity by having the AI "input" slightly backwards to slow down, and utilizing double jumps to course correct. Fortunately this issue was very limited due to the design of the levels, and we were able to get each difficult case working correctly. Had there been more sections with significant movement that the AI had to traverse, then I would have needed a more elaborate solution, or I would have potentially needed to introduce more "cheating" in the AI physics.
The end result was that the AI performed its job well, to the point where players found a lot of enjoyment in racing him.
Networked Co-OP
Although co-op was not slated to be added at the beginning of the project, it was something that I wanted to try given the opportunity. Many of my favorite game experiences are from playing games with my friends, even if the game was not built explicitly for co-op (such as players playing clones of the main character). I wanted to be able to play the game with my friends, so when the opportunity arose to add network play, I jumped at it.
The big immediate downside for this feature was the fact that I had to refactor existing code. Much of the player physics had been completed already, so I had to make sure the correct values and states were being replicated across the network.
The end result was networked co-op play, which was also useful for recording video and some debugging cases.
The big immediate downside for this feature was the fact that I had to refactor existing code. Much of the player physics had been completed already, so I had to make sure the correct values and states were being replicated across the network.
The end result was networked co-op play, which was also useful for recording video and some debugging cases.
What Went Well
Team Dynamics: Given that we had all worked well together before, our team cohesion was even stronger this time around. It cannot be stressed how much this helped the project overall. Things did not go perfectly, but because of our solid team dynamics, we were able to overcome obstacles and fix problems with little stress or panic.
Problem Solving: In this project, the team took an attitude that problems would happen, and that we should work to improve ourselves and solve them in the most effective way possible. The result was that when problems did come up, we were able to solve them, improve, and swiftly recover with little stress, even when significant changes had to be made.
Early Fun Factor: We knew from the early prototypes that the game would be fun, so we were able to allocate more time to iterating on the mechanics.
Focus on Removing Friction: From day 1 we wanted to be sure that the game played impeccably so that it would be fun to play for players of a wide range of dexterity without chopping down complexity. This principle helped guide several design decisions and ultimately shaped the product into a much more smooth experience
Problem Solving: In this project, the team took an attitude that problems would happen, and that we should work to improve ourselves and solve them in the most effective way possible. The result was that when problems did come up, we were able to solve them, improve, and swiftly recover with little stress, even when significant changes had to be made.
Early Fun Factor: We knew from the early prototypes that the game would be fun, so we were able to allocate more time to iterating on the mechanics.
Focus on Removing Friction: From day 1 we wanted to be sure that the game played impeccably so that it would be fun to play for players of a wide range of dexterity without chopping down complexity. This principle helped guide several design decisions and ultimately shaped the product into a much more smooth experience
What Went Wrong
Prepropduction Time Allocation: Much of our preproduction was focused on world building. While this was super fun and helped us tremendously with certain aspects of the game's vision, more time should have been devoted for deep diving gameplay. The result of not doing so was having to answer questions later down the line, causing rework. In a perfect world we would have had more preproduction time for both, but in this case time needed to be allocated more effectively.
Initially Not Saying What Needed to be Said: The whole team is on very good terms, but initially this caused problems in the fact that we were too hesitant to "step on each others toes," which resulted in some things not being said when they needed to. Fortunately this issue was fixed promptly, but it still resulted in some wasted work at the beginning.
Changing Game Components: Early in development, core components of the game changed as the design was formed into the final version. As a result, I ended up losing time, having implemented features that significantly lost prominence in the game.
Initially Not Saying What Needed to be Said: The whole team is on very good terms, but initially this caused problems in the fact that we were too hesitant to "step on each others toes," which resulted in some things not being said when they needed to. Fortunately this issue was fixed promptly, but it still resulted in some wasted work at the beginning.
Changing Game Components: Early in development, core components of the game changed as the design was formed into the final version. As a result, I ended up losing time, having implemented features that significantly lost prominence in the game.
What I Learned
Gameplay in Preproduction: Preproduction concerning gameplay should be more than just "the character can do X." We should be especially concerned with the player experience when he or she does "X." Dive as deep as you can and iron out as many details up front as possible, so questions don't have to be answered at a later time.
Determine your Game Complexity Early: From the start, have the best idea possible of how accessible, complex, or difficult you want your game to be. It will help you decide what to do when critical design questions come up.
Determine your Game Complexity Early: From the start, have the best idea possible of how accessible, complex, or difficult you want your game to be. It will help you decide what to do when critical design questions come up.