How Prototyping Saves My Sanity

bugatti-1612389_1280I am a firm believer in “good enough” mentality. When creating something, it helps to decide what would be good enough for the purpose you have in mind. Then you intentionally aim for that target. I would say that is the crux of any “lean” approach to writing software or starting a company. You do just enough to reach your objective and no more. That way you can avoid waste. Reasonable people can agree that avoiding waste is generally a good thing.

Still, the phrase “good enough” can be an excuse to avoid difficult work. It might also be used to rationalize being stingy, holding back what would benefit others. When striving to exceed expectations, an abundance mentality is more appropriate than squeaking by with something that is “good enough.”

To be effective, the phrase “good enough” has to be followed by the question “for what?”

If your purpose is to sell something, it has to meet a need that people will pay for. If your purpose is to gain notoriety or to build a legacy so that you are remembered for generations, you are setting the bar quite high. Whatever you create had better be outstanding.

As a solo-preneur—that is, someone working alone on bootstrapping a business around game design and development—my bar for good enough has to be relatively low. I am continuously testing ideas for viability. The ideas need to be good enough to gain even a little attention and to see what might work in a grander scale. I do not count on selling much in the early stages.

In my mind, ideas evolve quickly, and before long a vision begins to crystallize. Imagine with me that I have attracted thousands of followers. People are happy to use my amazing software and pay for it without hesitation. I have grow my company to a half-dozen people, and we are busy creating ever more software people love.

Hollywood has conditioned me to suspend my disbelief, so believing in my fantasies is easy. The hard parts are ignored, risks are dismissed. Would it be prudent to go all-in based on the movie of success in my mind? No, that would be crazy, or at least rather foolish.

Others would think so, too. They might whisper behind my back. You can almost hear the critique.

  • “Is that guy nuts?”
  • “What was he thinking?”
  • “He thought this drivel would draw an audience?”

On the other hand, all I need to do to keep my sanity is prove that the idea can work. Engaging in research and development toward in the pursuit of an idea is certainly reasonable. If it works, I’ll have something to show that others can understand. If I cannot find a way, or if it does not work as well as I imagined, I can use that evidence to adjust my idea or walk away from it.

With any non-trivial project, such as putting together an online game, I like to work in stages. The first stage is intended to answer a few questions.

  1. Can my idea work?
  2. What kind of effort will it require?
    • What skills?
    • What creative elements?
  3. Will the idea be interesting enough for others?
    • To try?
    • To pay for?

This first stage is a great time to build a prototype. Our ideas can be full of magic that needs to be turned into moving parts based on physical reality. A good prototype does the trick.

An Analogy

Think about a car manufacturer who wants to develop its first electric car. Does the company sell the first car it produces? No. Does it even have an assembly line for the first car? No. Although the car company knows how to produce cars, an electric car is fundamentally different than those that burns fuel. That requires some new ideas.

A team in a research lab might start by assembling by hand a wheel, an axle, an electric motor, and a battery. Someone might write software to control the motor. Although far from being a complete car, this is a basis for learning how an electric car might work.

Once those pieces are working together, the team might add a brake, updating the wheel and controller to accommodate. The team might try cutting-edge technology as well as something more traditional. In fact, they would consider the technology choices for each component, whether to stick with what has worked, to try something ground-breaking, or to invent their own technology specifically for this new purpose.

They probably have things wired to test and measure their attempts. Do the breaks get too hot? Can they overpower a runaway motor? Can a bug in the controller software lead to a safety issue?

The point is to learn, to push the boundaries, and to prove what can work. This is the essence of prototyping. See if your ideas can work, get a sense of the effort involved, and give yourself a way out before spending too much on full development and the trappings of a production launch.

Decisions about paint colors and interior fabrics can probably wait. Adding a rocket booster is probably also out of scope, as tempting as it might be to explore.

A True Story

Back in December, I wrote and launched my first release of StoryTime, which is a game platform for writing and playing interactive, text-based adventures. The first release was good enough in about two weeks.

By now you know to ask, “Good enough for what?”

Glad you asked. My target was to launch a “reader” application for playing story-games, with one complete story loaded and ready to play. The launch was merely a matter of hosting the system where anyone with an Internet connection could try it.

I did that.

Then I needed a way to register authors, so I added a database to the back-end and hooked up an identity provider to handle sign up and authentication. That work included a feature for players to opt-in and become authors.

Once it was working, I released it.

The release was nothing fancy. Real authors would probably want to provide a lot more information about themselves, like the write-up that you find on the back of a book cover. I only wanted to show that I could save any information about the author. What I had was good enough as a proof.

