Cribbage vs Robots

I’m experiencing a bit of a creative streak recently, creating several new games so far this year. I returned to app game development after more than a year away from it. My first game in this series, Island Golf, was a success in that I enjoyed making it, remained focused on the app all through development, and really took the time to fine-tune it before release. The result was a good game that had no major problems, even if it wasn’t much of a success in the store.

I followed that up with Nonograms Unlimited. Nonograms are en existing game, so I was simply implementing my version of that game. But this game, which includes ads, was more of a success. I won’t make a ton of money from it, but it looks like it will contribute a small piece to my bottom line from now on.

My third game, just released, is Cribbage vs Robots. Cribbage, of course, is an existing game. So this is just another chance for me to implement it better than existing apps. I think I’ve done a good job at this. I played a lot of other apps and figured out what I like and don’t like about them. I tried to make it quick and easy to play, removing all frustrations in handling the cards on a touch screen.

Since Cribbage is a two-player game, and I wanted to make a one-player app, I had to write a game AI to challenge the player. Writing a Cribbage AI is challenging, as most are. But you really need to balance the intelligence of the AI with its ability to make mistakes. No one likes to play a game and lose. People like to win. And playing against a perfect AI would make this a really bad game. At the same time, a perfect AI would take up a lot of processor time to run all of the numbers. So making a perfect AI and introducing some randomness to it wasn’t the way to go.

So I tried three different approaches. The first plays based off some basic rules that beginner Cribbage players are often told. So it looks for things in its hand and during the play, and applies the rules. The second uses a much more complex set of rules taking into account most situations and also looking at point values of cribs very closely to compare moves. The third is very different, running simulations of what would happen if cards were played or placed in the crib. Instead of considering all possible outcomes, which would take a lot of computations, it runs thousands of simulations based on decisions and picks the card(s) that score the best.

I liked all of these AIs. That’s why I decided to include them all in the game. This led me to the idea of creating “robots” that you could play against, each using a different AI, plus a random element to them to make them more unpredictable. So 6 different robots, two for each AI plus one a little more random than the other.

I actually come up with a fourth AI that I didn’t use, but was very interesting. This was my placeholder AI that I used to test the interface during early development. It was a completely random AI. It picked a random valid card to play each time. The surprising thing was that it played pretty well. After all, to pick 2 out of 6 cards for a crib is only 15 possibilities. So that’s a 1-in-15 chance of getting it perfect, and probably a better than 50% chance of making a reasonable decision that a beginner human would make. Then for the play, there is really only a 1-out-of-4 choice to make, followed by a 1-out-of-3, then a 1-out-of-2, then only one card to choose from. So there aren’t that many options. Often the random choice was reasonable, and sometimes it seemed like the random AI was being very clever.

From reading other developer blogs I know what to expect now. I will get complaints that the AIs are too hard. I will get complaints that they are too easy. I will get complaints that they “cheat” even though they do not. I will get requests from people to include their favorite Cribbage rule variations or suggestions to speed up or slow down gameplay. Cribbage players are very passionate about their game. But the main thing I need to focus on is the game’s success. I can worry about adding options and pleasing players if the game is successful.

Meanwhile, I am already well into the development of my next game. But this is going to be a bit of a weird one. I started making a word game. But the way the game looked moved me to making it a trading game. Right now it is both. I’m not sure anyone will want to play such an odd game. We’ll see how it goes.

Posted on April 24, 2018 at 10:34 am by site admin · Permalink · Leave a comment
In: General

Island Golf Development Notes

Island Golf is my first new game in more than a year. That’s probably my longest drought since I started making games in 1995. I’ve been busy developing online courses and had been discouraged by the lackluster performance of my last few games and the App Store in general.

Back in December I actually went looking for an idea for a new game that was small enough so I could spent lots of time perfecting it. I developed some quick prototypes for a number of games and tossed them away. I noticed a golf-like game in the app store that was new and doing well, and very simple. That made me think about one of my very first successes as a game developer.

