So one of our goals is to update the existing games so that you can switch back and forth between a human and computer player during the game instead of just at startup. Most of the games will be fairly easy to adapt to this system. We generally write the computer players in C++ while the rest of the game logic is in torquescript. This separation has meant that we generally pass everything the AI needs to make a decision each time the AI has to play.

Yacht didn’t have an AI at all, so to adapt it to the new system required me to write a computer player for it.

Yacht is a moderately complex game for a computer to play. The decision of which dice to keep depends not just on what you have rolled, but also on which categories are left to score. To play well, the AI needs to take into account the relative value and difficulty of each category and the chances of getting the bonus.

Fortunately, Yacht has been solved(pdf). Unfortunately, it is still too computationally expensive to use this method while playing a game. I implemented a simpler system. It is fairly simple to find the “best” way to play each round if you ignore future rounds. This is similar to solving for one “widget” as described in the paper linked above. Then, instead of trying to solve for all possible futures, I simply use a set of rules to describe the value of each category. I can also tweak the constants used when applying these rules to make different two computer players play slightly differently.

The computer player plays a pretty good game and is fast enough to not be noticeable. If I wanted the AI to be more sophisticated, I would add more logic for determining the probability of getting the bonus based on the current scores. Then I would try to improve the value that I assign to each category by having AIs play against each other with different settings to see what works best.

Here is what the new GUI looks like:

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 ended up being harder than I expected it to be (which seems to always be the case). There are a lot of different ways that the game can move forward – the timer, the user scoring, or the user saying that they are ready for the next roll. And keeping track of the state of the game and the players we messier than I expected.

I also had trouble organizing and designing my script code. The lack of an enforced structure made it difficult to decide what file/class/namespace would have each bit of logic. Between that and my lack of experience with the script language, I spent a lot of time looking for code and moving things around.

It was also somewhat difficult to get used to the more event and schedule driven game flow. For things to animate nicely, we needed to introduce delays where there normally wouldn’t be. For example, the game rolls the dice, the dice animate, then then game tells the players what the roll was and the player class unlocks the player GUI and displays the ready button. In application software, the dice wouldn’t be animating, and that would all be one flow of function calls. For the game, there had to be a scheduled delay between starting the dice animation and telling the players what the result of the roll was.

Space was also a more limiting factor than we thought it would be. On the 46″ 1920×1080 screen, the smallest button that the user can feel confident pushing on the first try is 32×32. To get things to fit, the scoring regions ended up being only 24 high.

Here is a screen shot of the completed game:

It is going to be eight player with each person having a score and dice region.

I am trying to pick a simple game in order to learn the Torque 2D scripting and game builder. The Hansa Teutonica project used Torque 2D as well, but William is handling all of the script and GUI parts. He has been using Torque for years and is going to help me learn the scripting sytems. He is also going to build the graphics that the game will use.