Then I added the Writing Desk, where authors go to write their story-games. It’s slightly more complicated than using a word processor because you have to hook up the scenes in a certain way. However, there’s no coding involved for the author. Just type and save.

So I released that.

The Writing Desk also lacked features that would make for a carefree user experience. One problem was the way the story was organized. The layout made it possible to get to everything but not necessarily intuitive. Also, the editors lacked feedback cues, and without auto-save, it would be easy to lose work.

Still, it was good enough to show how all of the pieces of a story-game could be written and connected.

Then I added a way to publish story-games. That promotes a game into the library where anyone can find it and try it out. Although the UI had a couple of refresh issues where updates were not being displayed immediately, nothing was broken fundamentally.

So I pushed that out, too.

The publishing step involves categorizing the story-game by assigning a rating (for age-appropriateness) and one or more genre. While capturing the information was import to show how stories might be grouped and searched, new features are needed to make use of the information. That didn’t stop me from releasing.

And there it stands, a working example of a simple gaming platform. Is it good enough? Well now, that depends, as you know. Good enough for what?

If I believed the movie in my head, the fantasy that I was creating something thousands would love and pay to play, my only option at this point would be to break down and cry. StoryTime is nowhere near good enough for commercial purposes.

Luckily, I have a mindset that allows me to appreciate what I have done and use that to understand what I could do next.

What I have done is to build a prototype of the gaming system I imagined.

  • The prototype is not colorful, at least not in an artful sense. At least I used Bootstrap for styling, so it isn’t horrible. Unless you don’t like Bootstrap.
  • It is not elegant. As I mentioned, it’s pretty easy to lose work, which is about the worst thing that can happen to a writer.
  • The library is still nearly empty. It’s got the one story-game that I wrote back in December. I have been too distracted to write another. Also, droves of writers have not decided to invest irrationally in a game platform without players, an ecosystem, or an obvious payout. Go figure.
  • Mostly players don’t want to become writers. In fact, players want graphics. A text-only game is a tough sell these days.

A game designer ask if StoryTime could be used as the story line in Unity, a popular game platform. That’s a good idea. So perhaps what I have done is assemble a new mechanism that could be built into a larger system. Like figuring out a drive train based on electricity.

As a stand-alone gaming platform, StoryTime could use so many more features. What about illustrations, at least for the cover art? How about collaboration? Shouldn’t there be a review process to make sure what’s being published meets community standards?

Say authors actually used StoryTime to create alternate-universe games. How would games be sold? What’s the business model? Some companies have made this work. Others have closed their doors.

In short, the gap to realize my dream for StoryTime is huge. Finishing will involve a lot more work. It will also take more talent than I have. To see it through, I will need that six-person team. And I still don’t know if would be worth it.

Meanwhile, something else happened that would be enough to drive a normal person bonkers.

Who Moved My Technology Cheese?

The last release of StoryTime was in April. Since then, I have been busy with other concerns. As I returned to my little coding project last week (now July), I found what has become a familiar scene. The software still runs, but everything it relies on has moved. Allow me to explain.

When I started this incarnation (let’s call it the 3rd go) of StoryTime, I made some choices for the underlying software technology. First, I decided to go 100% JavaScript. StoryTime uses ReactJS and its ecosystem of modules for single-page-app support. On the back end, StoryTime offers a service with a REST API defined using Open API 3.0 (a.k.a. Swagger). The service uses Express on NodeJS 8. That connects to a PostgreSQL database where the stories and data are kept. As any React developer might guess, the app uses React Router for navigation and Redux to manage UI state. I also chose Bootstrap for styling, as I mentioned before.

Everything is written using es6+. That’s a relatively new form of JavaScript that anyone serious has been using for a while, with Babel transpiling down to something that older Web browsers can understand. Of course, it’s all built by Webpack, with as many unit tests as I could remember to write (not enough).

The whole thing is hosted on Heroku, which had just introduced pipelines. So I check my code into Git and pushed to GitHub, where Heroku notices the update, pulls it down and builds it on my staging server in the cloud. After that, I try my changes in staging, which is as close to production as you can get. In fact, when things check out, I simple move that build to production using a little button on the pipeline. Easy.

Also, I installed PaperTrail in order to see the last few days of logs. After all, I want to know when people are using the game.

Even if you don’t write software for a living, you can see that there are a lot of parts. Many of these parts are moving, too, in that they are supported by communities of active developers who keep changing things.

So I am used to having to upgrade components rather frequently. But stepping away for a bit changed my perspective. Here are a few of the shocking revelations.

  • JavaScript is losing favor to TypeScript.

