A microservices based distributed 2d MMORPG with Hazelcast and Vert.x on Java 11, currently 20k LOC + configuration.
Sample in-game image of a simple test world, first demo video now available!
Uses Pixi.js for rendering and assets from gamedeveloperstudio, see license. This repository doesn't contain any client code or assets - as these may not be included in any open source listing. Contributions are welcome for the backend but only the core team may work on the client/assets.
If you are a part of the team please include the client prototype submodule.
# cloning the repository: git clone --recursive <repository-url> # if already cloned: git submodule update --init --recursive
- Requires Polymer-cli.
- Requires Bower.
Builds the project and runs all tests.
Create the distribution zip and run polymer build with:
To run the project without having to build a zip and perform polymer builds:
./gradlew prototype -Pexec=--generate ./gradlew prototype -Pexec=--deploy
Building a docker image, make sure to build the distribution zip first.
docker build -f Dockerfile ./build docker run -p 443:443 -p 1443:1443 -p 9301:9301 -it <imageId>
This is a 2D MMORPG that is in development, we are currently working on getting the core mechanics in place before we consider any gameplay/story. We're also trying to keep the development workflow as fast as possible in order to scale. Some examples include map designer, dialog designer, npc designer, reloadable scripts and fast startup times - 5s to start the current prototype with gradle and 2s to start it fully from a distribution on Java 11.
- ease of development: simple event passing and handler-based server development.
- fast feedback loop: fast startup times, fast client load times, unit-testable.
- simple and extendable: scripted events, yaml-based npc/item/spell/affliction configurations.
Overview of mechanics completed and TBD
- player chat
- spell engine (cooldown, learned spells, charges)
- dialog engine
- affliction engine
- cross realm/instance chat
- friend lists
- instance travel
- instance loading
- dynamically deployed instances
- scripted npcs/entities
- support for animations
- spawn entities/npcs from script
- NPC initiated dialogs
- NPC/interaction dialogs
- character status
- chat box
- creature targeting
- quest tracker
- in-game help
- sound effects
- spell effects
- patch notes
- realm list
- character creation
- character viewer
- auction client
- Game developers seeking to implement a 2D RPG multiplayer game.
- Aspiring game developers with an interest in backend development.
- Players who are into simplistic 2D MMORPG's.
To make this project a reality we use only great software.
On the backend
- CQEngine primary persistence store.
- Hazelcast for cluster discovery.
- Vert.x for threading and transports.
- chili-core for maximum ease of development.
On the frontend
Do you have an idea for a spell? a new player class? an NPC? gameplay mechanics? story? anything really, we are open 24/7 for contributions. Just submit an issue or a PR.
Some services comes with additional resources, these can be bundled within the jar if moved to src/main/resources. This also applies to configuration files, it is however recommended that these are easily edited.
- Authentication: Account creation and available realms.
- Routing: Routes client requests in/out of the cluster.
- Realms: Handles incoming connections, instance travel.
- Instances: Handles game logic.
- Realm registry: keeps track of active realms.
- Website: Provides an interface for account/character/realmlist.
- Logging: Receives logging data from the other components.
- Social: Achievements, chat, guilds. (TBD)
- Auction house: Handles asynchronous trading with orders/offers. (TBD)
- Serverstatus: Provides a quick overview of system uptime. (TBD)
Patching is no longer a service - the webseed standard was not very well supported so support was dropped. We are aiming to create a browser based game primarily and will rely on a CDN to provide game resources. We want to avoid serving files over the cluster or machines that handles the website or the game state.
Communication between services is done over the cluster/local bus, other available transports such as websock, tcp, udp and rest is available but not recommended unless a service is not able to join the cluster. Services that needs to authenticate another service should use the AuthenticationGenerator to generate pre-shared keys, secrets and generate tokens. This may be invoked from the standard launcher in chili-core, using the
--generate commandline argument.
All communication between services in different JVM's uses a text-protocol based on JSON for simplicity.