Back in 1996 I had started making Shockwave games for my own website and was getting a lot of attention. One of those games was called Pretty Good Golf. It was a very primitive 2D golf game. Shockwave didn’t even have hit detection at that point, so I had each fairway drawn with a series of horizontal and vertical ovals. You can calculate hits using simple math with those. The game looks so primitive today. Actually, it looked primitive then too. But in 1996 people were just amazed that you could interact with a web page at all.

Pretty Good Golf was actually the first game I licensed to another company. I continued to improve the game for a couple of years and then stopped working on golf games to move on to other things. So it has been at least 15 years, maybe more.

I started off creating this new golf game in Adobe AIR with one very important goal. I wanted the courses to be generated randomly from an algorithm. I remembered what a pain it was to make the courses for Pretty Good Golf. For this new game, I wanted a new fairway to just appear, and an infinite number of random fairways to come after that. I actually started with the idea that you would just keep playing holes in an infinite golf course.

So I embarked on weeks of development playing with algorithms that I devised to create a realistic-looking course hole. There had to be a fairway, surrounded by rough, then trees. And there had to be sand and water features too. And it had to be playable. And it had to fit on an iPhone screen and an iPad screen. And not too easy or too hard.

I started and tested and tossed dozens of models. I started over from scratch many times. I marked up my whiteboard with diagrams and equations. I loved it. What fun!

Eventually I got an algorithm that worked. After weeks of work on that, it took me about an hour to create a simple interface to “play” the holes. And I had a game where you could play hole after hole, never seeing the same hole twice.

One day I had the crazy idea of changing the background color to blue to see if the fairways would look like an island. It did! A few more adjustments and there were sandy beaches all around and even fairways that existed on multiple small islands where you had to hit the ball across the ocean. And it gave the game an artistic theme! I changed the trees to palm trees and worked on adding jumping dolphins and seabirds flying by.

And speaking of palm trees, I looked for some good vector palm trees and couldn’t find anything that looked just right. How hard could it be since you could make a palm tree with a few simple shapes. So that’s what I did. I spent a day creating an algorithm that created palm trees using math. That’s why all the trees in the game are slightly different. They are all generated randomly! Math FTW!

So the original game presented you with an infinite course. It was more of a toy than a game. So I changed it so you started with a set number of strokes and you saw how far you could get. With 50 strokes you could maybe make it to 7 or 8 holes before running out as a beginner. But someone good could go 18 or even 22 holes.

But after some testing, it turned out that this didn’t work so well. If you played an exceptionally good game, and so got to 21 holes, then it was unlikely that you would beat that any time soon. You would try a few times and then give up.

So I went back to the idea of a normal 18-hole round of golf. I wanted to do a high score board too. In order to make that fair, I switched from completely random holes to random holes starting with a random seed. So each day presents a new course, but the exact same course for everyone based on the date. Now you had a level playing field. And each day the high score board starts fresh. Hopefully this will keep players coming back. I know it does for me.

One difficulty I had to overcome with course generation was to make the holes look fine for such different screens. The iPhone X screen is 1125×2436, a 19.5×9 ratio, while the iPads are all a 4:3 ratio. So too wide and the fairway barely takes up any space on the iPhone X, leaving the top and the bottom of the screen blue water. Too tall, and the iPad screen has lots of water on the left and right. But the fairways had to be exactly the same to make the high score boards work. So there was a lot of compromise there.

How about monetization? Should I put ads in the game? In-app purchases? Or, just charge $2.99? I decided that any of these would hurt adoption of the game at the start, so I came up with the idea of doing it completely free. If the game is a hit, then I’ll pick one of those three in a future update. In the meantime, maybe I’ll get some more traffic to my other games.

Now that the game is out, what next? Well, I want to focus the next few weeks on just getting more people playing. It is unlikely that I will get featured in the App Store, or reviewed by a blog or site or anything like that. That takes luck, connections, or marketing bucks. But this time around I don’t want to be shy about spending money to buy ads from Apple, Facebook, Google and Reddit.

Of course I also have ideas for future updates if the game is a success. I want to improve the high score board with longer scrolling lists so you can see beyond 20. I want to improve the artwork in the game, especially the little pieces of flair that appear on each hole. I’d also like those to reflect holidays with little Valentines hearts, Shamrocks, Christmas trees, and so on. Maybe there should be two courses each day, to spread the high scores out. Maybe a north Pacific theme to the other course. Well, I don’t want to get too far ahead of myself.

