Making A Game: Siberian Dice
I was asked to shed some light on the development process of Siberian Dice. Surprisingly, there are interesting aspects to speak about.
First of all, it was not meant to be a mobile application. It was all started as a purely mathematical endeavour. Initially, we wanted to investigate some properties of the game, once it appeared so elegant and sophisticated to us. At a certain point we decided to develop an AI, in order to produce some «real» games for further investigation, where by «some» I mean an amount orders of magnitude greater than a human can produce simply by playing the game full-time for several years.
So we did.
But the AI revealed another problem (or shall I say the same problem which we ultimately failed to solve because our approach was fundamentally wrong) AI has to be trained, the games it produces were very not «real», it played its own strategies reasonable only within this artificial world of competing AIs, not what we wanted. How could we expect anything else? So we needed to train the AI on some real «real» data. I requested all the statistics we have so far in the physical existence. Presently we discovered that there were no recorded games on earth. These people do not keep game records (by the way, «Orochi» is the name of the people, I certainly must tell about them later on). Thus, we must produce the statistics ourselves, but how? I certainly can not play 10M games, I would probably die long before I accomplish this task. Artem, the discoverer of the game, came with the solution he regarded as the most obvious and smart — we must create a game server, crowd thousands of players, and record all their games.
So we did.
In a couple of months the server was up and running. Perhaps it deserves some attention, but it is a topic for another time. So, we have equipped ourselves to create the data we were craving, but… this second part, about the crowd… Who is going to play a rare peculiar game? None of us is a university professor empowered to force the students to do the job. It turned out that we need a lure — the game must be a pleasant experience in and out itself. Thus, we decided to upgrade the game interface.
So we did.
Except for the colour scheme the user interface was the biggest challenge in the development of the game. It actually took two parallel development jobs (not mentioning multitude of the dead-ends visited), both interfaces were complete and one was trashed. It also cost us a fight. But, after all I am proud of the UI we developed, it minimizes the amount of clicks and introduces the bare minimum of «must learn» entities to the user. It is developed with a the idea of «minimum information overhead» in mind. Every visual detail conveys some useful information to the user, and almost every user action is mapped into the game, there are very few «navigation» actions in the UI, we do not want our users to waste an instant of their life managing the interface. Interface is like the peel on a fruit — the less the better. I am sure no one can propose a smaller interface than the existing one. But it is not the point of the story, where was I? We had the server, and the web-interface, and we needed as many player as possible, so we decided to expand to the «mobile world».
So we did.
In order to migrate the existing web-interface to «android» we decided to employ Apache Cordova, which seemed to be the shortest way. It is perhaps the shortest, but it turned out to be not so short in absolute terms. Plenty of improvements were done in the course of adaptation to the «mobile» environment, so that the UI ended up much better than the original version. Because of that I decided to migrate it back to the web. And this was a pure joy! The Cordova's application HTML/JS-code simply works in a desktop browser without any serious alteration (I literally commented two lines out, nothing else (these were references to specific «smartphone» hardware)).
So we end up having a full blown game.
The lessons to be learned:
Cordovan code migration from «mobile» to desktop is just great and way better than the opposite direction.
JSviews is MAGNIFICENT. It is truly data-driven, very clear, transparent, and communicates with the rest of the world well (primarily it communicates with the rest of your application at all). Also JSviews creates no trouble at all in the «mobile» environment, and gets along with Cordova without interference.
First of all, it was not meant to be a mobile application. It was all started as a purely mathematical endeavour. Initially, we wanted to investigate some properties of the game, once it appeared so elegant and sophisticated to us. At a certain point we decided to develop an AI, in order to produce some «real» games for further investigation, where by «some» I mean an amount orders of magnitude greater than a human can produce simply by playing the game full-time for several years.
So we did.
But the AI revealed another problem (or shall I say the same problem which we ultimately failed to solve because our approach was fundamentally wrong) AI has to be trained, the games it produces were very not «real», it played its own strategies reasonable only within this artificial world of competing AIs, not what we wanted. How could we expect anything else? So we needed to train the AI on some real «real» data. I requested all the statistics we have so far in the physical existence. Presently we discovered that there were no recorded games on earth. These people do not keep game records (by the way, «Orochi» is the name of the people, I certainly must tell about them later on). Thus, we must produce the statistics ourselves, but how? I certainly can not play 10M games, I would probably die long before I accomplish this task. Artem, the discoverer of the game, came with the solution he regarded as the most obvious and smart — we must create a game server, crowd thousands of players, and record all their games.
So we did.
In a couple of months the server was up and running. Perhaps it deserves some attention, but it is a topic for another time. So, we have equipped ourselves to create the data we were craving, but… this second part, about the crowd… Who is going to play a rare peculiar game? None of us is a university professor empowered to force the students to do the job. It turned out that we need a lure — the game must be a pleasant experience in and out itself. Thus, we decided to upgrade the game interface.
So we did.
Except for the colour scheme the user interface was the biggest challenge in the development of the game. It actually took two parallel development jobs (not mentioning multitude of the dead-ends visited), both interfaces were complete and one was trashed. It also cost us a fight. But, after all I am proud of the UI we developed, it minimizes the amount of clicks and introduces the bare minimum of «must learn» entities to the user. It is developed with a the idea of «minimum information overhead» in mind. Every visual detail conveys some useful information to the user, and almost every user action is mapped into the game, there are very few «navigation» actions in the UI, we do not want our users to waste an instant of their life managing the interface. Interface is like the peel on a fruit — the less the better. I am sure no one can propose a smaller interface than the existing one. But it is not the point of the story, where was I? We had the server, and the web-interface, and we needed as many player as possible, so we decided to expand to the «mobile world».
So we did.
In order to migrate the existing web-interface to «android» we decided to employ Apache Cordova, which seemed to be the shortest way. It is perhaps the shortest, but it turned out to be not so short in absolute terms. Plenty of improvements were done in the course of adaptation to the «mobile» environment, so that the UI ended up much better than the original version. Because of that I decided to migrate it back to the web. And this was a pure joy! The Cordova's application HTML/JS-code simply works in a desktop browser without any serious alteration (I literally commented two lines out, nothing else (these were references to specific «smartphone» hardware)).
So we end up having a full blown game.
The lessons to be learned:
Cordovan code migration from «mobile» to desktop is just great and way better than the opposite direction.
JSviews is MAGNIFICENT. It is truly data-driven, very clear, transparent, and communicates with the rest of the world well (primarily it communicates with the rest of your application at all). Also JSviews creates no trouble at all in the «mobile» environment, and gets along with Cordova without interference.
0 comments