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.