TypeScript is a superset of JavaScript that introduces type safety, a much-needed measure of control, to JavaScript. Now you can ensure that an object conforms to the shape that is expected. All the flexibility of a scripting language with the safety of something that gets compiled, like C, C# or Java.

  • Redux sucks.

Redux is the “recommended” approach to managing client-side state. A Redux store is a good place to keep facts that you want to show in the UI. For instance, the fact that an edited scene needs to be saved might be recorded in a Redux store.

The truth is that the Redux approach is hard. I’m not just whining about it. It adds overhead and comes with a mental tax. I waited as long as I could before adding it into StoryTime because I knew that it would slow me down. Now every time I return to add something else to the store, I have to remember the gymnastics to make it happen.

  • Bootstrap looks horrible.

I mean it’s okay, but not really. Certainly not with my limited skill at styling. Also, I tried using reactstrap with its React-ready components for applying Bootstrap styles, but the documentation was insufficient for someone in a hurry. I had to keep looking at their code to know what was ready and how to use it. Bah.

  • Node is on to version 10.

You can still use 8, although it’s now on long-term support (LTS). Might as well start thinking about upgrading and what that will mean.

  • auth0 has a pricing model that will crush me beyond 6,000 (or so) users.

I knew this going in, but figured I would adjust if I ever got close to that level of adoption.

Any one of these gaps might not be worth a full-scale rewrite. Yet combined with the realization that I have been building a prototype and that no one has even tried to write a story-game yet (aside from my dad. Thanks, Dad!), I feel completely at ease walking away from this PROTOTYPE and starting over with a better idea.

Once again, prototyping has saved my sanity. I get to chalk it up to learning and decide what to try next.



See What You Can Do With These Game Ideas

A couple of posts ago, I promised to share one of my game ideas. This is my post to make good on that promise. Even better, let’s take a look at two ideas.

My game ideas tend to originate from either a twist on an existing game or some concept that can be made into a game. As a starting point, I think of ten ideas, anything goes. Most of them probably won’t amount to much. By coming up with ten ideas every day or once a week, eventually one of them is bound to be worth pursuing.

These are two that I think merit a closer look.


If you have made it to your 20s, you have lived long enough to be aware of pyramid schemes. How about turning that into a game?

Here’s the premise. Anyone is allowed to start a pyramid and be the boss, and players can join any of the active pyramids. The object is to convince players to join your organizations, which requires an investment of points. Those who join become recruiters who try to convince others to join.

Each player collects points based on a portion of the points collected below that player in the organization. The lower you are in the pyramid, the smaller the portion. At some point, it wouldn’t make economic sense to join, but recruiters can still do their best to persuade new joiners.

Players can participate in any number of pyramids as long as they have enough points to “invest.”

At some point, the top boss either makes the call to shut it down, say when growth starts to stall, and heads for the Bahamas. Or he or she gets caught by the authorities and goes to prison. Maybe the closest lieutenants have to pay a fine. Everyone else just loses their investment.

That’s the general sketch. Indeed, it might seem a little sketchy. Perhaps the point of the game is to demonstrate the problems with pyramid schemes, or to teach how to recognize them.

On the other hand, it might offer a way for the unscrupulous to practice without legal consequences. Also, people might also find a way to use the game as a proxy for a real-life pyramid scheme, where player points convert to money. That would be illegal (at least in the United States) or dangerous.

The game is suited for online play because it requires a lot of players the way I described it. In another form, the game could be laid out on a board and played in a way that’s similar to the Game of Life. Some of the spots allow you to form or join a pyramid, some add followers or receive regular payouts, some are where you get exposed and lose everything. If you make it to an undisclosed private island to live the life of luxury (and lonely isolation), you win.

Good idea or DOA? Alright, take it or leave. Let’s look at another.


This game is designed to give players a sense of the life of an entrepreneur. The premise is that you have this great idea for a business, and you want to launch a company and take it public.

You have to advance through levels, each of which gives you a baseline 10% chance of continuing. That’s a 90% chance of being wiped out each time you try to advance. You also have the choice to cash out once you complete the level you are on. Cashing out might cost you but probably leaves you with some rewards.

Maybe your odds are impacted by decisions you make. Choosing a narrow market, expanding in a way that builds on existing assets, getting the right professional help, and making good deals with helpful partners would all improve your odds. You can also make bad choices that lower the odds. Hmm, I can probably come up with a few of those, too.

Is this a board game where you have to go around some number of times? Is it based on decks of cards, one specific deck per stage?

