Dice Wars on App Engine + Twisted

    Since August, in my free time, I have been developing an entertaining risk-like toy in the world known as Dice Wars. The ingenious Japanese game designer Taro Ito came up with wonderful rules for this game and created it on a flash (single-player), and it gave rise to many variations on this subject, still poorly known in Russia. In this article, I would like to analyze my first fail with the risk-like game that I wrote about

    in March, to explain why I abandoned the idea of ​​using App Engine everywhere and everything, to show the bundle from App Engine + Twisted that I came to and which, it seems to me, is quite useful for applications with a permanent connection. In addition, I would like to tell about my experience with Actionscript 3, something like a look at the back end of the developer on this technology alien to me, as well as search here on the hub of companions and like-minded people.

    First pancake


    This winter, I came up with the idea of ​​using App Engine as an application server that implements a polling pattern for instantly receiving events from the server. Those. this is an application that sends a request to the server once a second and receives the actions of other users, chat messages and so on. As an example, I decided to make a simple risk-strategy and use Google maps, their JavaScript APIs in it. And in this game I made two key mistakes, in my opinion such.
    Firstly, with all the charm of JavaScript at the moment, it cannot replace Flash / Silverlight, and many things are difficult to implement. Progressive browsers, of course, support a lot of good features, but like 10 years ago you have to do ifs / switches for compatibility with other browsers. In addition, combining for example canvas and Google maps is difficult. This makes it difficult to create various ryushechek, so necessary in games.
    Secondly, using polling turned out to be bad ideas, and not because it creates a heavy load on the App Engine, it will cope with it, but because polling is difficult to develop.
    Since then, the Channel API has appeared, but it still does not offer the flexibility you have when designing your server that supports a persistent connection. It’s one thing when all the objects you have loaded inside the program, you freely operate them and according to your logic distribute the load between the servers, and it’s another thing when you cannot be sure which server the request came in and you need to request all the objects again each time, do not request unnecessary objects and takes care of the cache in memcache. I hope in the future Google will introduce a more convenient and flexible work with an instance of the application (inctance).

    Actionscript 3 for VIM fans


    I took several approaches to learning Flash, tried to read books, opened the Flash IDE, and every time I experienced some inexplicable rejection of all these buttons, windows, helpers. The Flash IDE is quite different from environments such as Eclipse or Visual Studio and requires careful study. The solution was simple. There is a Flex SDK, the mxmlc compiler, and with them the development is traditional. There is a plugin for VIM , and Actionscript 3 is a nice, modern, object-oriented programming language. If you are experiencing such problems, then maybe you should try this way.

    App Engine + Twisted



    The circuit to which I have just arrived is shown in the figure. Game mechanics is transferred to a separate Linux server, on which a daemon is launched, which accepts persistent connections from clients. To create a permanent connection on the client, Flash is used, and with a lack of Linux server power, the game is quite easy to scale. This is not a universal solution for all occasions and it assumes that you can separate game objects on different servers. In my case, the games take place in different "rooms" and these rooms can be located on different servers, everything inside the room is freely placed on one server.
    If you would make a super global game in which one hundred and five hundred thousand million people would play in one location, who would interact dynamically among themselves, then most likely the Channel API would be able to offer you a more flexible approach in this case.
    App Engine in my scheme has become a central authentication server and statistics server. When a client connects to Twisted, for authentication, Twisted makes a request to the App Engine and checks if this client is what it claims to be. Statistics is just a great area to use App Engine.

    Authentication Library



    For various authentication, I wrote a library whose class diagram is shown in the figure. End User (end user) applications are inherited from the User library, which in turn is connected through composition with various authentication schemes.
    All this happens on the App Engine server and for the Twisted server it doesn't matter where the client came from.

    Looking for companions


    Currently, I am having problems with design and marketing. If you understand one of these, you have free time, a desire to do something, but you don’t know who to join, I would be happy to share the delights of the creative process with you, just write me a personal message or email. The desire to find professionals in their field, the opportunity to someday create a strong development team, were some of the goals for which I wrote this article.

    References


    Game site In Cubes
    Application on Facebook
    Application In Contact
    Application in My World


    Also popular now: