Categories
Uncategorized

Devlog 2 – Using Machine Learning to Create AI Opponents

My first two posts on getting started and pivoting came from a product management perspective; to keep things lively, I’m writing this third case-study on how I utilized machine learning (ML) to create AI opponents for my game. But before I jump right in, I should briefly discuss why I chose to go down the ML route as well as explain the mechanics of Riposte!

Why ML?

The biggest reason why I went with ML instead of hand-crafting AI players was that I tried the latter and I could not make them fun.  Very early on in development I made several iterations of AI opponents using finite state machines.  I was unable to get them into an acceptable middle ground- they were obnoxiously good in terms of control and accuracy, while at the same time boringly simple at strategy and tactics.  I estimated it would take me over a month of full-time effort to get one into working shape. So when I pivoted the game design away from a single-player/co-op campaign to a party-fighting-game I put AI opponents on the back burner.

Nearly a year later I decided on a whim to give AI players another try.  Partly to give an otherwise fully multiplayer game some hint of single-player content.  And partly because machine learning is just plain cool.  It also helped that I had built the game in Unity and could use their ML-Agents toolkit.

(T-800 also uses Tensorflow)

How Riposte! Works

For context I should probably give a brief description of the control system in Riposte!  It’s a controller based fighting game where the player moves the weapons instead of the characters.  The weapons all fly around, and the characters follow and retreat automatically depending on the distance to their weapons.  

The weapons are controlled via a single analog stick, which directly translates them and indirectly rotates them (the weapons will rotate toward the inputted analog stick degree).  There are two available actions, set to buttons.  One locks the rotation so that you can choose to only translate, the other performs a special ability unique to the weapon.  For the initial AI opponents I trained them without the use of special abilities.

(each sword is controlled by a different player; or in this case by me with great difficulty)

The goal of the match is to stab the other character and to not get stabbed yourself.  The swords are segmented into multiple sections & colliders so that different types of collisions create different levels of knockback deflection and rotation.  Hitting another player’s hand creates the largest amount of deflection and is a primary tactic.

The Goal

Although the core of the main game is a 2v2 fighting system, my goal for the AI agents was to create a practice 1v1 gauntlet mode, a la Bushido Blade’s 100 opponent ‘Slash Mode.’  So I didn’t want an extremely good AI opponent.  I wanted several different profiles of differing degrees and styles, so that I could pit the player with a single life against back-to-back escalating enemies.

Setting up for ML-Agents

I won’t get into the details of the installation process, as the installation instructions already cover that fully, but it was relatively straightforward.  Before I even thought about how to set up my own training environment, I imported and ran through several of their provided examples.  I strongly recommend reading the docs and doing the same.

The first major hurdle was building a training environment in my game.  As a silly party-game, Riposte! has a ton of superfluous fanfare that I didn’t want slowing down training: pauses in-between rounds, zooming & panning in on hits, dumb banter at the start of match, trumpets and confetti at the end, etc.  Additionally, the matches all have an imposed structure: best of 3 rounds, with up to 3 points per round (depending on armor), and a match timer which I had to remove. 

Once all that juiciness was gone and the match structure lightened so that it would instantly reset, I moved on to wiring up the agents.

(Boring but fast)

Wiring a sword to be controlled by an AI Agent

For my use-case, it was super simple to give the AI brain control over the sword.  I modified my existing sword control script to have an “isAIControlled” toggle, and if set, then to use a small array instead of control input.

Next I made my own Agent and made it pass its vectorAction array inside its AgentAction() method to the weapon control script.

 public class AIGymSwordScript : Agent
 {
     … Other stuff…

     public override void AgentAction(float[] vectorAction)
     {
             baseWeaponScript.SetAIInput(vectorAction[0], vectorAction[1], vectorAction[2]);
     }
 }

The AI brain only has 3 continuous outputs which correspond to the x- and y-axes of the joystick, and whether the rotation-lock button is held.  These get clamped to -1 to 1 in the weapon script.

Getting information to the AI Agent

The next step is deciding what information I think the network needs to make decisions.  In my case it needed to know about: its own position and rotation, the enemy weapon position and rotation, and the position of both characters.  Although in theory the network can learn to infer other information about the weapons (e.g. the position of the hand, where the tip of the sword is, etc.) I decided to help it out by directly including some of those.

 public override void CollectObservations()
 {
         AddVectorObs(this.transform.position / 10f);
        AddVectorObs(tipTransform.position / 10f);
        AddVectorObs(handTransform.position / 10f);
        AddVectorObs(myCharacterObj.transform.position / 10f);
        AddVectorObs(enemyCharacterObj.transform.position / 10f);
        AddVectorObs(enemySwordObj.transform.position / 10f);
        AddVectorObs(enemyTipTransform.position / 10f);
        AddVectorObs(enemyHandTransform.position / 10f);
        AddVectorObs(this.transform.rotation.eulerAngles.z / 360f);
        AddVectorObs(enemySwordObj.transform.rotation.eulerAngles.z / 360f);
 }