I can imagine using dice to determine outcomes. Want to make a deal? A roll of 10 means it’s perfectly executed. A 5 through 9 means it goes through but is less effective than hoped. Roll a 2, 3 or 4 and the deal is off. A 1 means the deal is shady and costs you in the long run. That’s got the feel of an RPG.

Entrepreneur might be well-suited as an online multi-player game. Each player is busy trying to build his or her corporate empire. The “daily news” feed could be filled with the wins and losses of the other players, deal offers, and so on. Perhaps specializations develop: some want to build companies, others want to be venture capitalists. Maybe the bankers and lawyers are all bots with a range of programmed skills and ethics.

You get the idea, right?

Ta Da

So there you have it. Two seeds. Two kernels. Two ideas that might be developed or morphed into any number of interesting games.

If you liked those, let me know in the comments. I can share a few more someday.

If you are new to game design and want help getting started, check out Design a Game. It’s got all of my best thinking on the subject of game design. By the end of the course, you’ll be coming up with playable ideas of your own.

Finally, remember to subscribe because it shows me that you are interested.

Pictures of the Mind

Today, I ask the question, does entertainment require pictures?

The obvious answer is, “no.” People enjoy books without pictures. Music is fine without an accompanying music video. Both forms of entertainment often leave the visuals up to the imagination. Ideally, your brain fills out the experience in engaging ways.

I am obsessed with interactive fiction. To be more precise, I have spent a lot of time thinking about text-based games, a sub-category of interactive fiction.

This kind of game probably started in the margins of text books. On the upper left of the inside cover, you would find something like, “Turn to page 23.”  The bottom of page 23 would have an instruction to turn to page 16, which would take you to page 76, and finally to page 42 to read the message, “You are a dummy.” Nice payoff.

At some point, a bright lawyer, Edward Packard, during his daily commute devised the mechanic for choose-your-own-adventure stories. You are (sort of) in control of how the story unfolds, making key decisions at the ends of the chapters. Packard and another gentleman wrote a series of books that were popular when I was growing up in the 70s and 80s.

Computers are all about information and branching logic, so they are a natural tool for hosting modern “pick your path” style games. Imagine the available options auto-magically readjusting based on previous behavior, AI, and a bit of randomness.

That kind of adaptation is impossible (or at least highly impractical) in print. So most interactive fiction is played on computers. For that reason, the category expands well beyond simple text-based games. An obvious enhancement is to add graphics, first for the “cover” art, followed by chapter illustrations. Some forms allow you to create an avatar and place you in immersive scenes.

My interactive fiction platform StoryTime is still exclusively in the text-only camp. That’s more due to the limitations of my time and skills than some conscious choice. I use the system as a way to practice programming, and being a team of one only takes things so far. C’est la vie.

Some platforms choose to keep pictures out of the mix. Choice Of Games successfully sticks to text, touting the power of the imagination, rather than being spoon-fed eye candy (my tongue-in-cheek characterization).

From their website:

By using text, we can interact with the imagination in different ways from a graphics-based game. We can also allow game designers to quickly and inexpensively produce games in comparison with graphics-based games.

I agree. I also appreciate the practicality of their message. Good writing takes time for one writer and an editor. Producing a game with compelling visuals takes a lot longer and requires more skill sets, which means larger teams and a bigger budget.

While I may be biased by the limitations of my own platform, the case for text-only adventures is strong.

Another favorite of mine is TriadCity by SmartMonsters. This text-based adventure explores the idea of a game as literature. To quote from the TriadCity website,

We find that our own ability to form excellent pictures in imagination is more fulfilling. And, blind and visually impaired players are first-class citizens in TriadCity.

That quote exposes another way to extend text-based games, by having them read so that people who cannot see can enjoy them. This twist is not as obvious to those of us with working vision. Ironically, it may be the ease with which we take in supplied images that deadens our ability to have visions of our own.

Did you notice how we crossed over to the realm of sound? There’s another form of entertainment that hearkens back to the days when a “radio” was a giant novelty box that sat in your living room. Well, not your living room, but those of your ancestors. Of course, I mean theater of the mind.

This form of entertainment blossomed again with podcasting. When podcasting was new in the mid-2000s, the character John Bell came to life in Bell’s in the Batfry, with a whole cast of characters primarily voiced by Bell himself. John, a.k.a. Professor Zounds, is a talented voice actor with a sense of humor that has me guffawing in just about every episode.

Have you heard old-time radio programs? You have to think of ones like The Shadow that haven’t (to my knowledge) been portrayed on television or other visual media. Do you have a picture of what the characters look like, even though you have never seen them? This can happen over a conference call with someone you just “met” on the phone.

