For Geeks

Open Source Code

Kaya.gs now has an open project in Github where parts and bits are open-source. Check it out here. You are welcome to contribute, help, assist, tweak, improve and suggest.

Architecture

Kaya.gs is built from scratch with two important concepts in mind. Those are flexibility and scalability.

It is also important to leverage the developing-able community to expand the server features.

Up to now, almost all servers are done single-handedly by its owners which is limiting as there are many web-developers that would like to expand with rich and innovative features. IGS had great lone developers that expanded the server with great clients.

Scalability

Scalability is about having an architecture that will allow thousands of concurrent online players in a single shared space. It is important to know how Asian servers have the limitation of servers with 3000 players at a time. Being able to have the whole gaming community in a single space vastly improves the speed to get games and to find the best ones being played at any time. This poses a challenge, as having so many concurrent users is a drain on server resources, from bandwith to processing.

1st of all, Kaya.gs has a client as any other desktop-class applications. This client is delivered by the browser with Javascript. All processing that can be put on that side of the application without compromising security is moved, releasing the server from as much processing costs required.

2nd is about the drain of networking resources. Kaya.gs uses Websockets to form the client-server communication, which is the most efficient way to have a fast client-server communication. Below the hood Kaya.gs uses Socket.io, an Open Source Javascript Library designed for online communcational concurrency & gaming, in combination with a Redis DB.

3rd is about how efficiently the server is done. The server uses Ruby, a scripting language that might be famous through its use in Twitter. However because of its performance limits, we avoided the use of a Heavy Framework such as Rails, and even Sinatra. Instead we are using Cuba, a micro-framework with some functionality over Rack . This makes the server a very lean and efficient machine, able to handle a much larger number of requests. Cuba benchmarks have shown that it processes requests over 10 times faster than Rails. The server itself will be most likely be deployed on nginx.

4th is about how the server resources can expand themselves in case the server has a high number of users. Its deployment will be in the Amazon Cloud, with a structure that will add servers with load balancing as it is required. This strategy allows us to cut server costs by having the minimum amount of servers needed at any point in time.

Flexibility

At Kaya.gs we know that we dont know what is going to happen. There is a huge amount of features that will go to the server we havent thought of yet. Not ourselves, and not the community. On one hand, we want the server to be able to have any feature current servers have, plus any other feature that is feasible to develop. On one hand, the server will have a RESTful API so other services can consume them. This API is about letting other sites and applications get particular and useful information from the server to bond and expand itself.

An example: a tournament organizing site would like to organize games on a server. By consuming the Kaya.gs API, it can schedule matches and make sure that players play it. The server can report back the results, and compute if the players have played it or if there was a walk over. This is actually one of the first community able services that will be out there that is not directly developed by Kaya.gs, and anyone with an account on Kaya.gs can organize a tournament, without having to go through bureaucracy!

Besides the API, the site overall will have a Widget-based interface. That is that the components you see on the site do not relate to each other at all, but relate to server information. This comfortable practice allows us to add or remove widgets easily, knowing that no other part of the application is affected. Both the widget part of the application and what will be the board-client will most likely be open-sourced at a later stage in the project, once they are tested, secure and stable. The community will be able to make its own widgets, which once approved users in the server can add or remove for their daily use.

This allows the server on its final stage to be able to do almost anything, for people in the community to enrich Kaya.gs in almost any way they want, and to create a high quality Go server, surpassing by far the development power of Asian Go servers.

Other

We use HostedRedmine to manage our project internally. We are very grateful for their free hosting of redmine that allows us to manage our project without any cost.