In the training environment I set those various transforms and gameobjects in the inspector.  Later in using the AI agent dynamically in the real game they are set by the script managing the match.

Additional ML-Agent pieces

The final step is adding BehaviorParameters (with the action and observation vectors set appropriately), and the DecisionRequestor:

(26 is the total number of elements from all observations. 8 Vector3 + 2 floats)
(Decision period I set based on feel- too low and the swords would act twitchy and unnatural, too high and they would be laggy and slow to react)

Rewards
Once the environment is working and the agent is capable of moving the sword it was time to define the reward criteria.  For the agent to learn it needed feedback on whether it was succeeding or failing.  As a general rule, you should start as simply as possibly and only add more complex rewards as you iterate if you need to encourage specific behavior it is otherwise not learning.

I used three types of rewards in training the sword AI agents: win/loss rewards when a character is hit; smaller rewards on weapon clashes dependent on the type (e.g. strong vs weak); and very small rewards per timestep to encourage movement or stalling (depending on what behavior I was going for).

In the first setup I only used the most basic win/loss rewards, through methods that get called by the match manager.

 public virtual void DoHit(Tags.CharacterTag characterTag)
 {
         //Debug.Log("done hit");
        SetReward(1.0f);
         Done();
 }

 public virtual void GotHit()
 {
         //Debug.Log("done got hit");
         SetReward(-1.0f);
         Done();
 }

Later I moved on to other types of rewards which attempt to encourage good weapon clashes.  I had to keep these very small otherwise they would overpower the main objective.  In one case I accidentally trained two swords to trade off attacking each other’s hands, completely ignoring hitting the characters, to maximize their reward per match. 

 public virtual void DoClash(Tags.WeaponTag weaponHitBoxType, Tags.WeaponTag enemyHitBoxType)
 {
         switch (enemyHitBoxType)
         {
             case Tags.WeaponTag.Gauntlet:
                 SetReward(0.1f);
                 break;
             case Tags.WeaponTag.Hilt:
                 SetReward(0.1f);
                 break;
             case Tags.WeaponTag.Weak:
                 SetReward(0.1f);
                 break;
         }

         switch (weaponHitBoxType)
         {
             case Tags.WeaponTag.Gauntlet:
                 SetReward(-0.1f);
                 break;
             case Tags.WeaponTag.Hilt:
                 SetReward(-0.1f);
                 break;
             case Tags.WeaponTag.Strong:
                 SetReward(0.1f);
                 break;
             case Tags.WeaponTag.Guard:
                 SetReward(0.1f);
                 break;
         }
 }

Another time I set the positive and negative reward too high for a hand hit and one sword learned to bide its time and only attack the hand while the other tried to hide in the corner.

(Poor guy is scared!)

Hyperparameters

Hyperparameters, hyperparameters, hyperparameters!  These are simultaneously the most important and most confusing part to new users.  There are quite a few of them and they interact to determine how learning occurs. 

Repeating my earlier sentiment, start small.  I began with a network size of 128 nodes x 2 layers, and iteratively increased it until the swords moved smoothly and learned actual tactics.  I ended up testing networks up to 1028 x 4, but ultimately settled on 512 x 3.

Stability

In the description of a lot of the hyperparameters it says that they affect and often trade off between stability and rate of learning.  Personally I am impatient and greedy so I try to ratchet up the learning rate, usually to the detriment of stability.  What this means in practice is that the agent can end up locking in on some weird, local optimum and never recover.

(This was disappointing)
(At some point during self-play training the network got trapped and they stopped engaging, see gif above)

Training within Unity

While it is much faster and more efficient to train with a standalone executable, you should first confirm that everything works and that the agent is actually learning.  To do this you can run the ml-agents command without an env= and it will wait to connect to the Unity editor, where you can then hit play.  I still make this mistake when I am in a hurry, and it has wasted more than a little time, because it is difficult to know early on if something isn’t working while training externally.

 mlagents-learn ...config\trainer_config.yaml --run-id=SwordVSShield021 --train 

Adding Initial Randomness