The same is true of Bell’s in the Batfry. The show revolves around him trying to produce a podcast with his cohorts: the inventor Arnie, the ad man Brad, the science professor Mr. Whizzr’d (who likes to torture his assistant Billy with his experiments), and the ditsy by lovable Miss Schmacklehiemer, to name just a few. It does not take long to imagine how these characters look, although each listener’s rendition is certainly different.

To bring this to a close, many forms of amusement rely on the creativity of the reader or listener to supply the visuals. So it’s okay for games to impose the same constraint on players. The best part of the game might be what the player brings to it. Don’t count on it, though. You’ll need to supply plenty of context for most people to follow.

Once you have the text-only basics worked out, you can always think of ways to introduce visuals and sounds without disrupting the intended effects.

For fun you can check out:

And remember to subscribe because I like to know that you care.


How I Come Up With Game Ideas

Have you ever thought about coming up with a new game? I do it all of the time. Today I will explain my approach. You can use what I show you to come up with your own game ideas.

The formula is simple. Start with a familiar game or concept. Either apply a twist or combine the original idea with something unrelated. To turn this into a game, answer a few questions.

  • What are players trying to achieve?
  • What happens during each turn? Are turns sequential or simultaneous?
  • How can players advance their cause and hinder their opponents?
  • What are the trade-offs to manage?
  • How do players use strategy to gain an advantage?

Answer what you can, and allow other details to emerge as the game unfolds.

Once the mechanics of the game are worked out well enough, get people to play it with you. Put together a quick prototype, and find out if it’s any fun.

If the game is not quite right, ask yourself how it might be better. Pay attention to the answers that pop into your head, especially while you are doing other things. (Creativity often happens when you’re not focused on it.) Apply those changes, and play again to see if things improve.

Iteration is the key. Repeat that cycle until playing is so much fun that players never want to stop.

Repeat: { Idea ⇒ Blend ⇒ Try ⇒ Evaluate }

That’s it. Simple, right?

To give you a better sense of this approach, let’s look at a one of the simplest games I have morphed into something new.

A Simple Example—Number Guessing

You know the guess-a-number game, right? Someone (or perhaps a computer) picks a number from 1 to 10. The player guesses a number and is told to guess higher or lower. The game ends when the player guesses correctly. The fewer the guesses it takes to win the better.

Nothing innovative there, but that’s a good starting point.

I played this often with my kids when they were small. Even for them, the game quickly became boring. So we started by expanding the range of numbers up to 50, 100, 200.  Eventually we allowed numbers as high as you could count, like 1,000. Woo.

Things get confusing in the tens and hundreds of thousands, let alone the millions. And no one really knows what comes after a gazillion, other than infinity, of course.

We also expanded down into negative numbers. My 6-year-old never quite got it that -1 is greater than -2. Regardless, we had about as much fun with guessing numbers as you can imagine.

To change things up, we tried guess-the-animal, where the player asks yes-or-no questions about the animal in mind. After hearing the answer, the player gets to guess one animal. A solo player could repeat that loop until she guesses, or there could be multiple players who take turns trying to be the first to guess correctly.

Before long, the kids started figuring out strategies to arrive quickly at the correct animal. Is it warm blooded? Does it have 4 legs? Can you ride it? You get the idea.

So once we got the hang of that, we added a twist. The thing to guess could be anything. That opens up the possibilities quite a bit. Meanwhile, we basically rediscovered the classic game 20 questions.

Now I am getting to the good part, multi-player number guessing. Everyone who is playing thinks of a number at the same time. Once they each have a number in mind, the players take turns guessing the sum of all of the numbers.

A player cannot repeat a guess that has already been made. When all of the guesses are in, the players tally the numbers that everyone was thinking. Whoever guessed closest to the sum is the winner.

You get a bonus point for being spot on.

To illustrate, let’s say you and I are playing. We each think of a number from 0 to 10. I think of 2, and you think of 8.

Since there are two players, the total range of possible sums is 0 to 20. Say that it’s your turn to go first, and you guess 12. I guess 4. The sum of our numbers (2 and 8) is 10. Your guess (12) is closer to 10 than mine (4), so you win.

Got that?

The game goes quickly, so you can play a best-of-ten series. We played without a way to record the numbers, so we exercised our memories and practiced simple mental arithmetic.

What makes this game fun? Two things.

First, the privilege of guessing first rotates. There is a challenge to going first, second, and so on. Does it even matter? Certainly, though for a two-player game either can be an advantage with the right strategy. (We never tried with more than three players.)

Second, you only need to be closer to the sum than the other players. It’s like the Price is Right when you are last and everyone before you has overbid. You win by bidding $1.

