Devlog 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 building multiple prototypes then choosing whichever game speaks to you strongest. This is too touchy-feely 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 desire a plan. 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.

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 below I will walk through how I applied them to several prototypes, including what eventually became my current project , Riposte! (obligatory plug).

Evaluation Criteria

These are the 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 the 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 its 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 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 of 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 struck through 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.

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.

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.

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).

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!

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 what I specifically did.