As a fighting game it was important that each match start out from the same initial, symmetric conditions.  However, for training purposes I added small random positional and rotational offsets at reset in order to get the swords exposure to a greater variety of situations and have more robust training.

Multiple Matches within a Training Gym

Once you’ve confirmed that everything is working as intended with a single match you can add multiple matches to speed up training.  This took a little extra re-jiggering to get my game to function, as originally the setup made some assumptions on the default position of characters and swords.

(Training a shield to defend)

Training with Multiple Standalone Environments

Next up we build the gym scene into an exe and then we can train at maximum efficiency!

 mlagents-learn `
     ...\config\trainer_config.yaml `
     --env=...\Builds\training\SwordVSShield2\Riposte.exe `
     --num-envs=8 `
     --run-id=SwordVSShield022 `
     --train `
     --no-graphics

Keep Records

As you train different sets of rewards, observations, actions, and hyperparameters it can be difficult to determine which is working well.  I recommend recording and commenting on the outcome, either in a txt file, spreadsheet or elsewhere (I just put notes in the config yaml).

 ## 021
 # Only +/- 1 on hit.
 # 8 environments, 16 matches per env
 ## Attacks okay, makes very little effort for defense.
 SwordDumbAttackerBrain:
     trainer: ppo
     max_steps: 1.0e8
     learning_rate_schedule: linear
     batch_size: 8192
     buffer_size: 131072
     num_layers: 3
     hidden_units: 512
     time_horizon: 2000
     summary_freq: 5000
     normalize: true
     beta: 5.0e-3
     epsilon: 0.2
     lambd: 0.95
     num_epoch: 4
     reward_signals:
         extrinsic:
             strength: 1.0
             gamma: 0.99

Training using Self-Play

Unlike the above gif which is training a sword against a shield, ML-Agents has an implementation of a really cool self-play algorithm, where the agents are scored with an ELO and play against ever improving versions of themselves.  It does take significantly longer in terms of steps than the ad-hoc adversarial training I was previously doing, but resulted in the best general AI opponents I was able to make.

The setup is largely the same.  The biggest change was going back to the simplest possible rewards and remembering to set the team_id for the swords correctly.  After iterating across multiple self-play setups, I settled on training with +/- 1 reward for winning/losing and small additional rewards/penalties for hand hits.

 ## 180
 # 16 matches, 8 env
 # +/- 0.25 on hand hits
 # -0.001 per tick if center out of band, -0.005 per tick if tip off screen
 # removed decreasing hand hit reward/penalty.
 ## Not too bad! Could be smarter.
 SwordGeneralBrain:
      trainer: ppo
      max_steps: 2.0e8
      learning_rate_schedule: constant
      learning_rate: 8e-4
      batch_size: 8192
      buffer_size: 131072
      num_layers: 3
      hidden_units: 512
      time_horizon: 2000
      summary_freq: 5000
      normalize: true
      beta: 5.0e-3
      epsilon: 0.2
      lambd: 0.95
      num_epoch: 4
      self_play:
          window: 15
          play_against_current_self_ratio: 0.45
          save_steps: 60000
          swap_steps: 30000
      reward_signals:
          extrinsic:
              strength: 1.0
              gamma: 0.99

Overall Post-Mortem

Moderately successful!  It took more work than expected to make my game fit for ML-agents training.  Not a stupendous amount, but it wasn’t trivial.  If I had planned on doing this from the start and had less coupling it would have been smoother.

Self-play produced the best overall agents- I can still win 9/10 times if I’m trying, but they put up a good fight sometimes.  Even within a self-play paradigm I had to give additional rewards on top of the +/-1 for winning in order to better encourage certain tactics I knew to be optimal. 

The top performing agent along with a couple dumber but tactically different agents were enough to make a satisfactory gauntlet mode experience.  The gauntlet format combined with some extra help for the bots (they get armor as the enemies progress, etc.) really brings it together.

(2 of the better agents actually dueling!)

TL;DR Take-aways

  • Read the docs and do the examples!  
  • Test if rewards are functioning and agents can actually act by training within Unity first.  
  • Slow and steady is better, start with a smaller learning rate and num_epochs, etc.
  • Start with simpler rewards before adding complexity.
  • Start with a smaller network first, then add more nodes & layers if necessary.
  • When training multiple matches & environments you need to increase your buffer and batch size to remain stable.
  • Randomizing initial conditions helps agents learn more robustly.
  • Keep any additional non-primary goal rewards small.
  • Be careful with negative rewards, they can easily lead to only learning to avoid the penalty.
  • Self-play works very well, but can take longer.
  • Record notes on the setup: rewards, hyperparameters, etc. to help you iterate.