Posted on February 9, 2018 at 10:54 am by site admin · Permalink · Leave a comment
In: General

A Free-First Approach: Thoughts On Mobile Game Monetization

I’m finishing up my first new mobile game in a while. I need to figure out how to monetize it. I wish there was a group or forum with other mobile game creators where I can talk about this stuff, but I haven’t found one. So I’ll talk about it here and maybe come to a conclusion. Or, maybe my thoughts will help someone else.

The most obvious way to monetize is to simply charge for the game up front. This was the original method, and has been around since day one. The problem is that with so many free and free-to-try options, you won’t get that many people to pay for something up front. Sure, if it has a big brand name in front of it, or you can afford to spend a lot on marketing, you can break through that. But for a small indie developer with no brand name content, you’ll just see zeros.

Soon after the app stores got going around 2008 or so, the second monetization method started up: advertising. This is what I use for most of my games. You allow a network, like Google AdMob, to place banners or interstitial ads in your game, the user is annoyed, and you get a steady income. This allows you to keep the game free, so more people will at least try it out. But it sucks from a design and user experience standpoint. Plus, the one network that did this really well, Apple’s iAd, doesn’t exist anymore. AdMob only pays a fraction of what iAd did.

Most big mobile games make money through in-app purchases. From a game design standpoint, you can have nice purchases like game levels or more content. But that’s not the model that really makes money. The big apps all sell in-game currency or objects. Often, you need these to advance, or at least advance quickly, in the game. The hope users get addicted to the game and then fork over the bucks. This works great when you have a ton of users and marketing money. It also requires a deep game with a lot of internal content. Small casual games can’t really do it as well, which is why it has never really worked for me.

So here’s where I am going with all of this. I have a new game to launch. I can just stick ads in it. Or. I can just charge for it. The first one may work, but I hate it and it really complicates the design. Also, when I first launch the game I can’t expect to have too many people playing, which means I won’t be seeing any real revenue anyway. So why not start with no ads, and then add them later if the game gets popular? This should increase the chances that the game is a success, right?

Or, if I plan on charging for it, I know it will be a failure right away. No one will pay $3 or even $1 for a game they have never heard of from a company they have never heard of, with no reviews. But if I start it out for free, I can always charge for it later, right? So why not start it for free, and if it fails then it would never have worked as a paid app anyway. But if it succeeds and gathers some reviews and downloads, then I can switch to charging for it.

Or, I can do in-app purchases. But that would require the development of a lot more content. I’ll need new game modes, features, etc. But I can start it out as a free app and then add all of that content later on. At that point I can start charging for the new content.

So all three monetization methods seem to work with a free-first approach. I put the game out for free. Then I can decide whether to charge for it, put ads in it, or add content. Heck, I can do all three. People that downloaded it for free can’t complain (though they will). And I can make one of the in-app purchases to remove the ads.

So a free-first approach is just the logical approach. But then why don’t I see it more often? Maybe I’m just not looking for it. Maybe these free-first games have already moved on to the paid/ads/in-app stage by the time I see them.

And there is one more advantage to the free-first method. There is a halo effect when a game does well. People will seek out other apps from the same developer, partially because the app store shows them. So if the game does well I should see an increase in ad revenue and sales from my other games even while this new game is free.

OK. I think I have talked myself into launching my new game as a free and ad-free app. We’ll see how it goes.

Posted on January 12, 2018 at 5:20 pm by site admin · Permalink · Leave a comment
In: General

The iPhone X Is Not a Good Gaming Device

So I recently went on high alert after getting an email from AdMob saying that we all need to update our apps so the ads aren’t messed up on the iPhone X screen. This was a few weeks before the iPhone X existed in the world. But we only had 2 weeks after that release to make the changes. In the past it took Apple up to 2 weeks to approve changes, so this seemed like a panic situation.

