This is the first time that I have sold software. I have given away lots of software and have done an ad supported phone app, but this is the first time I am asking people to part with their money for something that I made.

Getting the software ready for release has been a lot of work. All of these games have been done and playable for a long time, but there are a lot of things that have to be done before software is ready for public consumption. Here is what we have been doing for the last week to get ready for release.

• Support for windows touch events instead of just TUIO: We can sell to more people if we support windows touch events too. Unfortunately, windows touch events don’t have velocity information like TUIO events do. So I also added code to buffer up the incoming events and calculate a velocity. This also involved adding code to detect which touch events are coming in and only processing one or the other.
• Support for windows XP: XP didn’t have touch events, so we had to be careful not to call those functions directly and instead call them through function pointers returned from GetProcAddress.
• Support for lower-end hardware: We went through all of our graphics and reduced the sizes to at most 1024×1024 so that the games would run on older graphics cards.
• Removed requirement for redistributable: The way that we were building and linking a font library was causing a dependency on the C++ redistributable, so that had to be changed.
• Contracts: We wrote contracts for the two sites that will be selling the games.
• Instructions: We had some instructions within each game, but we made those better and made PDF instructions and took screenshots of the games.
• Remembering preferences: We added configurable options to some of the games and added a ‘fullscreen’ button to all the games. And we added saving those preferences between runs.
• Installers: We used Inno Setup to create installers for each game and for the bundle of games. We learned about a few more options in the Inno program because we needed to only remove the game launcher once all of our software was un-installed, and we needed to clean up our saved preferences.
• More testing.

Overall, I would say that we have spent a full week just on getting the games ready for sale. Some of that work went into engine improvements that will apply to all of our future games. And the next game that we release will have pre-made contracts and installers ready to go. If we end up releasing a lot of games, this time will be worthwhile, but I don’t really expect to make enough from this first set of games to justify the effort required to sell them.

It is not possible for the computer to look through all the possible games to decide what to do since there are a staggeringly huge number of games. I decided to make the AI score each possible option after each throw. The tricky part is scoring the possibilities. The first step was to build a table of all the possible combinations of the five dice and how likely they are to come up. For example: there is only one way to roll all ones, but getting four ones and one two can happen five ways. For a given roll, the choices that you have depend on the rejects that you have taken so far. So, for each set of three rejects, I looked at each dice combination and built all the choices that you would have. For example: if you are rejecting 1,2 and 3 and you roll 1,3,4,4,5 you can: reject 1, take 7,9; reject 1, take 8,8; reject 3, take 5,9; or reject 3 take 6,8. So this roll give you one way to score 7, three ways to score 8, two ways to score 9, etc.. I then add the number of times you could take each number times that number’s score to the weighting for that number. In the previous example there were three ways to score 8 * 60 ways to roll a 1,3,4,4,5 * 40 points for eight = 19,200. After going through all the possible rolls I had a weighting for each number, repeating for each set of three rejects, I had a strategy of which dice to take based on your rejects.

The next step was to write the actual game AI based on this strategy. The AI played by scoring each possible choice and taking the best scoring choice. The choice’s score is the amount of points you will gain/lose for scoring those dice, plus a factor for getting the set of three rejects that the strategy picked, plus a factor for getting the three rejects picked quickly, plus a factor for keeping the rejects taken a similar number of times, plus a factor for picking scoring pairs that have a high weighting. I picked the relative importance of each of the five factors by hand.

The next step was to make some improvements to the game logic. I wrote some code to handle the fact that scoring two of the same number in one round is not the same as scoring each number separately. I also wrote code to handle the symmetry of the rejects: 1,2,6 is the same as 1,5,6; so if your strategy is to go for 1,2,6 and you have the option to reject a 5, that is just as good. And finally, if you are forced to reject a number outside your strategy, I update the weightings of each scoring number. Once all the play logic was written, the AI was scoring about 0 points for the best set of rejects and -100 to -50 for the other sets of rejects.

The next step was to write code to run the game many many times with different values for the five scoring factors to find the best set. To do this, I create a population of 20 different values and play 50K games. The top scoring set of values is then used to make 20 new strategies. Repeating this 100 times results in a good set of scoring factors. This step improved the AI to an average score of 65 for the best reject set and 10 for the other reject sets. The average human averages -50 and a good player can average +100.