Categories
Uncategorized

Devlog 1 – Pivoting for Indie Game Development, A Case Study

***Disclaimer: this post is NOT about quaternions***

In my first post, Devlog 0 – How I Got Started, I outlined the process I used to choose my current project.  This post is a continuation on the theme of applying Product Management ideas to indie game development.  Specifically, the Pivot. As before, I will discuss what it means to pivot and then as a case-study go through how I have pivoted.

There are plenty of resources available to indie devs about coding, design, architecture, even project management, but very little information on the role of a product manager.  If you haven’t worked for a larger software company you might not be familiar with the term, but as a solo or indie developer you’ve worn that hat (possibly unknowingly).  

The PM idea of the Pivot has a special incarnation in the game development world.  It is not as wildly drastic as the infamous silicon valley pivot—  I won’t suggest you throw out your game and make a smart-toaster.  I also want to distinguish a Pivot from the familiar gamedev concepts of iteration, refinement, and polish.  The Pivot falls somewhere between a massive paradigm shift and an incremental tweak. It is a decision to change the core of a game while staying true to the high-level experience.  Maintain the vision, change the delivery.

I ranted briefly in the previous post about the value of an idea, and here again I want to stress that the strength of a good idea is the overarching orientation it provides.  An idea is a lighthouse, providing a clear experiential goal while allowing plenty of room for pivoting. Without some even amorphous goal you have nothing to pivot towards. Conversely, too specific, too detailed plans don’t allow pivoting without significant discomfort.

Why Pivot?

With my state mandated diatribe out of the way let’s dig into the details of pivoting.  First and foremost, why pivot? This following list isn’t exhaustive, but should get across the broad reasons:

  • You accidentally built something you hadn’t intended, which turns out to be more interesting than what was planned.
  • The new mechanic wasn’t apparent until the game was nearby in design space.
  • The original design just isn’t fun, but there wasn’t a way to know until prototyped.
  • Someone else did it better first.
  • The game as a product wouldn’t be financially viable even if it were well made.
  • You’ve run into a Cursed Problem.
  • Feedback from playtesting is telling you that you’re solving the wrong problem.
  • You have no path forward in the design; don’t know what to do next.
  • There is some insurmountable technical obstacle.

Downside of Pivoting

There is of course a cost to pivoting, which would be weighed against the need.  Just like a physical pivot, changing the direction in the design means some loss of momentum (unless you are pivoting because you’ve already hit a wall).  Previous work might have to be thrown out. Timelines may have to shift. All of these can be pretty painful.

Degree of Pivot

The pivot itself can be classified into three broad buckets:

  • Fundamental.  A change in genre; solving for a very different game experience.
  • Metamorphic.  Staying in the genre; a change in approach to the original goal.
  • Situational.  Avoiding a specific design or technical issue; sidestepping instead of solving a problem.

Pivots in the Development of Riposte!

It is no surprise that the game I will soon launch looks nothing like the original prototype.  

Top: original prototype.  Bottom: the game now.

Some of this is from the obvious incremental changes and polish, but many of the sweeping differences are from pivots.  I will go through each of the pivots I had to do in chronological order. It’s worth noting that the degree of the pivots generally decreases with time, which is the ideal scenario (huge late changes are difficult and demoralizing).

1. QWOP -> Directly Controlled Weapons (Fundamental Pivot)

The original prototype (top pic) I made to entertain myself on a long plane flight.  The controls were intentionally terrible. One joystick controlled the rotation of the shoulder, the second joystick rotated the elbow joint, and the shoulder buttons moved the legs.  It was rough.

As part of the process I described in my first devlog post, I remade the prototype but changed the controls so that one joystick controlled the rotation of the weapon, and the second stick directly moved (translated).  It felt so much more responsive and FUN to play, that I immediately decided to change the genre from a wacky, uncontrollable physics game, to a more competitive fighting game. As part of the change I removed the arms so that the disembodied weapons would just fly around (I don’t consider this a pivot, just solving a specific implementation problem).

My art also became slightly less terrible. Slightly.

2. 1v1 -> 2v2 (Fundamental Pivot) 

The next pivot I made was to change from a 1v1 fighting game to a 2v2 experience.  The impetus was the idea that since I already had a sword I should add a board. This made the duel significantly more interesting.  Before it was just a relatively shallow positional contest- whoever outmaneuvered got the hit. Now it was a back-and-forth match, where players could trade initiative, go on offense or defense.  It felt like much more of a *game*.

3. Pixel Art -> Medieval Art (Metamorphic Pivot)

