The Dance Server aims to emulate the behaviour of the original DANCE! ONLINE game.
- Building
- Versioning
- Running
- Scripts
- Structure
- Best Practise
- Further Thoughts / Bigger Goals
- Developer Environment
- Links
Gradle is used as the build system.
If no local gradle installation exists you can use the gradle wrapper to build the project.
To use the wrapper run 'gradlew' instead of the 'gradle'-command.
Further details: https://docs.gradle.org/current/userguide/gradle_wrapper.html
Building the project:
gradle build
# without gradle installation
gradlew build
Building a single executable .jar-file:
gradle fatJar
# without gradle installation
gradlew fatJar
Building a single executable .jar-file without version:
gradle fatJar -Pserver
# without gradle installation
gradlew fatJar -Pserver
The version number depends on the git commit.
The command git describe --tags
is used to determine the version number.
It is made up of the latest git tag
along with the number of commits after that tag
and the short commit hash
of
the commit the release is based on.
Ex:
{ProjectName}-bundle-{Version/GitTag}-{Number of commits after tag}-{Short git hash of commit}.jar
dance-bundle-1.0-1-g588a3f9.jar
Running Server:
gradle run
# without gradle installation
gradlew run
Running Server from fatJar:
# GUI
java -jar dance-bundle-1.0.jar
# No GUI, just server
java -jar dance-bundle-1.0.jar server
Deletes all files that are ignored by git:
# unix
./clean.sh
# windows
./clean.bat
The Server is written in a modular way, that allows to exchange and reuse components easily.
Provides the entry point to launching the server and all related tools.
It processes the arguments and launches the appropriate components.
Following arguments are implemented:
- server: Launches only the server
If no arguments are passed the graphical user interface will be launched.
Only the graphical components who depend on the server-project are included. All other user interfaces can be found in the editor-project. Adding new graphical components is easy by extending the 'EditorFrame'-class, this provides all information on how a window is displayed.
Automated client to interact with the game-world via server.
TODO:
- Interact with server by using existing protocol (as client)
- Extended Bot, knows the server instance, overrides methods to be spawned as a thread by server
- join Rooms, play games, be fair :)
- ability to spawn bot for playing by players (think lover-mode is missing a player)
Backend to store persistent data.
Function:
- Provides an interface to implement different storage solutions in the future.
Ensure:
- Save to DB when creating new entities who require to have an 'id'-property.
- Save to DB on critical operations (e.g. change of 'coins'-property)
Contains graphical user interface components to manage tasks.
TODO:
- "songlist.dat"-File editor
- "datas.sac"-File editor
- "Add/Remove Song"-function (create entry in songlist.dat & DB, produce all necessary client files)
Read/ Write 'iteminfo.dat'
Function:
- View all items
- Edit item
- Add new item
- Export to Database
Stepfile Editor
Function:
- Read / Write '*.gn'-files
- Display properties of stepfile (notes, difficulty)
- Visualise steps
Includes shared functions that are used in multiple projects.
Function:
- Database Models
- Classes for client file reading/altering/writing
- Utility Classes
Handles log messages.
Function:
- Different Log Levels
- Scheduled writing to file
- Printing to console
Accepts clients and handles requests.
Displays a list of channels available to join.
TODO:
- Test synchronisation of players (channel status)
- Implement the special competition channel
Lobby, Room and Private messages are handled.
Function:
- Easy to extend by middleware
- Commands
- Filtering bad words
- Logging of chat messages
TODO:
- Banner Messages (Scrolling top of screen)
- World Messages (Shouting with the speaker item)
Manages starting a game, handling scores
Creates new groups and keeps track of exist ones.
Manages items a player owns.
Manages the players inside a lobby, and keeps track of rooms.
System to send and receive in game mails.
Handling of individual client requests and building the answer.
- /packet/builder
PacketBuilders are Factories that help building the packet.
The Factory should only ask for the minimum necessary input to build a packet. - /packet/handle
Packet Handlers are Classes that handle an incoming request, and craft the response.
TODO:
- Implement missing packet functionality.
Interface to talk with external clients
TODO:
- remove dependency of 'com.sun.net.httpserver.HttpServer'
Handles room state, keeps track of the players inside
TODO:
- Sync (Test joining / leaving)
Handles shopping actions (buy / sell)
TODO:
- Implement missing features
Manages available songs
Underlying system to handle TCP connections
TODO:
- Testing of different implementations / multiple clients / load
- Finding best implementation
Lets two people marry, displaying their characters in each others profile.
- org.xerial:sqlite-jdbc:3.20.1
- Own the Code: extract solutions, discard libraries
- Reduce Inheritance: Favor composition over inheritance
- Reduce Inheritance: Don't target the Interface (ie: declare varables as List<> instead of ArrayList<>) until necessary
- Reduce Database Access: Manage high read/write access in memory, write back when crashing/closing (Except critical transactions, money, etc.)
- Annotate functions with Javadoc (http://blog.joda.org/2012/11/javadoc-coding-standards.html)
Duplicated information is stored in more than one place. For example the properties of items are stored in a file (iteminfo.dat) and inside the database. It need to be ensured that those files are always synchronised. Therefor a source needs to be set on which can be relied that it contains the latest up to date state of the information. A system need to be put in place that can produce all necessary files based on the source.
- Define a source ("master"-source) that holds the latest version of the information / where information are stored and updated
- Build a system that can produce all files from the "master"-source
- Version these files, so clients can always be sure to be synchronised with the servers "master"-source
- If the "master"-source is updated, the server needs to be shut down, a version needs to be bumped, and when clients connect they need to update in order to be synchron with the "master"-source again
- A new project called "inspector"
- Operates as a proxy and lists all incoming / outgoing packets
- Provide inspection of the packets (display all known and unknwon properties with name and value)
Steps to setup an development environment with various IDEs.
- Arrowgene
- Markdown-Cheatsheet
- SDO-X (Malaysia) http://sdox.cibmall.net/
- When a client disconnects, at some points we still try to write to the socket (maybe test if alive or smth?)