RedDwarf - server platform for developing online games in Java
Good day!
For the last two years I have been developing a game server on the RedDwarf platform - a free (GPLv2) server platform for creating online Java games. Habré has very little information about this platform, so I decided to correct this shortcoming.
The development of this engine was originally carried out by Sun, the platform itself was called the Sun Game Server (the abbreviation sgs is still used in the package names). In 2005, the server was introduced to the world under the name Project Darkstar. After Oracle bought Sun, the projectors refused to support the project, the platform was renamed RedDwarf Server and now exists only with the support of the community. The project is developing now much slower, but still developing - last year version 0.10.2 was released. There are still no planned chips (transparent scaling) in it, but as a basis for the game server it is used in many projects .
The game server on the RedDwarf platform consists of the following parts.
The internal database is a high-performance embedded database (used by BerkleyDB), which is used to store service and game data during the game. This database stores all game objects, game and internal tasks and events. With the help of the database, transactional execution of tasks is realized. This allows you to run it from the same place where it was stopped: the game will continue as if nothing had happened.
')
The RedDwarf core includes all worries about working with the BerkleyDB database, with the network, connecting and disconnecting users, planning deferred and periodic tasks.
Extensions are easy-to-connect plugins that enable the use of functionality not included in the kernel. There are extensions for profiling, working with an external database (SQL), working with HTTP-services.
The game application is written by the developers of the game in the Java language. The game application uses the API provided by the kernel and extensions. RedDwarf imposes some restrictions on the gaming application: tasks should be short, not do input / output directly, not create their own threads, but use the task mechanism.
Any game (or internal) event is a task. Tasks are serialized, written to the database, and then, if possible, read and execute. At the beginning of each task, an internal database transaction is opened, after the task is completed, the transaction is committed. If an unhandled exception occurred during the execution of the task, or the task was executed for more than 100ms (by default), the transaction is rolled back.
In this regard, another interesting point: if there is a transaction conflict (that is, the same game object has been changed in parallel in different tasks), then the transaction is rolled back and the task is executed again. Because of this, the program is written as single-threaded - even the use of synchronized and blocking collections is prohibited (they can lead to deadlocks).
Storing tasks in a database provides unique opportunities.
The first is the ability to safely resume the server after it stops or crashes. However, in practice there were cases when the server crash was caused by an avalanche-like multiplication of tasks (due to an error in the code) - and then to restore the server’s work, one had to either shamanize a lot or delete the entire database.
The second unique possibility is to create transparent scaling - serialized tasks are easily transferred between the individual nodes of the server cluster, and are performed where possible. Unfortunately, this scaling is not yet fully implemented and cannot be applied in practice yet.
The platform implements a convenient sheduler that allows you to plan one-time, pending and periodic tasks and cancel them.
It is possible to monitor the status of the server and administration using JMX.
In order to provide transactivity and allow programmers to (almost) not think about multithreading, all game objects must implement the ManagedObject interface. Work with such objects can only be carried out within the framework of transactions (that is, you cannot simply start your own separate stream and work with such objects in it). The link to such an object should not be stored explicitly, but inside a special object - a ManagedReference. The need to dereference of such links is slightly annoying, but remembering that it eliminates the fuss with locks, you quickly get used to it.
A great opportunity for game developers under Reddwarf is the message channels. A channel can have a large number of subscribers, and when a message is posted to a channel, it is delivered to all recipients. The implementation of the channels is such that this mechanism works much faster than bypassing all the subscribers in the loop and sending a message to each of them.
For RedDwarf, there are many libraries for writing the client part in various programming languages. Platform developers support Java and C client libraries. There are also libraries for ActionScript, Objective-C, C #, Python .
Since much has already been implemented in the platform itself, to get the game, programmers need to do the following:
As a result, Reddwarf is a good platform for developing online game servers: it frees the programmer from worries about multithreading, provides a convenient API for working with the internal database, with tasks and the network.
In the next article I wrote how to write my first application under RedDwarf .
Official site of the project
Reddwarf FAQ
Architecture Presentation
For the last two years I have been developing a game server on the RedDwarf platform - a free (GPLv2) server platform for creating online Java games. Habré has very little information about this platform, so I decided to correct this shortcoming.Story
The development of this engine was originally carried out by Sun, the platform itself was called the Sun Game Server (the abbreviation sgs is still used in the package names). In 2005, the server was introduced to the world under the name Project Darkstar. After Oracle bought Sun, the projectors refused to support the project, the platform was renamed RedDwarf Server and now exists only with the support of the community. The project is developing now much slower, but still developing - last year version 0.10.2 was released. There are still no planned chips (transparent scaling) in it, but as a basis for the game server it is used in many projects .
Basic principles
The game server on the RedDwarf platform consists of the following parts.
- Game application
- Extensions
- Core
- Internal DB
The internal database is a high-performance embedded database (used by BerkleyDB), which is used to store service and game data during the game. This database stores all game objects, game and internal tasks and events. With the help of the database, transactional execution of tasks is realized. This allows you to run it from the same place where it was stopped: the game will continue as if nothing had happened.
')
The RedDwarf core includes all worries about working with the BerkleyDB database, with the network, connecting and disconnecting users, planning deferred and periodic tasks.
Extensions are easy-to-connect plugins that enable the use of functionality not included in the kernel. There are extensions for profiling, working with an external database (SQL), working with HTTP-services.
The game application is written by the developers of the game in the Java language. The game application uses the API provided by the kernel and extensions. RedDwarf imposes some restrictions on the gaming application: tasks should be short, not do input / output directly, not create their own threads, but use the task mechanism.
Tasks
Any game (or internal) event is a task. Tasks are serialized, written to the database, and then, if possible, read and execute. At the beginning of each task, an internal database transaction is opened, after the task is completed, the transaction is committed. If an unhandled exception occurred during the execution of the task, or the task was executed for more than 100ms (by default), the transaction is rolled back.
In this regard, another interesting point: if there is a transaction conflict (that is, the same game object has been changed in parallel in different tasks), then the transaction is rolled back and the task is executed again. Because of this, the program is written as single-threaded - even the use of synchronized and blocking collections is prohibited (they can lead to deadlocks).
Storing tasks in a database provides unique opportunities.
The first is the ability to safely resume the server after it stops or crashes. However, in practice there were cases when the server crash was caused by an avalanche-like multiplication of tasks (due to an error in the code) - and then to restore the server’s work, one had to either shamanize a lot or delete the entire database.
The second unique possibility is to create transparent scaling - serialized tasks are easily transferred between the individual nodes of the server cluster, and are performed where possible. Unfortunately, this scaling is not yet fully implemented and cannot be applied in practice yet.
The platform implements a convenient sheduler that allows you to plan one-time, pending and periodic tasks and cancel them.
It is possible to monitor the status of the server and administration using JMX.
Managed objects
In order to provide transactivity and allow programmers to (almost) not think about multithreading, all game objects must implement the ManagedObject interface. Work with such objects can only be carried out within the framework of transactions (that is, you cannot simply start your own separate stream and work with such objects in it). The link to such an object should not be stored explicitly, but inside a special object - a ManagedReference. The need to dereference of such links is slightly annoying, but remembering that it eliminates the fuss with locks, you quickly get used to it.
Channels for bulk message delivery
A great opportunity for game developers under Reddwarf is the message channels. A channel can have a large number of subscribers, and when a message is posted to a channel, it is delivered to all recipients. The implementation of the channels is such that this mechanism works much faster than bypassing all the subscribers in the loop and sending a message to each of them.
Client part
For RedDwarf, there are many libraries for writing the client part in various programming languages. Platform developers support Java and C client libraries. There are also libraries for ActionScript, Objective-C, C #, Python .
What is required from the game developer
Since much has already been implemented in the platform itself, to get the game, programmers need to do the following:
- Create game entities and connections between them.
- Implement game data storage (either in the built-in database or using extensions in the external one).
- Develop a server and client communication protocol (there is almost no tool in RedDwarf itself).
- Program the game logic, the server's reaction to the client's actions.
Conclusion
As a result, Reddwarf is a good platform for developing online game servers: it frees the programmer from worries about multithreading, provides a convenient API for working with the internal database, with tasks and the network.
In the next article I wrote how to write my first application under RedDwarf .
Literature
Official site of the project
Reddwarf FAQ
Architecture Presentation
Source: https://habr.com/ru/post/129174/
All Articles