At about the same time as #2, I also changed the art style to something more realistic, but medieval inspired.  The above is still placeholder art I cobbled together from old public domain medieval and renaissance sources. I included this in the list of pivots even though it could be considered just window dressing.  The new style had a slightly more serious feeling and informed the design moving forward.

4. Double Stick Controls -> Single Stick Controls (Metamorphic Pivot)

[I don’t have a good picture to illustrate this]

On a whim I changed the controls to see what it would feel like to control both the translation and rotation of the weapon with a single joystick.  It turned out to be much nicer. Technically you had less control, but it was so much simpler and more intuitive that players instantly performed better.  To put back in a bit of depth and raise the skill ceiling, I added the ability to lock-in the rotation by holding a button.

5. Addition of Special Abilities (Metamorphic Pivot)

This was a fast follow-up from #4.  With the simplified controls, positioning became too trivial a problem for players to remain engaged.  To make it more dynamic I gave each of the offensive and defensive weapons a unique ability on a cooldown.

6. A Fighting Game with a Co-op Campaign -> A Party-Fighting Game with Minigames

(Foundational Pivot)

I really liked the core gameplay I had built, but my original plan of fighting game with a full co-op campaign would require way too much art and way too much development time.  This was a very uncomfortable pivot for me. I was and still am a big fan of the initial idea, and made the decision around 6 months into development. I didn’t have to throw out much work, fortunately.  

7. Name Change: “Fully Simulated Fencing” -> “Riposte!” (Situational Pivot)

The name “Fully Simulated Fencing” was what I came up with when I made the very first prototype.  I still think it’s a good joke, but it no longer captured the spirit of the game. I am personally terrible at naming things.  I take forever to just name a new character in an RPG, and I agonized for the better part of a week over this. In the end I asked for name suggestions from friends and someone more clever than myself suggested “Riposte!” (with the exclamation point), which stuck. 

8. Substantially Slowed Down the Gameplay (Metamorphic Pivot)

[Again, no picutre. I guess I could make a gif….]

This change came fairly late, nearly 8 months into development.  Prior to this, all of the weapons moved relatively quickly. The duels were chaotic, and the balance tended to favor certain weapons because of it.  Slowing down the whole game across the board (by around 50%) changed the matches from high scoring battles to much more deliberate, tense duels. It was like going from basketball to soccer.  This created a *ton* of extra work, rebalancing the abilities, wholly changing others, rethinking how matches are scored, changing the flow of the party-mode, etc.

9. Negative Points in Party-mode -> Positive Points (Situational Pivot)

I fought this change for probably too long.  Players had complained about the negative scoring since almost the first playtest.  My idea was to have negative points so as to easily accommodate drinking games. I tried different UI fixes and whatnot to make the negative points more clear, but it never stopped being confusing so I redid the entire meta-game scoring system.

10. No ties (Situational Pivot)

As a consequence of #8, the number of ties or draws in which no team definitively won went way up.  I tried for a while to make the meta-game work with ties, with no success. It was screwing up the tournament brackets and watering down the points in the party-mode.  With no elegant non-pivot solution, I ended up leveraging one of the minigames as a mandatory tie-breaker. The minigame duel (“Shivlary”, get it!) is structured to make draws nearly impossible (there’s no armor or defensive weapons), and is a nice counterbalance to the tension of the regular matches.

The Takeaway

I’m still a little ways out from launch (but you can wishlist :D), so I don’t anticipate any more pivots.  In the event I do have to substantially alter the design I will attempt to do so thoughtfully and intentionally. If you’ve made it this far then hopefully you’ve either gained a new tool or at least given a name and structure to a concept you’ve been putting into practice the whole time. 

Categories
Uncategorized

Dev Log 0 – How I Got Started, A Case Study

Dev Log 0 – How I Got Started, A Case Study

Seeing the question “How do I get started, what should I make?” pop-up again, as it does with regularity, inspired me to finally get around to writing about what I did. There are already several good articles and presentations about how to decide what to make, but I felt that all of them stayed at too high a level. This post is my attempt to breakdown the different criteria into their nitty gritty details and explain how I applied them to my personal, real-world example.

A quick survey gives us a spectrum of approaches, starting with the theory-free method of multiple prototypes and choosing whichever game speaks to you strongest. This is too touchy feeling for me. I needed a decision making scheme that at least pretended to have rigor.

At the polar opposite is the strategy of choosing your game based primarily on market analysis. If dime-a-dozen mobile games seem soulless, it’s because they were building golems from the start. I combined the two approaches. I want to make the game I want to make.

