Browser game server development ... as an academic discipline
In the middle of last summer, a letter arrived at the Mail.Ru Group client games department program mailing: “A competition has been announced for the position of a Java course teacher in our joint project with MGTU. N. E. Bauman. As a programmer and an employee of the department, I also received this letter. As a graduate of the Physicotechnical Institute, and in the past a teacher and scientist, decided to respond.
So for me, the history of work as a teacher in the Technopark began. Actually I want to tell you about it (about work, about Technopark, about my course and about students).
Demotivator on Java Course Discussion *
(*) The demotivator was made on the basis of the recording of the presentation of the “In-depth Java Programming” course at the “1 Year Technopark” speech and received the first place in the closed demotivators contest.
The task of the article
I will begin with a review of the topics and objectives of the article. I try to start all my lectures in this way. So, I will tell:
')
History of the course
I have responded to the mailing list. To invent and read a course on the topic of your main work is an opportunity to simultaneously gain teaching experience, learn more about a programming language, take a fresh look at yourself and your work, and, in addition, earn money. A couple of days later, I was written by the head of Technopark and offered to discuss the draft course.
I will not write here in detail about Technopark here - there is an excellent article by the head of Technopark Dmitry Voloshin.
The full title of the discipline course, which I had to read, was: "In-depth programming in Java." This is a semi-annual course for students who have successfully completed the first semester of study at the Technopark. By the beginning of the course, students should already have a basic knowledge of programming and little experience developing in any high-level language.
I had to prepare material for 9 lectures and 6 seminars (4 academic hours for each lesson). The course was supposed to be part of a general program for the preparation of web developers and system architects.
I was free to choose topics and materials, I could prepare any course corresponding to the title. The only prerequisite was the practical orientation of the course. That is, the students had to not only listen to the theoretical material, but also do a number of practical work - for example, solve problems similar to those that we solve ourselves.
As I already wrote, I am an employee of the client computer games development department. I participated in the work on the Allods Online project and now I work in the server team of the new project SkyForge. I write games. More precisely, I am writing to Java server part of an online game. I need to prepare a course for students that would be practically oriented to solving problems similar to my workers.
Having formulated my task in this way, I understood what course we needed. This should be a course in which students will write their game server to Java .
Is this a Java course? Yes. Is this a practical course? Yes. According to my work? Yes! Initial conditions are met. You can start developing a program.
I did the main work on preparing the course myself, but of course, I didn’t think on many questions alone. Describing the results of teamwork (discussions with management, colleagues, students) I will write “we”.
Course Development
I started working on the program. The first difficulty that immediately caught my eye was that the server was useless without a client. You can write a “divine server”, but if no one can turn to it, its value will be low and it will not be interesting to write it. Writing your client, especially in Java, had neither desire nor time. The decision, in general, was also striking. As a client, you can use the browser. And write a server for a browser game. For the architecture that I describe below, from the server’s point of view, there is no difference what client to use.
The second difficulty with the selection of materials was to find a balance: they should be enough to create a complete project, but not too much for the work to be completed in the allotted time. During the 4 months that the course lasts, students must complete work equivalent to developing small browser and / or social games. As far as I am familiar with this kind of development, the whole cycle of creating such games for a team of 3-4 people takes 1-2 months. But professionals are involved in the development (to a greater or lesser extent), and they work full-time. And the majority of students with whom I had to work, have no development experience (it does not matter in what language, it is important that there is no experience in creating projects). In addition, besides my course, they have 2 courses of Technopark and it is not yet known how many courses of MSTU are.
We decided that in order to achieve our goals we need to adhere to a number of rules.
As a result, the program includes the following topics:
More information on the Technopark program can be found here .
Let me remind you that the full name of the course is “In-depth Java Programming”. Therefore, I had the right to a sharp transition from the first lesson from Hello World to multithreading in the second lesson. In the annotation to the course, we wrote that for successful perception, students need familiarity with basic concepts in Java. What came out of this could be learned only in practice.
Requirements for students
Of the three words that make up the course name (“Java”, “programming” and “in-depth”), the word “in-depth” is the most ambiguous. If the course were called "Introduction to Java", it would be clear what to talk about. “In-depth” means that students are already familiar with programming - and not just in a high-level language, but specifically in Java programming. We decided that students should already know the following:
In the Technopark study second to fifth year students of various faculties of MSTU. They came to my course after the first semester. They were tested for motivation; everyone who did not have basic knowledge received basic knowledge. Among the students were those who already wrote in Java and earned money by it, and those who did not write anything before the course in Java.
As a result, some of the listeners at the first practical work wrote “Hello world” for the first time, while another part decided that it was not interesting to develop without template engines and HTTP sessions. Based on the results of the first two classes, I decided that it would be right not to limit the students, and allowed to use any libraries that they know. And by the middle of the course I allowed to write my Frontend part at all, that is, to organize the entire work of the server with the browser in the way they prefer. At the same time, those who had no previous experience in Java could continue to learn from my program. The use of additional knowledge did not affect the assessment.
Features of reading a course in Technopark
Technopark is voluntary. In the sense that we do not take tuition fees from students, do not sign any contracts and do not oblige to attend our classes - students should have an interest in attending lectures and seminars. This should be their own desire. So, the lessons themselves should be primarily interesting. If a student is interested in what is happening, he will also remember the material of the lecture and most likely will come to the next lesson. We decided that it was not enough to do not just a Java course, but a game development course. A lecture in our understanding should be a kind of show. First of all, this was reflected in the illustrations to the educational materials. Below are three examples of lectures:
Matryoshka-Batman - an illustration to the theme "Decorator Pattern in Java I / O",
Traversing the tree - an illustration of the topic “Working with XML Documents”
Wooks on the slide with a lot of code - so that the eye has something to rest on
In addition to the slides, to attract attention, it was very useful to ask the audience unexpected questions. For example, “Who remembers the distance from the Earth to the Moon? If we have a server with databases on the moon, what will be the minimum delay when writing to the database? ” Or "Who played Korean online games?" Can you explain the term WRC? "
The mention of names and play terms that students do not expect to hear at the university has a positive effect on perception.
Learning server architecture and practical work
Not everything that I wrote about the course before this can be clear from the point of view of teaching theory of the Java language. If we confine ourselves only to reading the lectures on the above program, the meaning of many of the questions being analyzed in the course will remain unclear. For example, why do we need multithreading at the second lecture, why load testing at the fifth, and why annotations are only at the end of the course? This oddity will be understandable if we consider the course on the part of homework and practical work.
I'll start with a description of the problem. The training server offered for development consists of 8 modules:
Details about each module:
You can compare the learning server architecture with the Allods server architecture. Borrowing is not complete, but it is obvious that we tried in every way to imitate them.
Now about the sequence in which we all wrote this. The work was divided into 6 workshops:
The seminars were very lively. My assistant and I ran between the students, answered a lot of questions of varying degrees of complexity. Students showed each other their decisions. We examined common to all problems and difficulties. Some of the questions were really interesting, and my desire to “learn something new about Java and myself in the process of teaching” was completely satisfied.
An approach in which a student from the state “did not write anything to Java” for a month goes into the state “wrote a web server that runs in 3 threads” may seem hard. However, as practice shows, it is he who works best.
First semester results
Most students have mastered the program proposed above. Problems with the perception of the material were in the third lecture, by the end of which we analyzed the interaction of flows through the messaging system. Now I have read the same lecture to the second stream of students. And now it seems to me that the problems were not so much with perception, as with my ability to explain the material. Repeating the course, as far as I can judge by the degree of glazing of the students' eyes, is much more productive.
In almost all the lectures, I showed my code and showed how it works. As a result, even if the student did not understand something at the lecture, he could look at it in the notes and copy complex sections of code. I did not distribute the source code of my code, and, as a result, even when borrowing the code from the lecture, this code had to be rewritten at least.
I consider as the main result of the first semester the opportunity proved by students to write a web-project in the allotted time according to the architecture proposed by me. To protect the server reached six groups of ten. Three groups of six approached the task creatively and, besides the implementation of all server modules, developed an interesting game mechanics.
And, of course, a survey of students after completion of the course:
Exam and tickets
The exam was passed only by those students who could not complete the practical work on time. We decided that they were theorists, and that they might be able to achieve recognition in the role of architects. To get an excellent grade, you had to answer 3 questions randomly taken from two identical sets of 49 questions each. The option in which the student will pull out two identical questions, we did not discard. In this case, he had to answer the same question twice. True, there were no such lucky ones at the exam.
For a complete picture of the course I provide a list of questions:
Conclusion
In conclusion, I want to note that we continue to work on the course. With each reading, the structure of the course becomes more logical, and the material itself becomes more understandable. Future plans are to make the course even more practice-oriented, to include in the mandatory program the use of template engines for creating pages and the practice of deploying the product on the server. But I will write about this later, when there is enough new material.
Thanks
In the work on the article and the course helped me:
Alexander Akbashev - QA server of the SkyForge project, a graduate student at MSTU and my assistant at Technopark.
Dmitry Voloshin - Director of Research and Education Mail.Ru Group.
Sergey Zagursky - the head of the SkyForge project server team.
Timur Bukharaev is the head of the web-team of the SkyForge project.
So for me, the history of work as a teacher in the Technopark began. Actually I want to tell you about it (about work, about Technopark, about my course and about students).
Demotivator on Java Course Discussion *
(*) The demotivator was made on the basis of the recording of the presentation of the “In-depth Java Programming” course at the “1 Year Technopark” speech and received the first place in the closed demotivators contest.
The task of the article
I will begin with a review of the topics and objectives of the article. I try to start all my lectures in this way. So, I will tell:
- about the history of the course and the selection of training topics and materials
- about the requirements for course participants and their real compliance with these requirements
- about the features of lecturing and conducting seminars in the Technopark
- about the architecture of the educational project and practical work
- about the results of the first semester
- on practical work protection, exam and ticket
')
History of the course
I have responded to the mailing list. To invent and read a course on the topic of your main work is an opportunity to simultaneously gain teaching experience, learn more about a programming language, take a fresh look at yourself and your work, and, in addition, earn money. A couple of days later, I was written by the head of Technopark and offered to discuss the draft course.
I will not write here in detail about Technopark here - there is an excellent article by the head of Technopark Dmitry Voloshin.
The full title of the discipline course, which I had to read, was: "In-depth programming in Java." This is a semi-annual course for students who have successfully completed the first semester of study at the Technopark. By the beginning of the course, students should already have a basic knowledge of programming and little experience developing in any high-level language.
I had to prepare material for 9 lectures and 6 seminars (4 academic hours for each lesson). The course was supposed to be part of a general program for the preparation of web developers and system architects.
I was free to choose topics and materials, I could prepare any course corresponding to the title. The only prerequisite was the practical orientation of the course. That is, the students had to not only listen to the theoretical material, but also do a number of practical work - for example, solve problems similar to those that we solve ourselves.
As I already wrote, I am an employee of the client computer games development department. I participated in the work on the Allods Online project and now I work in the server team of the new project SkyForge. I write games. More precisely, I am writing to Java server part of an online game. I need to prepare a course for students that would be practically oriented to solving problems similar to my workers.
Having formulated my task in this way, I understood what course we needed. This should be a course in which students will write their game server to Java .
Is this a Java course? Yes. Is this a practical course? Yes. According to my work? Yes! Initial conditions are met. You can start developing a program.
I did the main work on preparing the course myself, but of course, I didn’t think on many questions alone. Describing the results of teamwork (discussions with management, colleagues, students) I will write “we”.
Course Development
I started working on the program. The first difficulty that immediately caught my eye was that the server was useless without a client. You can write a “divine server”, but if no one can turn to it, its value will be low and it will not be interesting to write it. Writing your client, especially in Java, had neither desire nor time. The decision, in general, was also striking. As a client, you can use the browser. And write a server for a browser game. For the architecture that I describe below, from the server’s point of view, there is no difference what client to use.
The second difficulty with the selection of materials was to find a balance: they should be enough to create a complete project, but not too much for the work to be completed in the allotted time. During the 4 months that the course lasts, students must complete work equivalent to developing small browser and / or social games. As far as I am familiar with this kind of development, the whole cycle of creating such games for a team of 3-4 people takes 1-2 months. But professionals are involved in the development (to a greater or lesser extent), and they work full-time. And the majority of students with whom I had to work, have no development experience (it does not matter in what language, it is important that there is no experience in creating projects). In addition, besides my course, they have 2 courses of Technopark and it is not yet known how many courses of MSTU are.
We decided that in order to achieve our goals we need to adhere to a number of rules.
- All practical code development tasks should be put together in one project. Not a single line of code should be written just for training.
- For tasks not directly related to the course, we use third-party libraries.
- Students combine in groups of 3-4 people. One group is developing one project. Assessment for the practical work gets the whole group.
As a result, the program includes the following topics:
- History and features of the Java language. Java platform. Java editions. Garbage collector. Comparing Java and C ++. Inheritance in Java. Keywords: interface, class, enum, extends, implements.
- class Object and class Class <?>. Classes "wrappers" of simple types. Generics. Typification. Iterator and Iterable. Browse Java collections. Class Collections. Multithreading Processes and Threads. Interface runnable. class thread. sleep (), interrupt (), join (). Threads from the point of view of the processor. Interrupt. Java memory model. Volatile. Critical sections. Synchronization. Mutexes Semaphores Monitor. Problems of multithreaded data access. Atomic Variables. Deadlock. wait () and notify ().
- A description of the thread interaction problem. The task is the interaction of the Frontend and AccountService streams. Advantages of solving the problem through two streams. Methods of interaction between threads. Concurrent collections. The main idea of the interaction of threads through messages. MessageSystem - an object for data exchange. Address and Abonent. Analogy with the mail. Message - the message inheritance hierarchy. Addressservice.
- Code organization. The problem of cyclic dependencies. The solution of cyclic dependencies through interfaces. Server architecture Analysis of server modules and their interaction. Game mechanics. Diagram of interaction between game mechanics and frontend modules. Replication Examples of game mechanics.
- Types of testing. Unit testing. Functional testing. Stress Testing. Practice Testing. Junit Selenium. Analyzed parameters. GC. Types of GC. GC options. The principal device GC.
- Singleton and Context. Events, subscription to events. Callback. Anonymous classes. Random. Work with time and date. Unix time. Locale. Subscription on time. I / O Streams. Stream bytes and streams of characters. Thread inheritance tree File streams. Security closure threads. File. Vfs. Code examples.
- Serialization / deserialization. Interface Serializable, transient fields, serialVersionUID. Reflection. The role of reflection in serialization. Class <T>. Field, Method, Constructor. ReflectionHelper example. Factory method pattern. SAX and DOM parsers. Recovering an object from an XML file. Resources. Use ReflectionHelper to deserialize resources. The role of resources in the game server. ResourceFactory.
- Template work with the base. DataSet, DAO, Manager, Executor. JDBC API. Database driver. Connection Statement. Resultset. Executing SQL statement. Module for working with the database. Dependency Injection.
- Annotation. Object Relational Mapping. Hibernate.
More information on the Technopark program can be found here .
Let me remind you that the full name of the course is “In-depth Java Programming”. Therefore, I had the right to a sharp transition from the first lesson from Hello World to multithreading in the second lesson. In the annotation to the course, we wrote that for successful perception, students need familiarity with basic concepts in Java. What came out of this could be learned only in practice.
Requirements for students
Of the three words that make up the course name (“Java”, “programming” and “in-depth”), the word “in-depth” is the most ambiguous. If the course were called "Introduction to Java", it would be clear what to talk about. “In-depth” means that students are already familiar with programming - and not just in a high-level language, but specifically in Java programming. We decided that students should already know the following:
- primitive types, overflow
- objects, classes, inheritance, encapsulation, polymorphism
- variable scope, static variables
- branching and cycles
- primitive type conversions
- interfaces, interface implementation
- statements, the order of execution of statements
- stack pile
- visibility modifiers (private, protected, public)
In the Technopark study second to fifth year students of various faculties of MSTU. They came to my course after the first semester. They were tested for motivation; everyone who did not have basic knowledge received basic knowledge. Among the students were those who already wrote in Java and earned money by it, and those who did not write anything before the course in Java.
As a result, some of the listeners at the first practical work wrote “Hello world” for the first time, while another part decided that it was not interesting to develop without template engines and HTTP sessions. Based on the results of the first two classes, I decided that it would be right not to limit the students, and allowed to use any libraries that they know. And by the middle of the course I allowed to write my Frontend part at all, that is, to organize the entire work of the server with the browser in the way they prefer. At the same time, those who had no previous experience in Java could continue to learn from my program. The use of additional knowledge did not affect the assessment.
Features of reading a course in Technopark
Technopark is voluntary. In the sense that we do not take tuition fees from students, do not sign any contracts and do not oblige to attend our classes - students should have an interest in attending lectures and seminars. This should be their own desire. So, the lessons themselves should be primarily interesting. If a student is interested in what is happening, he will also remember the material of the lecture and most likely will come to the next lesson. We decided that it was not enough to do not just a Java course, but a game development course. A lecture in our understanding should be a kind of show. First of all, this was reflected in the illustrations to the educational materials. Below are three examples of lectures:
Matryoshka-Batman - an illustration to the theme "Decorator Pattern in Java I / O",
Traversing the tree - an illustration of the topic “Working with XML Documents”
Wooks on the slide with a lot of code - so that the eye has something to rest on
In addition to the slides, to attract attention, it was very useful to ask the audience unexpected questions. For example, “Who remembers the distance from the Earth to the Moon? If we have a server with databases on the moon, what will be the minimum delay when writing to the database? ” Or "Who played Korean online games?" Can you explain the term WRC? "
The mention of names and play terms that students do not expect to hear at the university has a positive effect on perception.
Learning server architecture and practical work
Not everything that I wrote about the course before this can be clear from the point of view of teaching theory of the Java language. If we confine ourselves only to reading the lectures on the above program, the meaning of many of the questions being analyzed in the course will remain unclear. For example, why do we need multithreading at the second lecture, why load testing at the fifth, and why annotations are only at the end of the course? This oddity will be understandable if we consider the course on the part of homework and practical work.
I'll start with a description of the problem. The training server offered for development consists of 8 modules:
Details about each module:
- main - depends on all other modules. Contains the main () function. Creates all the other modules at the time of starting the server. Runs frontend, dbService and gameMechanics in separate threads. Initializes the Jetty library, sends a link to the frontend to the Jetty.
- Frontend is both a handler for Jetty events (the user sends a request to Jetty through the browser, Jetty calls the handle from Frontend), and a service that lives in its own thread. Frontend stores only those data about users that are needed to create the page and send it back to the browser. All calculations occur in the gameMechanics stream. The task of the frontend is to accept the request from the user, transfer it to the necessary service and give the user a page (in asynchronous mode).
- dbService - server connection service with database. Lives in a separate thread, keeps the connection to the base. Handles requests from other modules and returns them answers. dbSerivice can be several, each in its own stream.
- gameMechanics is a server service in which all game events take place. The game world lives in this stream. For all other services it is just a black box. Different games written by students should differ only in game mechanics. Game mechanics cheat all events and sends a replica to the Frontend.
- messageSystem is a common object for all threads through which data is exchanged between threads. Contains one message queue for each thread. Those who wish to access another thread must put a special object in the appropriate queue - a message. The recipient will take this message out of the queue and process it at a convenient time. The result of processing may be sending a response message.
- resourceSustem - singleton, which allows all services to access files with server operation parameters (resources). Read more about the resources here .
- Utilities - a set of services and helpers for working with time, random numbers and logs.
- base - a set of interfaces and base classes for all services.
You can compare the learning server architecture with the Allods server architecture. Borrowing is not complete, but it is obvious that we tried in every way to imitate them.
Now about the sequence in which we all wrote this. The work was divided into 6 workshops:
- Hello World, Eclipse Meet, Jetty. Run a web server on localhost: 8080, which returns a page with “Hello Server!”. Memorizing the user either through Jetty sessions or through hidden fields on the form. Creating a page that queries itself once every T milliseconds.
- Run Frontend in a separate thread. Counting from this stream the number of hits that came to the server from the user. Run in a separate thread of the dbService prototype (which is not currently accessing the database, but only simulates cache access in memory). Writing a messageSystem for the interaction of these threads through messages.
- Getting started on game mechanics. Students decide what game they will write, and begin to develop logic. Creating a gameMechanics module in a separate thread, forwarding messages from Frontend to mechanics and back. Testing already written modules. Development of unit-tests and functional tests.
- Creation of tools for working with time and random numbers (if they are needed for mechanics). Creating a module for working with the file system. Transfer all parameters from server code to files (resources).
- Work with databases. The transformation of a "fake" dbService in the present.
- Shut down and protect the server.
The seminars were very lively. My assistant and I ran between the students, answered a lot of questions of varying degrees of complexity. Students showed each other their decisions. We examined common to all problems and difficulties. Some of the questions were really interesting, and my desire to “learn something new about Java and myself in the process of teaching” was completely satisfied.
An approach in which a student from the state “did not write anything to Java” for a month goes into the state “wrote a web server that runs in 3 threads” may seem hard. However, as practice shows, it is he who works best.
First semester results
Most students have mastered the program proposed above. Problems with the perception of the material were in the third lecture, by the end of which we analyzed the interaction of flows through the messaging system. Now I have read the same lecture to the second stream of students. And now it seems to me that the problems were not so much with perception, as with my ability to explain the material. Repeating the course, as far as I can judge by the degree of glazing of the students' eyes, is much more productive.
In almost all the lectures, I showed my code and showed how it works. As a result, even if the student did not understand something at the lecture, he could look at it in the notes and copy complex sections of code. I did not distribute the source code of my code, and, as a result, even when borrowing the code from the lecture, this code had to be rewritten at least.
I consider as the main result of the first semester the opportunity proved by students to write a web-project in the allotted time according to the architecture proposed by me. To protect the server reached six groups of ten. Three groups of six approached the task creatively and, besides the implementation of all server modules, developed an interesting game mechanics.
And, of course, a survey of students after completion of the course:
Exam and tickets
The exam was passed only by those students who could not complete the practical work on time. We decided that they were theorists, and that they might be able to achieve recognition in the role of architects. To get an excellent grade, you had to answer 3 questions randomly taken from two identical sets of 49 questions each. The option in which the student will pull out two identical questions, we did not discard. In this case, he had to answer the same question twice. True, there were no such lucky ones at the exam.
For a complete picture of the course I provide a list of questions:
- History and features of the Java language.
- Java platform. Java Editions. GC, JVM, JDK, JRE. Bytecode.
- Rules for naming packages, classes, variables and methods. Running Java Applications
- class Object and class Class <?>. The main methods of these classes.
- Simple types in Java. Classes "wrappers" of simple types.
- Generic programming in Java. Create your own template classes and methods.
- Java collections. Iterator, Iterable.
- Processes and Threads.
- Interface runnable. class thread. Methods start () and run ().
- Thread class methods: sleep (), interrupt (), join ().
- Keywords volatile and synchronized. Synchronized methods and expressions.
- Problems of multithreaded data access. Race condition. Deadlock.
- The Object class methods are: wait (), notify (), and notifyAll ().
- Pros and cons of multi-threaded applications.
- Methods of interaction between threads.
- java.util.concurrent.
- MessageSystem. Address and Abonent.
- Distribution of classes by packages. Cyclic dependencies between packages.
- Game server architecture. Module dependency diagram.
- The process of the game server replication.
- Types of testing.
- GC. Types of GC. GC options.
- Work with random numbers.
- Design patterns: Singleton and Context.
- Events. Subscribe to events.
- Transfer functions to the library. Callback.
- Anonymous classes.
- Work with time and date. Unix time. Locale.
- I / O Streams. Byte streams and character streams.
- Exceptions: Throwable, Error, Exception, try, catch, finally.
- Serialization / deserialization. Interface Serializable.
- Keyword transient. Reasons for using transient when serializing.
- Reflection. The role of reflection in serialization.
- Factory design pattern.
- SAX parser.
- DOM parser.
- Server resource system.
- JDBC API.
- class Connection from the JDBC API. Tasks that Connection solves.
- Dependency Injection. Use when working with databases.
- class Statement from the JDBC API. Tasks solved by Statement.
- class ResultSet from the JDBC API. Handling the response from the database.
- DataSet (ORM element).
- DAO (ORM element).
- Annotation. Use of annotations. Create your own annotations.
- Object Relational Mapping.
- Frontend - role in the server.
- Game Mechanics - role in the server.
- Database Service - a role in the server.
Conclusion
In conclusion, I want to note that we continue to work on the course. With each reading, the structure of the course becomes more logical, and the material itself becomes more understandable. Future plans are to make the course even more practice-oriented, to include in the mandatory program the use of template engines for creating pages and the practice of deploying the product on the server. But I will write about this later, when there is enough new material.
Thanks
In the work on the article and the course helped me:
Alexander Akbashev - QA server of the SkyForge project, a graduate student at MSTU and my assistant at Technopark.
Dmitry Voloshin - Director of Research and Education Mail.Ru Group.
Sergey Zagursky - the head of the SkyForge project server team.
Timur Bukharaev is the head of the web-team of the SkyForge project.
Source: https://habr.com/ru/post/177953/
All Articles