Catch Phrase Against Humanity’s Freemium Model

The freemium model dominates app stores. My games are no exception.

I have been listening to a book on Audible called "FREE: The Future of a Radical Price" by Chris Anderson. In it, he talks about the history of free and how that price affects certain economies. He describes how people react differently to a cost of $0.01 versus free. He talks about how people value objects differently when they pay for them versus when they are free. He talks about Moore's Law and how certain things (like digital storage capacity) double in size and halve in cost every 18 months.

These topics reminded me of how I sell my mobile games. I'm sure you have all heard of the freemium model: offer a product for free but have advertisements and paid premium features.

So why have this model? The main reason is to reach more people. More people will download an app or a game if it is free. Would you download an app for $0.99 when there is a free one that does the same thing? $0.99 is almost nothing, yet we will avoid it if we can.

Catch Phrase Against Humanity currently has over 7k downloads. It would be a fraction of that without a free price tag.

Income is generated from ~5% of people that pay $2.99 for the premium version. That premium version removes ads, enables a new game mode, and allows for more custom phrases.

The players who paid nothing still generate income from ads. I get anywhere from $1-$3 per thousand views of the ads. There is a banner ad at the top of the screen and then a full page ad that pops up after every other round.

I don't get to keep all of this money. Apple and Google take 30% off the top. Does this seem like a lot? Think about what features they provide that justifies their cut. I get access to every single person with a smart phone in the world. A market of billions of people. If I can stand out from all the other apps and games, then people will find me.

As of this writing, if you search "Catch Phrase" on Google Play and the iOS App Store, my app shows up 4th. That is pretty good, and probably a large reason for the downloads.

I plan to use a similar freemium model for my upcoming action puzzle game, code named "Move the Blocks". There will be ads and a premium mode but how these are structured will be slightly different.

Ad placement is about trying to show as many ads as possible, while not intruding on the game experience. In Move the Blocks, the screen real estate is too valuable to have a banner ad; as in, there is information I need to provide to the player on all screen edges.

There will be a full page ad that pops up every 3 levels or so. Each level could last 10 seconds, or it could take the player a few minutes. In this case, I could also base it on time. If one level is taking the player a long time, then I could show an ad directly after they complete it. I could also factor in level retries. If they fail a level 5 times in a row, then I show an ad. That begs the question: if a player is struggling with a level, do I really want to punish them with an ad? That is the kind of balancing I need to get right.

There will then be a premium version of the game that players can upgrade to. The upgrade will remove ads and unlock more levels. The key here is to give the player just enough gameplay that they want to continue playing more levels by buying the premium version.

This model is definitely the way to go as I keep making small mobile games. If I move into the PC gaming market, then I will adapt to the best pricing model on that platform. For now, everyone can enjoy my games for free.

Early Feedback Proves Valuable Again - Update #2

I completed another iteration to my upcoming action puzzle game, codenamed "Move the Blocks".

This is the 2nd playable version and includes input from feedback I got from the first round of testers. The big takeaways were to utilize more player feedback and to change up level progression.

Player Feedback

To be clear, this is my definition of player feedback: any visual or audio response when the player interacts with the game.

I went on a Youtube binge of videos about player feedback, also commonly called "game feel" or "juice". Basically, the little things in a game that make your game feel good to play but don't necessarily add to the game play. These are things like an animation when the player kills an enemy, or particles that shoot out when you do something good. It is a vast array of things that make the game responsive and "fun".

It might not make sense to add juice to a puzzle game, but just look at a game like Candy Crush. Yes, Candy Crush is a puzzle game and yes, it has lots of juice to keep players coming back. Most of my juice was different animations and movements. Audio is something I still haven't introduced yet.

This is a list of some of the improvements:

• The dashes along the perimeter now disappear when the ball moves over them. It's kind of like a Pac-man type visual and adds to the goal of getting the ball to the end.

• Time rewinds after death instead of just teleporting everything back to its starting position. Blocks move back to where they started, the ball retraces its steps, and the dashes that disappeared now reappear.

• The blocks grow and shrink when moving them to add a sense of weight.

• I added more tweening animations to almost everything. The dashes don't disappear, they shrink out of sight. The levels don’t appear and disappear, they slide in from the left and out to the right.

• When blocks hit each other, they change colors.

• Particle effects when the bonus coin is collected or the level is completed

All of these may not seem like a big deal and will go mostly unnoticed. But without them there, the game can feel stale and unpolished.

Level Design

Level design improved a lot as well. I took the 10 existing levels and added an additional 20. Each section is split into 10 levels called a "level set". Each one has similar gameplay elements. Each level flows into the next as you complete the previous one. After all 10 levels in the set have been completed, your death and bonus coin stats are displayed.

One major gameplay element that I added were blocks that you can't move, but that the ball can go through. Basically it blocks passage for the blocks on the edge of the game area.

I then gave this new version to a few more friends for testing and more feedback.

The first and most frustrating thing for players was that they had trouble touching and moving the blocks. They thought they were touching the block but the game didn't register the touch. I am using Unity's built-in system for handling touch. The fix I made was making the "touch box" bigger on all the blocks.

