One of the lessons that we learned from PAX is that it is very nice to be able to switch between a human and AI player while playing the game. The only game that had this feature at PAX was Parcheesi. It made people more likely to start a game since they knew that they could be replaced by a computer player if they got bored or had to leave.
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.
We have the first set of multi-touch games ready for sale! We are going to be giving away “Bubble Defender” and selling “Concentration Sweep”, “Temple Raiding”, “Yacht” and “Solitaire Dice”. Initially, they will be for sale at Peau Productions and bundled with tables sold by Mesa Mundi.
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.
I have started a new project for the Touch table called Yacht. It is a public domain version of Yatzee. To take advantage of the multi touch screen, and to make the game faster, I am doing a “shared-dice” variant where all the players share the same die rolls. As a player locks/selects dice, they no longer use the shared roll of those die.
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.