Or more like being chased by a bear in the forest. You just have to run faster than your hiking companion.

So the combination of guessing first or second along with pinning the number you are thinking to either end of the range can help secure a win.

Along with the “pinning” technique, we discovered ways to psych each other out with our banter and poker faces. Trick the other player into guessing too high, and you can sneak in with a winning guess that is one less.

On any given night, one of us would consistently outsmart the other. And the honor would flip-flop the next night. That’s a game with staying power.

My next big idea is turn this into an online game. A bunch of people would join, play a few rounds and scores would go up and down based on the results. Some of the players might be bots, especially to cover for anyone who drops out mid-game. Over time, players with the best strategies would rise to the top. Books on hacks and cheats would be published. Las Vegas would host the World Series of Multi-player Number Guessing.

All of that from a simple twist on guess-a-number. Who would have thought?

If nothing else, it will be a good programming exercise. Someday.

Stay Tuned

Next time, I will share another game idea that is still in the early stages. I will take you through a few iterations, and we will see where it goes. Then you can take it from there if you like.

You might want to subscribe to my newsletter because I need to know that you care.



Skill Atoms—Building Blocks That Make Games Fun

I have been putting together a course for beginning game designers. It’s called Design a Game, and it‘s a perfect way for anyone who wants to start making their own games to get started.

The first part of the course answers the question, “What makes a winning game?” My answer is that all great games are fun to play. That begs the question that you clicked on to read this post. Namely, what makes games fun?

In the course, I describe a set of qualities that make games great. One of those qualities is improvement. Great games allow players to get better at something, presenting rewards and unlocking further advancement when they do.

Yesterday, I found an article that describes the concept of skill chains. Imagine that every attainable skill is an atom, a self-contained building block of something a player can learn to do. That “atom” can be used to achieve higher-order skills, which in turn can be used to learn more skills.

According to the author, it’s the process of gaining skills that makes games fun. Everything else is secondary.

Here’s an example. Back in the 80s, Apple introduced Apple Panic. The game featured a simple 2D world with crazy, man-eating apples running around, and you with a shovel. You could dig holes in the floor, and if an apple fell into a hole, you could smash it over the head a few times to kill it.

So there were two things you could do with the shovel: dig and smash. To activate the shovel, you pressed the spacebar. That skill is pretty easy to acquire. Want to dig a hole? Hit the spacebar. What to smash an apple stuck in the hole? Hit the spacebar.

Now, is that one skill or two? For argument’s sake, let’s say that smashing is an advanced form of digging. After all, you have to dig holes first. Then you have to learn how to get those pesky apples to fall into a hole, and to be close enough when it happens to start smashing it. Smash too late, and the apple wriggles out to eat you.


Skill chains for Apple Panic

Apple Panic had a few other skills to learn. The movement skill was pretty easy to acquire, too. Just use the arrow keys to go back and forth on a level or up and down ladders.

Avoidance was a more advanced form of movement. You didn’t want to get stuck between two advancing apples without enough time to dig a hole on one side or the other.

Finally, the crowning skill was learning how to coax an apple into a hole by jumping into it yourself. The attacking apple would follow you down and get stuck, as you sailed on through to the next level down. Then you’d have to run back up quickly enough to smash it before it escaped.

Fun stuff. I remember having a blast in the computer lab.

In those days, time at the computer was precious. Yes, boys and girls, there was once a time when a “personal computer” was a new concept and getting 20 minutes to play a simple game like Apple Panic was pure heaven.

As a result, I never had a chance to get bored with Apple Panic. Regardless, acquiring skills is clearly a big part of the fun of playing games.

As for the claim that everything else is secondary, I have a different take. The blend of a number of qualities is what’s important, and acquiring skills is just one of them.

If you want me to write more about this topic, show me some love, and clap a few times.

Also, you might want to read The Chemistry of Game Design, which was the inspiration for this post.

Finally, you can learn more about my course, Design a Game.


How to Become an Expert Regardless of What You Know

I was hired into a mess.

At most software companies, that’s called normal. Software development is a blend of science and art, where the normative state is for things to be at some level of disarray. Even the best teams are composed of people, and everyone makes mistakes. Besides finding the balance between crossing every ‘t’ and releasing sometime this century inevitably leads to shortcuts.

Assuming you do everything correctly, you will still end up with a pile of code that is not structured correctly for some future demand. As long as you are successful, you will have many future demands. More likely, someone else will have demands to satisfy on your pile of code. It’s tough to jump into another person’s art and “take it from there.”