The next complaint was that there is no way to control the pace of the game. As soon as you die, the level restarts. The players felt stressed when they died a bunch of times while they were just trying to figure out the puzzle. I will implement some sort of pause into the game. Whether that's just a basic pause button or something else is yet to be determined.

The next thing is making the bonus coins more desirable. There really isn't a use for them other than adding difficulty. Constantly showing whether they have gotten the bonus in this level and making the coin stand out more are a few ideas that come to mind. Of course you need to be able to use the coins you have collected to buy something. What that is and what the store looks like is still unknown.

The first level is also still confusing players. I originally didn't want to have a tutorial,  but instead have players figure out the game on their own. To a certain degree, that is actually working. No players need further explanation to finish the game. They just don't like to feel flustered or confused, even if it's just for a split second. I'm thinking of adding some sort of quick image at the beginning of the first level.

The last thing is how the levels are laid out. There are 10 levels in a set and players were complaining that it's too hard to go back and replay one if they didn't get the bonus or want to play it again with less deaths. The concept of level sets is not perfect yet. Think of it like a golf video game, you can't just play an individual hole, you have to play the whole 9 or 18. I think the first step is to bring down the set count to about 4 or 5. Then maybe add a way to play individual levels. I just like the way the game flows from one level to the next. I don't want a level end screen after each level that may only last 10 seconds.

There were a few levels that were a bit too difficult for players. It is hard for me to know how difficult a level really is since I am the creator of the puzzles. It's pretty easy to either make the level slower or take the complexity down a bit.

Iterations will keep happening

It has been incredibly valuable to watch other people interact with these versions of the game. There is constantly something to work on and the game is improving because of it.

Let me know if you want to test the game out! Preferably I would like to be there so I can watch, but I will also have a beta ready soon.

If you've made it to the end, thanks again for reading this blog and supporting me! It means a lot. See you next time.

Cheers

Building a Minimum Viable Game for Early Testing

Early testing fixes problems that would be a behemoth to tackle later in the development cycle.

I had to expose my early builds to people for criticism in order to achieve this benefit. I gave it to a few friends, didn't say anything, and just observed.

I did my first round of testing with "Move the Blocks", aka MTB (just a placeholder name), as soon as I had a playable demo of the game.

For background, MTB is a casual action puzzle game where the objective is to move obstacles out of the way of a ball circumnavigating the screen.

Building the Minimum Viable Game

Like a minimum viable product, a minimum viable game lets you iterate and adapt your game for greater success.

Game Mechanics

First, I got the basic rules and game mechanics working.

For MTB, that includes being able to move the blocks around by tapping and dragging on the screen. The other main mechanic is seeing the ball circumnavigate the screen and start over whenever the ball collides with anything.

via GIPHY

Art

The assets are all currently just "Programmer art" (stand in art if you don’t have the real thing). It conveys basic visual cues. For example, there are some blocks that you can move freely and others that only move horizontally. Horizontal blocks have horizontal stripes to convey the movement pattern to the player. This won't be the final art in the game, but a similar visual cue  will exist.

Level Design

I then designed levels and built in player progression. I completed 10 levels before I handed it over to testers. Each level doesn't necessarily get harder, but it might teach the player a new mechanic or add difficulty to what the player already knows. 10 may sound like a lot, but each level in MTB lasts about 10 seconds (without dying of course).

Testing the Game

I gave it to a few friends to test out. Without explaining any of the rules, I asked them to try out this "action puzzle game" I was working on. I wanted the game to be straightforward enough from the user interface and game design that even a few short instructions were not needed to play.

The testers were not necessarily gamers, and even if they did game, they don’t play casual puzzle games frequently. I want the game to be playable for everyone, so they did just fine.

What I learned

Everyone eventually got through to the end of the 10 levels. No one struggled extremely hard and no one got through without dying at least a few times.

There were still many aspects that needed improving.

The first level is extremely simple, as in, you can't lose simple. But people were confused about what the goal even was. My next iteration will have a different level 1.

There needs to be more feedback when the player dies and when the player collects a coin. The coin is just a bonus objective for the level and acts as the currency for the game. People were confusing it with the ultimate goal and didn't even see their money count go up after they collected it. 

Graphic and audio cues will help with player feedback when they collect a coin or die. For example, I can add sounds and particle effects when they collect a coin or flash a death symbol upon death.

I also realized that I was introducing too many mechanics too early. I wanted every new level to introduce something new. For a game where each level is no more than 10 seconds long, that can be a little much. Having levels that get players use to existing mechanics will help with practice for tougher parts of the game.

For level progression, I want to reorganize the first 10 levels and then get to a total level count of 20. Constantly iterating and improving player progression will help get new players skilled at the game. The less frustration for new players, the more likely they are to get hooked.

Lastly, getting non-programmer graphics, music, and sound effects always loom ahead. Ideally those would evolve along with the game. For now those will have to wait.

This Minimum Viable Game idea has already given me things to work on. I look forward to the next iteration I can show people.