Marauroa is Arianne's Multiplayer Online Engine, which you can use to build your own online games. Marauroa handles object management, asynchronous database persistence and perception based client-server communication.
What is Marauroa?Marauroa is completely written in Java using a multithreaded server architecture with a TCP oriented network protocol, a MySQL or H2 based persistence engine and a flexible game system based on open systems totally expandible and modifiable by developers. Game rules can be written in Java, and Python scripts could be supported with a little work. Marauroa is based on a philosophy we call Action/Perception, on each turn a perception is sent to clients explaining them what they percieve and clients can ask server to do any action in their names using actions. Marauroa is totally game agnostic and makes very little assumptions about what are you trying to do, allowing a great freedom to create whatever type of game you want.
FeaturesMarauroa features state-of-art technologies as:
- Java 1.5 and higher compatible
- Persistent objects
- Transactional relational database support
- Asynchronous database access
- Delta and Delta2 Perceptions to reduce bandwidth usage
- Multiple independent zones of gameplay
- Server content streaming
- Turn based or real time gameplay
- Nicely documented: Design and specifications available
- Based on a XP development model
- Follows KISS principle: Keep it simply stupid
- True Open Source Software: GNU/GPL
Marauroa is based on very simple principles:
- Clients communicate with the server, and vice-versa, using a TCP portable network protocol with reliability in mind to allow a stabler experience when online game lag occurs.
- To play a game every player needs an account on the server that is identified by an username and a password.
- Players use their account to login into the server and then choose a 'player' stored under their account to play with. The server then checks the login information using the MySQL backend and loads the player into the game using the persistence engine.
- Players send actions to the server. The action system is totally open and has nothing hard-coded so you can edit it totally to your game style. The server sends at regular intervals, called turns, a perception to each player to inform them about the state of the game and any relevant state modifications. Marauroa's perception system is based on the Delta^2 ideology: simply send what has changed.
- The server executes some code each turn in order to move the game status on. Using this hook it is simple to code triggers, timeouts, conditions and whatever kind of behavior you need.
- The server transparently and automatically stores players and game status modifications on the persistence engine, and also information decided by the game developer using their game definition scripts.
- Game rules can be coded in Java to allow simple and rapid development and without having to know anything about Marauroa's internals.
- Python scripts for the game rules could be supported with a little work.
- The server generates statistics of usage which are stored in a MySQL or H2 database (so you can later generate fancy statistics from them). Or in case you don't require them, they can be disabled to save CPU cycles and disk space. Marauroa features a modular structure that means modules can be changed and disabled without affecting the operation of other modules.
- Both the server and clients are fully and wisely documented, with documentation about specification and design and not just API documentation.
- Security update (thanks to pepzs for the report)
- Marauroa failed to verify username on client transfer
- fixed a race condition allowing double login which may result in item duplication (thanks to pepsz for the report)
- added support for HTML clients
- smaller features
- database indexes are created automatically on database creation or update
- added data type long
- support character creation while in game
- added multilanguage support (en, de, pl, uk)
- initial status of account and characters can be configured in server.ini
- converted CVS to Git
- junit tests use in memory database
- various performance and memory usage improvements
- fixed compiler warnings and improved code comments
- code cleanup and refactorings
- skipped version number
- retry database command on connection loss to the database server
- marauroa can invoke an external command (email_command in server.ini) with the token and email-address on account creation
- use a dedicated email table
- workaround for IllegalArgumentException in proxy check (see http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1055 )
- added support for Sha512Crypt with salt and pepper
- fixed cacheable flag being ignored (e.g. map content may be cached)
- failed logins are now logged with distinct status values
- client support for skippable empty perceptions
- ban messages are no longer restricted 256, if both server and client use the new protocol version 34
- added RPClass support (type checks and transfer compression) to RPAction
- content transfer includes a md5 hash of the content, if both server and client use the new protocol version 34
- fixed a bug which caused the server to use the client protocol version in its messages, even if it was higher than the version supported by the server
- automatically try to use a configured SOCKS-proxy. If it cannot be used, Marauroa falls back to direct connections
- RPRuleProcessorImpl provides a default implementation for IRPRuleProcessor
- new server.ini variable server_abuseContact to add a sentence with contact information to the ban dialog.
- use ENGINE instead of TYPE on table creation to be compatible with MySQL 5.5
- performance improvement by not deep copying all player objects every turn.
- performance improvement by skipping RPObject.id validation during cloning of RPSlots
- performance improvement by removing redundant calls to Attribute.has() and RPObject.getID()
- increased client side timeout while the server is processing the login (may do slow database queries)
- defined better indices for loginEvent designed to answer the number of recently failed logins question fast
- performance optimization in RPObject.getDifference() by drastically reducing the number of RPobject instantiations
- performance optimization in RPObject to create internal list/map objects only on demand
- build script now creates an additional minized jar file for clients: marauroa-client-only.jar
- improved messages on errors in server.ini
- fixed an issue on account renaming
- fixed an issue with special characters in character names
- zones are now stored asynchronously to the database
- fixed a co-modification issue in Attributes.clone() and Statistics.clone()
- fixed "Replacing content to transfer"
- added configurations parameters allow_account_creation and allow_character_creation
- added new Result.FAILED_CREATE_ON_MAIN_INSTEAD of account/character if it was disabled
- fixed bogus error message about accessing available transactions on closing the TransactionPool
- security fix preventing multiple logins of the same character on MySQL
- increased visibility of RPSlot.getOwner() to protected
- always call rewriteSql
- speed up first connection time on servers with low entropy
- increased visibility of RPSlot.add(RPObject object, boolean assignId) to protected
- add method to check the length of a column during database update
- added new Result.FAILED_OFFLINE of account/character creation to be used when the server is not reachable 3.8.1
- added new method ClientFrameWork.sendKeepAlive for keeping the connection open more than 10 minutes in the character selection state pre game
- added new method DBCommandQueue.getOneResult
- database: added id and status to characters table
- fixed an issue if a client with version 32 and a client with version 32 are in the same zone
- attributes of type map
- multi protocol version support for client server communication (from version 31 to 40)
- multi protocol version support for database storage
- added ability to RPClass.bake() the RPClass to speed up performance.
- logins are now processed asynchronously to speed up performance
- only count clients that are in game in the statistics (not the ones waiting to connect or waiting to logout)