What We Learned By Creating BullShoppe

We released BullShoppe earlier this month on Itch.io and now that it’s been out for a couple weeks, why not peel back the curtain and take a look into its development.

Let’s start by looking at the events that led up to BullShoppe. I had been busy spending the first 6 months of Catalyst working on a multiplayer game (to be revealed at a later date) and quickly realized just how much I didn’t know about the game industry. Any time I had found the answer to one question it seemed to revealed 5 more. I felt like Hercules trying to slay the dreaded Hydra.

The Hydra: Destroy one head and another takes its place

So, I decided to pivot off of the more complicated multiplayer title and on to a smaller one that would allow me to answer some of the bigger questions. Here are some of the lessons that the team and I learned while making BullShoppe.

Games & Apps Are Different

I’ve spent the last 20 years learning how to make games and software: programming, UI design, some basic illustration skills, 3D modeling, texturing, etc… But what I had failed to learn was all of the stuff around the technical implementation of something. Not to mention, the majority of my professional career has been making tools. And while video games are a form of software, there are some big differences between building a game and building a tool.

When you’re building a tool (like an app or a website) there’s a clear goal: a problem to solve. So long as the tool solves the problem well enough for the majority of your users, you’ve succeeded. Games are far more subjective. In my opinion, they’re far closer to art than a science. The problem to solve is the same for all entertainment… an escape from the mundane or painful grips of reality.

Games Are About Fun (For the Player)

This is the point where just about everyone is rolling their eyes and saying, “well duh!” But when you’re in the director’s seat and making the decisions of what to build and how to build it, it can be easy to lose sight of this all important goal.

As a developer, your goal is to make things work. This is usually not the easiest task, but when it finally does work… oh man, it’s an amazing feeling.

Making software that finally works is a major dopamine rush

And this can become a real problem for a game’s creator. It’s easy for game developers to veer off the path of creating what’s most fun for the user, and instead add features that we want to see working. We’re chasing the high of overcoming a challenging technical problem, and we start to distort the goal of “what’s fun for the player” to “what’s fun for us to build”.

This isn’t to say that creating games should be a total bore for the developer. In fact, I would argue the more fun the creator is having making the creation the more fun and exciting the creation itself will be. Just make sure there’s a balance. Especially since there’s a lot of tasks involved in making a game that are tedious, hard, or frustrating. Game dev is really a test of perseverance.

Play Test Early and Often

Again, this seems like an obvious step but it’s another one that can easily be put aside. I think this is largely due to personal fears. You want people experiencing your game to be experiencing the same version of it that you have in your head, that’s your exciting about making. Doing this, however, is a detriment to your game being fun to others. By play testing early and often, you gain critical insights into what is and isn’t working in your project.

Don’t Get Married to Any One Idea

This kind of riffs on my previous point, but iteration is king in game development! Be prepared to change or outright throw away some ideas as your game develops. This is especially true as you begin to get feedback from your play testers. Your play testers are your key into how your average player will likely think about and approach your game.

Don’t Assume Things Are Clearly Communicated

If your play testing, this is one of those things that will reveal itself. Just because something makes sense to you or your team doesn’t mean it’s going to make sense to everyone. It’s also easy to fall into the trap of assuming that something will be clear because it’s a common trope or you see it in other/similar games.

We quickly learned that everyone approaches and interperets things differently. Even the play-testers who frequently play a large variety of games missed out on important aspects early on. Therefore we were continually having to tune our UI, sounds, level designs, and animations to reinforce the intended behavior of the game.

Have A Plan On How You’ll Teach Players

Sadly, this is something I feel we utlimately failed on for this title. Noone wants to play a long, dull, hand-holding tutorial, but people also don’t like playing games where they don’t feel they have a good grasp of what’s going on. We did introduce a number of changes during gameplay that helped to improve our player’s understanding while playing, but there is still more we could (and probably should) have done.

An Improvement

The biggest improvement we made towards this was adding prompts for when you can both interact and grab items. In earlier builds, only the former was presented but we quickly observed players being confused on what they could grab and when they could grab it. Adding the prompt helped teach the mechanic of the game and made it much more approachable overall.

One of the best design choices we made.

A Lack of Substantial Improvement

An example of where we failed was the stock room. In each level there’s a backroom area with different flooring from the rest of the level, and in it new products will spawn when a product is sold, broken, or stolen. The purpose is to provide with new items to restock shelves, a mechanic that ultimately was lost on the majority of players.

We tried a few solutions like smoke clouds when items respawn, repositioning the stock room to be more obvious, adding a sign above the stockroom,etc… And while most players will eventually figure it out, none of these ultimately managed to make the intent of the stock room exceptionally clear to new players.

Talk About Your Game While Making It

Another area we ultimately failed is that we didn’t talk about our game publicly until it was released. I could say that a big part of this was due to the short development timeline, which is partially true… But for me, a bigger aspect is that I tend to hold my projects sacred as I don’t want to share them until they’re “perfect”.

But nothing is ever perfect, perfect things don’t get finished. Plus, if you don’t tell people about your idea then you have no audience to share it with. If you’re making a game, please, once you have something to share start sharing it. It will go a long way in building interest for your creation!

Closing Thoughts

Even if you’re not a game developer, I hope that this article is at least mildly interesting. Building games is hard, regardless of what the game is, and it’s always surprising what things will be your biggest hurdles along the way.

Want to be among the first to know the latest news about what we're working on? Then you should join our mailing list!