However I also needed a plan for a couple of reasons. Regardless of success, a plan will increase and enable the learning that comes after. It will even form a skeleton of sorts for the post-mortem. Secondly, having had some strategy gives a cold comfort by letting me say that I at least tried.

Somewhere between the two approaches lies the triple Venn diagram of “a game I can make,” “a game I want to play”, and “a game people will buy.” Basically Ikigai for gamedevs. These ideas are still too high level to be directly applicable, so I’ve used them as grouping categories for more granular and explicit decision criteria. A friend with an MBA explained that I was doing my own hacky SWOT analysis. I told them don’t talk to me or my son ever again. After laying out the criteria I will go through how I applied them to several prototypes, including what eventually became my current project, Riposte! (coming soon on Steam).

Evaluation Criteria

These are various criteria I thought about when comparing the prototypes and ideas for games.  Obviously my list isn’t perfect, or complete, or would be the same for another developer or team.  That’s not the point. The goal is to introduce just a little rigor into the process, and hopefully increase the chance of success (even a little!).

A Game I Can Make

Budget. What is the total asset count (assuming I can’t make them myself, which I definitely cannot), and associated cost? This is the most pragmatic question: Can you afford to make this game?

Timeframe. Some developers might have the luxury of a never ending development cycle. I am not one of them. Scoping and estimating issues aside, if you want to finish you need to plan to finish and choose a project you believe you can accomplish in a defined timeframe. Additionally, Finishing Is A Skill. Seeing a professional gamedev project through to completion was a primary goal for me (and should be for all aspirants). This is so important that I almost made category header above read “A game I can make (in a reasonable time frame).”

Technical Expertise. This is fairly self-explanatory. Are you capable of building the technologies necessary for the game? Learning is part of development. There will be some things you’ve never done before, but scoping your project in the ballpark of your abilities will keep your timeline intact and save you from at least some of the inevitable head-bashing.

Familiarity. This and the following criteria diverge from the more literal ones above to something more like “A game I can make well.” I don’t think many will disagree that it would be unwise to attempt development in a completely unfamiliar space. For game development this has two aspects. Familiarity with the genre from the players perspective, and also from the creators. Do you know the tropes, common mechanics, and importantly, the player’s *feelings* evoked by the experience? Do you know the appropriate design patterns and architecture, the common pitfalls and implementation hacks? What about the game is unique in its genre? You would need at least passing familiarity to answer this question, and intimate knowledge of the niche to know if the novel mechanic or gimmick meshes well.Every wholly new gameplay mechanic and concept decreases the chance that it can be made, let alone that they will fit together cohesively to form a good game.

Flexibility. How good would the game be with it’s scope cut in half? The time and energy you are able to commit is not constant. Deadlines move. Emergencies happen. Maybe a problem you think is easy will turn out to be intractable and you’ll have to pivot.

A Game I Want to Play

Desire. When you sit down, either by yourself or with a group of friends, is this the type of game you love to play? Even better, is this the game you wish existed, that delivers some particularly underserved experience? Game development, especially as an indie or solo dev, can be grueling at times. One source of consistent motivation needs to be your desire to see your game exist.

Vision. Does the game have “it”? Does it excite the designer in you, spawning countless new ideas (not all of them necessarily good)? Can you clearly picture the intended experience? Do you really WANT to make this particular game? Here is where I separate from the too often repeated mantra that ideas are worthless.

I see this getting hurled at young (probably naive), aspiring game designers all the time. “Ideas are worthless,” “iteration is all that matters,” etcetera, etcetera. This is an unproductive strawman, or at least misses the true value of a good idea. Yes, testing and iteration are at the core of making games, but without an idea acting as a lighthouse (even implicitly) it would be aimless and unproductive. A guiding idea is the difference between a random-walk and hill climbing. Having a defined high-level vision will help in nearly every difficult decision that arises, when you have to ask “is this what the game needs.” #endregion RANT

Is it actually a game? A lot of the ideas I have fall apart upon inspection. Not because they are bad ideas but because they would make bad games. Perhaps the experience would be more powerful as a novel, or a comic, as a D&D campaign. Does this *have* to be a video game?

A Game People Will Buy

Audience. Depending on your personal goals, market research might not be necessary. If you intend on selling the game, I strongly recommend doing at least a cursory assessment of the state of the genre. It’s probably not safe to wholly trust your feelings that the game you want has enough of an audience to justify the investment of your time and hard work.

Competition. Even if you make a good game, is the competition so fierce that the genre is at saturation? It might not be impossible to make the next break away success Battle Royale game, but it would be quite a gamble to attempt. Ideally the niche is underserved, with just a handful of stale titles and a huge, slavering audience of gamers with fat wallets. Ideally.