So given the way things tend to go in software, the mess I stepped into was not too surprising. In fact, it was a great time to be hired because there was a serious problem to solve, which gave me a chance to be part of the solution. Also, the management was committed to do the right thing, even if it meant (as it turned out) taking a year to overhaul the architecture. Kudos to the management.

Through that year of intense development, I became an expert. While we were pounding the software into shape, my enterprise software expertise was forged. I wasn’t alone. That experienced turned out a dozen experts who went on to lead other initiatives and teams.

That’s one way to become an expert. Take on a difficult challenge and see it through. By being directly involved, you gain knowledge and insight that no one else has. Congratulations. You are now the go-to person for maintenance issues and sales people who want to push the limits of what they can promise customers.

That’s expertise.

When our year-long recovery project was over, we decided to fix our development process to avoid the mistakes that caused the architectural problems in the first place.

Despite preaching agile to customers, the development team was following textbook waterfall development methodology.

  1. Write a complete requirements document.
  2. Hand off to developers to implement their interpretation of the requirements.
  3. Hand off to Quality Assurance testers who immediately would find ambiguities in the requirements, bugs in the code, and gaping holes where entire features were missing. Turns out that some of the features were deemed “stupid” by the developers, so they didn’t bother putting them in. They also didn’t bother to tell the PMs about it. They were avoiding a fight, or at least deferring it.

Kind of dysfunctional.

So we decided to adopt an agile methodology. That’s with a lowercase ‘a’ to emphasize pragmatism over dogma. Agile was in its early days, and we needed an expert to show us the way. Luckily, a leader of another product team was said to be an agile guru. For the sake of the tale, let’s call him Bill.

Bill is the kind of expert that is book smart, and he loved to preach things by the book. The problem with Bill was that he wasn’t great at following his own advice. That’s because pure methodologies tend toward being impossibly perfect, and perfection is unattainable.

The same is true of design patterns. They show how to put together some code for a certain effect, but they leave out what to do at the fringes because they’re just patterns. Not instructions on how to assemble the whole quilt.

Bill was the kind of guy who would spend hours and hours reading up on the latest theories, which is how he became a “guru.” He just never applied the knowledge to see if it really worked. Often in a follow-up discussion with Bill, I would learn that what used to be an “essential” step in the process was now considered to be an anti-pattern, something one should avoid at all costs.

Bill is a bleeding-edge, book-smart expert. He stays up with his reading while you fall behind trying to follow his advice.

That’s not a total knock on Bill. There’s value in being pointed in a good direction. We were able to extract a pragmatic approach out of his purist advice without too much trouble. That new process served the team well for many years.

Another way to be an expert is the fake-it-till-you-make-it way. That takes chutzpah or nerve to boldly declare that you know the best way, while your confidence is based more on optimism than expertise.

Hey, I suppose I have used that strategy to reach some of my proudest moments. At that same company, I led the charge into cloud computing without quite knowing how it would turn out.

The cloud became an obvious thing some six or eight years ago. At that point, Amazon had been working on their API-only strategy for a decade or more, Salesforce opened its APIs and hosting with sforce, Google was installing data farms for its cloud offering, Microsoft had Azure going on. The skies were dark and stormy with so many cloud solutions overhead.

Meanwhile, our company was still debating it. Success makes one cautious, so having a debate was not unreasonable. But at some point, it’s time for action. So a few of us charged ahead, and as a byproduct, we became the experts in cloud-based software development.

That’s chutzpah, with a ‘khuh.’


Now I am at it again. I left that company and have been working toward starting Happy Spirit Games for online games and training. Play as you learn. Learn as you play.

What do I know about games? I have been working on my own games in my spare time since I was a teenager back in the 1980s. Nothing too fancy, but good enough to play. I even sold a few copies of an original that I wrote in the mid-90s for Windows 95.

After that, I got busy working on “business solutions”: information systems, online advertising, insurance platforms, and so on. All very important. All very serious. I used my game coding time as a way to keep up with technology that was too experimental for work. Once I became a big-shot manager, I used it to keep my coding skills reasonably current.

But now, through an act of sheer chutzpah, I am a full-time game and course producer. My first game is StoryTime — and I will warn you that it needs a major overhaul. Still, it’s playable and you might enjoy poking around on it, if only to spark some ideas of your own, or for future bragging right that you got to play the original.

My first course is called Design a Game, and it’s almost ready. The course is designed to help beginners get started with game design. For anyone starting out, taking the course is a great first step toward becoming an expert in your own right.

Since you are still reading, here’s a quick recap of how to become an expert.

  1. Spend time solving a major problem. By the time you are done, you’ll be one of the leading experts in that solution.
  2. Read incessantly, always staying up on the latest thinking, even if it turns out to be a bad idea. No one will fault you too much for being ahead of the curve.
  3. Apply chutzpah, or nerve, or guts and imply that you know more than you do until you really do know more than you did. Ha. This way is the most fun.

