How I Made Reversi Magic For Android/iOS (And Games In General)
A few weeks ago, I took a bunch of my old computer systems (Atari’s, GameBoys and Sega Systems) to my kid’s school to show them off as part of his “History Of Video Games” project he had worked on. Several of the kids ask me, as a games programmer, how I make them, and even my own kids recently have started asking questions about how I make the small games that I do, so I thought I would write this up showing how I made my Reversi Magic game to hopefully educate them a little bit, and also anyone else who might be interested in learning the process.
Firstly, I should start by saying that the various methods used by different people tend to be very different; I take a more OldSkool approach to writing games than say, some of the modern game programmers. Also, being that I work mostly in my spare time, at home, at night, in-between a full time job & managing the kids, some things get done with more priority than others. Someone with more resources/time etc. can probbably get things done a lot quicker. That being said, i’m always open to feedback so feel free to comment on this if you have some 🙂 Don’t shoot me if I do something differently than everyone else 🙂
Coming Up With Ideas
Before I start laying in any amount of code, I usually try to come up with an idea of where I want the game to go. Depending on the game and whats going on, there might not even be an idea yet. Ideas tend to come from existing games, so you might have a couple of web games that seem good, but if one had this feature, or copied ideas from this, it might be even better. If I have a general idea of what I want to work on, i’ll take an empty project file of mine (which consists of the game basics such as the menu’s and basic graphics, enough to be able to press Play, and just start adding game code right away) and modify it to work with a very crude, but simple engine showing the gameplay for this idea. This will be tweaked until the game is able to do what I was thinking of, then its evaluated for how well it plays. Lately I have been playing online casino games at https://imhighroller.com/reviews/genesis-casino-review/, its been fun to play with other people. Some of these tests might seem pretty good, even with very basic graphics (often coloured blocks or re-used images). Others, will be quite bad. It’s not a bad thing if the idea doesn’t yet work, it just needs more refining. After working on a very basic idea, its often good to have a friend play with it and have them give you some feedback. You are trying to find an idea thats engaging to you and your players, so if your friend is very quickly bored, or finds the idea too challenging or confusing, then you need to head in another direction.
In this picture, this game (called Avalanche!) was put together in about 2 days altogether, to show off some ideas I had about a columns-based game, and matching snowflakes together to make some cool snowy explosions etc. In the end, I never released the game, but it was fun to work on the prototype.
In the past, I have prototyped as many as 30+ different game ideas, some better than others, until something comes up. Often, you’ll know when a good idea comes up as you’ll find yourself playing it for ages, while not getting bored of it. Also, your friends might like playing it too. They are also handy to come back on later as well, i’ve worked on some I haven’t touched in years, bringing some new changes and various elements to the table that turn it into a better game.
The Design Process
Once you have thought of a solid idea to work on, it’s often a good idea to do a brief design draft of where the game should be heading, so that you don’t fall off the wagon too easily. If you’re going a route that’s not recommended or you get stuck what to do next, you still have your plan to fall back on for guidance. Again, depending on the type of game you are writing, you can also define a list of specific behaviour rules here, that must be followed at all times. For example, if it’s a puzzle game, you would lay out the logic here exactly, so that you know exactly how it’s supposed to play. If its doing something its not supposed to, you can later analyze this logic to start tracking bugs. This is more important for larger games, or puzzle games that have a lot of different AI/Logic combinations.
Normally I do paper notes for almost all of my games, I still have notebooks with designs in them from my days of writing programs on the ZX spectrum games! One day, i’ll put all that stuff online, but it won’t be today hehe 🙂
Below is my notebook pages that I did for my Reversi Magic game, that’s currently available on Android, iOS and Kindle Fire. The notes were done a year or so ago. The idea was very simple, and I have always been interested in playing Reversi on the computer, with this game not being my 1st on the computer. The goal was to make a simple, easy to pick up game that anyone could familiarize themselves with, without having to learn any new rules or be bombarded with over-the-top graphics. Not all games require notes, but it doesn’t hurt to play with pen/paper every so often to make some design sketches. These 2 pages are the design spec that I originally set forward to complete:
The 1st page just covers some simple layout rules and goals that I would like to have the program meet, and the 2nd page shows some interface layouts for various orientations, and a few other design elements such as an idea I had for dynamic grid frames.
I spent a full month of non-stop coding of the AI engine for the game. The tough parts were testing it to make sure it plays 100% compliant moves, so in the end, there would be a long debug report of the game, how the computer did, as well as opportunities that it took/missed so I could review and tweak the AI later. The AI algorithm itself is based on a combination mix of NegaScout & Min/Max game theories. The Min/Max algo will evaluate scores recursively for the Best/Worst possible scoring points, and NegaScout does some pruning to several paths in that tree, to ensure the answer it comes out with can be found faster. Combine this with some traditional elements of gameplay, a method of looking at grid moves to determine how risky they are, and you have a very powerful AI routine. You can learn more about the Min/Max methods Here in this great tutorial (with samples and images).
The next hardest part of programming the AI was to teach the computer not to be too hard on beginner players. Its programatically easy to make the computer as hard as nails when it comes to playing the game, but how do you adjust those levels so that they are somewhat forgiving to a new player? Again, with a reverse NegaScout algo, and a few other traditional playing rules implemented, the computer will now assist the player to some extent when playing its moves, so as not to dominate. Of course, there are always some people who are just not very good at the game (or Reversi in general), and as I have seen on the feedback for my games, they think the game is the fault and tend to leave negative feedback because of that.
Your game should also show assists/help to your players, for when they get stuck and cannot decide where to play a move. They also may not realize they can play a move in certain areas. In Reversi Magic, I added options that show you where you can place a tile, they actually cycle in and out as small transparent disks of your colour. Tap the disk to place your move. There is also an option that shows you where the opponent last moved, so if you are not following the board too closely, you can still see where they last played and how it affects your strategy. Both of these assist options can be turned off in the game Options screen at any time, though they are enabled by default for first time users of the game. In my original design, I had wanted to show how many disks were going to be flipped for each move that was shown as available, but as experienced players will tell you, playing for the best possible score every time is not the best playing strategy at all, so I eventually removed it.
Cleaning Things Up
Now that the majority of your code is done, the last part of the process is to apply the spit & polish needed before you release it. For me, this is usually when I will finalize all of my graphics, and add all of the last bits of fine tuning to the game. Normally, i’ll sit in a room with my Nexus 7 and play the game, write down all the stuff that I see that is annoying, or needs fixed (out of place text, menus that move too slow, playing effects that should happen that don’t, ways to improve the ingame experience etc. etc.) and then after I have the list, i’ll set forth on making the changes. If you are not already doing so at this point, its often a good idea to send out your game to some private testers. Friends/family often make a good choice, but you want to pick some who are open to give you criticizing feedback (and some who will actually give feedback!) Listen to their complaints and what they think might make the experience better. You might not be able to implement it 100% exactly as everyone wants it, but you might be able to meet in the middle, especially if several testers are reporting on one specific area/feature of the game (which normally means you should focus some effort on it anyways).
From Prototype, To Finished Game
In the above pictures, I have used my game Twinz! as an example of what the game may look like in prototype, to the final product. The left screenshot is from the prototype game I did in about 2005 or so. It was just a handful of images, a simple shaded image for the door shutters, and a small logo. The image on the right is taken from an iPhone running the released version of the game. As you can see, the screen’s real-estate has been cleaned up to make the size of the tiles more optimal, and get rid of the unused areas. This game runs great on tablets, and features high resolution tiles.
After the launch, you can sit back and watch your total downloads go up for each market, and wait for your customer’s feedback. Most players are nice in that they will contact you directly about any bugs they might find, before they leave negative feedback, so if you do get not-so perfect app feedback, or bug reports, be sure to get right on top of them and prepare for an update in the future.
While I have yet to become mega rich or famous from one of my games, this is still a hobby that I love to do, and hope that one day at least one of my games will be successful enough that I can quit my job and focus on doing this full time 🙂
If you want to play any of the games mentioned above, or any other games of mine, please visit the app store for your preferred device and try them (there are free versions of all of my games): Amazon App Store (For All Kindle Fires), Apple App Store, Google Play
Should you find the info in this page useful for anything, show your support by buying a game! If you have questions, ask in the comments or send me a quick email. Thanks!
This entry was posted by FishGuy876 on June 14, 2013 at 1:16 pm, and is filed under C / C++, Games, Reversi / Othello. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site.
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Leave a Reply