Genre Originality. What is original about your game? Part of the decision process when people buy a new game is their desire for a new experience. Is it the art, or the story? Is it a specific new feature? Is it just a novel combination of existing mechanics? There does not need to be anything specifically new, but if there is, focus on it because it will likely be one of your hooks.

Improvement. What does your game do better? Not everything has to be new, often you can just do something better. There is plenty of room in many sub-genres for a game to sell solely on refiniments and polishing what has come before. Keep in mind that the idea “I can do better” is probably inflated.

Pricing: Is the price you need to charge feasible? Again, this only matters if want to sell it. Do the genre expectations in combination with the amount of content allow for a price point that justifies the effort?

The Process

Step 1: Ideation

Before I sat down at the keyboard to hack out small concept prototypes I spent a couple days brainstorming. Some of this process was coming up with new ideas, and some was fleshing out old ones I found in my notebook. I also dug up a few recent game jam games. To all of these I applied the above criteria, not in a particularly in-depth way, more just looking for a reason to NOT make them.

Step 2: Rapid Prototyping

I read somewhere I can’t remember (and so cannot link to) that a prototype for the core of a game should equal 10% of the total time it would take to make the game. I, being stupid, really wanted to get something Finished in a year, meaning 5 weeks for a prototype. I kept to that for the main final prototype I moved on with, but preliminarily I spent 3 weeks making 3 separate, very bare-bones rapid prototypes. I added to this 2 other prototypes I had made in the previous year (one for a jam, one for giggles), which I also fleshed out a little more for parity.

Step 3: Evaluation of Prototypes

I’ve tried to keep the evaluation of each game prototype concise, with just a sentence or two per bullet point.  The criteria I’ve highlighted in red are ones I consider negatives or potential blockers.

Spear Hunter

(That’s a bear if you can’t tell)

The idea for this game was an action RPG, set in prehistoric times, where the player would play a series of cave-persons. Instead of increasing in direct power (stats, equipment, HP, etc.) the character would gain, per enemy based on number and type of encounter, additional telegraphs and markers for weak points and openings.

  • Budget: Probably too high. Even with a low number of environments, and low numbers of enemies it all adds up quickly, and then there are the necessary animations, etc.
  • Timeframe: Uncertain. This was a big sticking point.
  • Technical expertise: Low. There wasn’t anything planned I didn’t think I couldn’t build.
  • Familiarity: Pretty good from a player’s perspective. I play a lot of action games, both 2D and 3d. Poor from a development perspective. This was the primary reason I didn’t choose this game. I have way too little experience making polished, good feeling combat.
  • Flexibility: Without some base, fixed number of enemies and locations the game would feel too empty.
  • Desire: This was the evolution of an idea I’d been kicking around for a long time. I think it would be great to play a game like this.
  • Vision: I had a pretty strong sense of what I wanted for the world and the systems, but was a little vague on the feeling of the moment-to-moment gameplay.
  • Is it actually a game: Yes, actually! The gameplay loop in the prototype was pretty neat.
  • Audience: Seemed fairly good based on a quick survey.
  • Competition: Quite a bit, unfortunately.
  • Originality: I wasn’t able to find any good examples of the type of indirect progression I had envisioned, so potentially original.
  • Improvement: Similar to my assessment of my familiarity, I don’t think I have the experience necessary to improve much on existing similar games.
  • Pricing: The price I would want to set would be in-line with the genre and scale of the game.

 

 

Even though I still really like the concept for the game, and the prototype was fun, my lack of experience in creating action games lead me to shelve this one.

Weaver

(the “woooo” is something I left on for debug purposes. I no longer know why.)

This was a prototype I had started nearly a year prior, which I fleshed out more in order to properly evaluate. The concept was a top-down spell casting action game, where the spells were obscenely powerful but laborious to cast and had to be done in real time.

  • Budget: Way to high for the amount of content (enemies, spells, environments) that would be necessary.
  • Timeframe: I estimated this would take 2-3 times as long as I wanted for my first release project.
  • Technical expertise: In order for the spells/magic to feel good they would need to look good, and I am not good enough at building effects.
  • Familiarity: I’ve played plenty of spell casting games.

 

  • Flexibility: Very inflexible. The whole point of the game was to be a sandbox for a huge catalog of spells.
  • Desire: Fairly strong. I am still in love with the idea.
  • Vision: Strong enough that I could tell the prototype wasn’t it!
  • Is it actually a game: Sadly, no. At least I couldn’t make it work. It sounded like a neat idea but the fun just never materialized.
  • Audience: Just fine.
  • Competition: Probably too much.
  • Originality: Not super original, but at least I haven’t seen this exact spell casting system done before.
  • Improvement: If it worked and was fun, it would have been a step forward.
  • Pricing: I don’t think the low price I would need to set would justify the effort.

 

 

 

 