Thanks for staying with me until the end.

If you are interested in creating games of your own, read more about the Design a Game course, and sign up to be notified when it’s ready.

Sign up for my newsletter. You’ll be the first to know about new games and courses as they are released.

This post first appeared on Happy Spirit Games.

My Mini-retirement

A few years ago, I read The 4 Hour Workweek by Tim Ferriss. The book tickles my get-rich fancies by defining a new category of rich, aptly named the “New Rich.” While few get to be as wealthy as Daddy Warbucks, no one really needs that level of opulence and control. Anyone can become one of the New Rich by earning enough to live comfortably while gaining control over your schedule. Okay, sign me up.

One of the key ideas of the book is to take mini-retirements throughout your career, rather than the traditional approach of saving it all up for the end. You never know if you’ll make it to 65, let alone whether you’ll be healthy enough at that point to enjoy yourself. Lots of people work too hard and drop dead in the first year of retirement. So the advice is to arrange a few breaks along the way.

Tim claims to have coined the phrase “mini-retirement,” and the first time I came across it was in his book, so I believe him. Of course, he earned himself a mini-retirement by writing about them. Smart guy.

So that notion had been bubbling in my brain for a while, along with a growing list of feature ideas for StoryTime (my game platform for interactive fiction), and the fact that my oldest child is a high-school senior and heading off to college soon. Then I took a course last August on how to build an online business, the kind of business that could, eventually, be automated and free up my time, just like Tim talks about in his book.

I have written about the circumstances surrounding my decision to finally make my move, so I won’t repeat that part of the story. Go read about it if you need to catch up. Then come back to find out how this turns out.

Right, as I was saying, I finally decided to take my first mini-retirement, or pre-tirement. It’s not that I can afford to stop working forever, especially with my first born heading off to college and two more in her wake. On the other hand, I had saved enough to afford at least a few months of schedule freedom. So I spent a few care-free months working on StoryTime.

In that time, I got to go on hockey trips without having to ask for days off, to chaperone a couple of school field trips, and to exercise in my living room in the middle of the day five days a week. I kept to a reasonable 6- to 8-hour work day of blogging and coding, and I was able to reach a milestone in StoryTime in early April, a week before tax day.

I also managed to achieve the other thing retired people do, which is to annoy my spouse by being home all of the time. Oops. Guess I didn’t realize that chiming in on every little decision and squabble (between the kids, or one of them and my wife) could be aggravating. Or that using my newfound free time to help with all of the kids’ activities would deprive her of much-needed, non-spousal, social interaction.

I thought I was being helpful. Well, now I know. Time to dial it back a bit.

For the past month, I have been working on the next phase of pre-tirement, called employing-myself-to-see-if-I-can-get-paid-for-providing-what-I-want-to-offer-the-world. Hmm, it might be easier to say that I am starting a company or that I’m bootstrapping a start-up. That’s what I’m attempting, anyway, although it sounds like such a long shot.

No matter, for the last month I have been busy creating an online course to teach beginners how to design a game. The course is called “Design a Game.” Creative name, right? I am following the sage advice of my business advisor, Ramit Sethi, from that course I took in August. He says not to get fancy with course titles. I agree, since I wouldn’t want to mislead anyone.

While I am a big fan of quick deadlines, this is somewhat new to me, so I am being lenient with myself. Also, we’re heading into a busy time of spring hockey, graduation and vacations. Ahhh, pre-tired life is nice. So I’m not quite ready to turn up the heat on the business.

That means you still have plenty of time to sign up for my course before it’s launched to the world. Why not do it now? That way, you’ll know the moment it’s ready. I’m thinking about a one-time discount for people who are subscribed at the launch. Show me your interest by signing up.

Not sure if you want to design games? Sure, that makes sense. Most people just want to play them. I’m looking for people who are bored or frustrated at their day job and want to have some creative fun in their free time. Or anybody who wants to get a start creating games. Eventually this will lead to another course on programming games. Look for that later in the year.

As for my mini-retirement, I’ll say I’m in transition between that and my next paying gig. Whether I can make enough “by myself” is a question to be answered over the summer. If not, I’ll return to corporate life and look for a nice cubicle to park myself in while I earn a steady paycheck.

My bet, though, is on building a profitable business around games that will last many years and make lots of people happy. Maybe in 5 years I’ll be able to take another mini-retirement, just in time to see my son graduate high school.

Here’s to the dream!