I would get my iPhone X on Nov 3 and work all that weekend to update my apps so they didn’t violate this AdMob edict. The penalty for failure could be that AdMob kicks me out and my app revenue comes to a halt. So I even spent some time before Nov 3 getting ready by adding code to move the ad down a bit. But I could only do so much until I had the phone in my hands. A feature in Animate/AIR that allowed you to use the iOS simulator from Xcode was broken in the current version, so I couldn’t even guess as to the size of the “notch” at the top of the iPhone X’s screen or the depth of the corner curves. I just nervously tracked my iPhone’s shipment progress and waited.

Turns out, I didn’t have to worry at all. Apps that are not optimized for the iPhone X’s screen simply show in a rectangular window that fits well inside the notch and corner curves. It actually tries to maintain the screen ratio of the iPhone 6/7/8. So all of my games worked fine and the ads weren’t obscured. All that worry for nothing.

But I decided to update some of my games anyway. That way at least they used the whole iPhone X screen.

Well, it turns out the iPhone X is a horrible gaming device. The reason is it is a very vertical screen. Instead of 16 by 9, it is 19.5 by 9. Yeah, that tall.

I guess if I were to develop a game for that screen size, it would be fine. But I make games that have to work at the 4 by 3 ratio of the iPad. I can sometimes stretch them out a bit for iPhone users. But to go from 4 by 3 to 19.5 by 9 is … well, more than a bit of a stretch.

And it gets worse. No home button, right? So there is this new “home indicator” line that appears at the bottom of the screen. And by bottom, I mean the bottom at the current orientation. So a horizontal game, like most games, will have this line taking up 40 pixels or so at the bottom. That makes the remaining space even thinner. So you end up with something like 2436 pixels across and 1085 vertically. To put a 4 by 3 game in there means tons of space to the left and right are blank.

And the notch itself isn’t helping. To center the game, but not try to use the “ears” at the sides of the notch, means that there will be a corresponding blank patch on the right as well.

Now if I had one game that I worked on. One game that I poured my development hours into and maintained and care for. Well, then I would probably have separate screen designs for the iPad, iPhone 6/7/8 and iPhone X. I’d work carefully to optimize the design for each.

But I’ve got 25 games or so, some of which bring in only a few pennies. So I’m not going to do that. And I’m willing to bet that even big development companies with major games aren’t going to make a custom iPhone X design either. The result will be to make the iPhone X an even worse game phone.

Posted on November 29, 2017 at 7:55 pm by site admin · Permalink · Leave a comment
In: General

New and Improved Isn’t Always Better

Can you spot the problem with the title of this post? “New and Improved” is just “Improved” as the “New” is redundant. So “Improved Isn’t Always Better” is the real statement. But the definition of improved is “better.” So improved is, in fact, always better.

But nonetheless this exact statement was one made by a player of my jigsaw puzzle game, which I just converted from Flash to HTML5. In doing the conversion, I made sure that it as, in fact, improved. Included every feature of the old game, added new features and options, improved the quality of the images, and by simply converting to HTML5 I made the game playable to millions more people who do no have Flash installed.

What this person really meant to say, was “I do not like change.” The new game is different than the old one. There’s a subtle difference in the shape of the pieces, for instance. They have been playing the same game for years and now suddenly it seems unfamiliar to them.

It is a valid feeling. And very human. I have dealt with as a developer all of my professional life. Make a change to software, and even if it is clearly an improvement in every measurable way, there are people who will complain because they don’t want change.

But things need to change. It is very obvious here, with Flash being more and more hated and approaching its official retirement, that I need to move the game to HTML5. As a mind experiment I think of this person in 4 years suddenly finding that the game doesn’t work for them anyway. “Well, you didn’t want me to change it, so I didn’t. And now Flash is gone and you can’t play the game.” Or, maybe they read a blogger who spews hate for Flash and decide to uninstall it to find themselves in the same situation, but sooner.

So as a developer, I’m the one who has to bend. I can’t ask the user to do that. So I explain the changes, explain why they are necessary, and leave it at that. If I can’t convince the user that the new situation is better, then I have to let them go. It know it will be better for a majority of the current users, and all of the future users. So I press on.

Posted on August 4, 2017 at 11:28 am by site admin · Permalink · Leave a comment
In: General