Overall the game I wanted to make was too large, and more importantly I never really found the spark in the gameplay.

Beans

(I had forgotten about the subtitle ha!)

This was a game I made for a jam at the start of this whole endeavor. It was a cross between a visual novel and a puzzle game, where dialog is driven by a puzzle mechanic.

  • Budget: Nice and low.
  • Timeframe: The plan was for a fairly small game, so this was a pro.
  • Technical expertise: Nothing particularly challenging!
  • Familiarity: A little on the low side, as I am not a puzzle aficionado.
  • Flexibility: Not a sticking point with the scope so low to begin with.
  • Desire: Without a strong vision and solid prototype it was tough to want to go on.
  • Vision: I didn’t really know what I wanted when I started, and by the end all I knew was that it wasn’t it.
  • Is it actually a game: Nope. Not at all. Completely unfun. A friend said to me after playing, “I’m happy you made this puzzle mechanic because now we know it doesn’t work.”
  • Audience: The niche seems to have a decent base.
  • Competition: The genre isn’t dominated in the same way others are, so not too bad.
  • Originality: Original but in a bad way.
  • Improvement: In theory yes, in practice no.
  • Pricing: I think the price would have been right on target.

 

 

 

 

 

This is a great example of why RAPID prototyping is great. The novel puzzle mechanic I created was hopelessly bad. I would have had to make another, and then another and another until I got something that worked.

Synth Hack

(The picture in picture is of me tuning the monotron to find next code)

This was a proof-of-concept prototype I built. It’s a complicated lock-picking / safe-cracking game using an external musical device (I played using a Korg monotron DUO, but anything works).

 

  • Budget: Very small. Excellent.
  • Timeframe: Also small!
  • Technical expertise: Potentially a sticking point, as I had made the prototype for one specific sound source and it would need to be generalized.
  • Familiarity: While I have a surprising amount of experience manipulating audio data, this was still pretty new territory.
  • Flexibility: Difficult to measure without having a clear idea of how a larger game would be made.
  • Desire: I thought it was a really cool concept, but it never pulled on me strongly to expand on the concept.
  • Vision: I had a pretty clear idea of the experience and the prototype confirmed it, but I couldn’t see it as a full game.
  • Is it actually a game: Yes, the game was fun!
  • Audience: Most likely very small for a weird alternative control scheme game.
  • Competition: Not a lot.
  • Originality: Too niche.
  • Improvement: It’s hard to say with something genre defying.
  • Pricing: I think the price point would have been reasonable for the scope of the full game.

 

 

 

 

 

The two biggest sticking points were that I didn’t know how I would expand the demo concept to become a larger full on game, and that the potential audience for a weird alt-control scheme was probably very small.

Fully Simulated Fencing

(It was somehow clunkier than it looks, which is a feat)

This was the original working title that would later become Riposte!, the game I am currently building. I made the prototype on a plane flight based on a pretty stupid idea. The original was a QWOP-esque sword fighting game. It was brutally hard to control in the first prototype (on purpose), but when I made a second version on a whim it turned out to be pretty great!

  • Budget: Delightfully small.
  • Timeframe: The scope started out pretty small, and eventually got even smaller.
  • Technical expertise: I had no experience making multiplayer games.
  • Familiarity: When my friends and I all find the time to sit down together in person all we do is play these types of games.
  • Flexibility: Very flexible. As a party fighting game I could cut the scope 90% and still have a small but satisfying game.
  • Desire: I love playing these types of games and making my own was a big motivator.
  • Vision: I’m counting this as a negative because my original vision was hazy and took several iterations and pivots to get to a good place.
  • Is it actually a game: The first prototype, not so much. The second version was where I knew I had something.
  • Audience: Respectable.
  • Competition: There aren’t a ton, and most aren’t new.
  • Originality: Strong! I have a lot of unique hooks!
  • Improvement: Also pretty good. I knew what issues I had with similar games and at least some idea of how to improve.
  • Pricing: I was confident I could keep the timeframe small enough that a modest price would be okay.

 

 

 

 

 

This is the game I ended up making. The main points in favor were the small scope and flexibility, which turned out to be crucial when it came time to pivot and scale back. In my next post I will dig into the concept of pivoting and how I did it.