SnipePlatform

Max S edited this page Feb 11, 2016 · 2 revisions

Snipe Platform

Overview

The Snipe server platform is a collection of source code and utilities for the creation of the MMO game server. It is written in Haxe programming language, and requires a Linux operating system and PostgreSQL database to run. The web editor component will require a configured web server such as Apache with Neko VM support enabled.

System requirements

The Snipe server requires a Linux operating system with the following packages installed:

  • Haxe programming language 3.1+ (needed only for development)
  • NekoVM interpreter 2.0+ with nPostgres module
  • PostgreSQL 9.0+
  • Apache 2.0+ with mod_neko (for running the web editor)

Logical structure

The platform consists of logical subdivisions called servers and the web editor. There is a single cache server that acts as a master server and has a connection to the database. There is at least one game type slave server plus there can be more slave servers of different types. All clients connect to the slave servers, send game logic requests, and receive responses. There should always be at least one game server. This server type holds the core game logic - users, shops, items, inventory, etc.

The web editor operates on a webserver. It can make database and cache server requests to read and modify the data and it can output webpages with this data and controls to change it.

There are two modes that the server can be compiled and operate in. In the normal mode, each of the slave and cache servers is a separate application that can be operated on different physical machines and communicate through TCP/IP connections. In uniserver mode, all servers are glued together into a single application to run more efficiently on a single machine. In that case all cross-server communication is done through thread messaging which is significantly faster. You don't have to change any project code to do that.

Modes of operation

Core modules

The platform provides various core modules which are the meat of it. The following modules are available:

  • Calendar events. This module enables the creation of different events that are active in the given period of calendar time. You define the event types, write game logic handling them, add events through the editor and its done. For example, they can be used to make timed shop prices discounts, display the information page on client login or lock buying of specific items in the shop until the release date.
  • Game Variables. This module is used to store game-related server-wide variables in database, read them on server start and update their values on all servers if any changes happen.
  • Items + Item Bundles. This module concerns in-game item definitions. These items can be given to players or sold in the shop. Each item has a list of attributes that can hold arbitrary game-related information. Items can be grouped into item bundles if needed.
  • Localization Support. This module enables an easy localization of every line of text you have in the game. You can download and upload the CSV file that contains all localization strings through the editor.
  • Quests. This module adds quests and quest chains into the game. Quests have lots of useful triggers, requirement types, local quest variables and results. Everything in the quest can be extended. Daily quests are also supported.
  • Shop. There is an in-game shop with unlimited or limited item amounts that are synchronized on the cache server. You can have multiple currencies if you want, the module allows that.
  • Users. The largest of the modules, it has sub-modules for things like:
    • Ready for full customization User registration and login support.
    • Badges (also called achievements), that can be given to players through the quest subsystem when a player reaches specific conditions.
    • Temporary in-game effects that can be received, or removed through the API. When the effect times out, the trigger can be called if needed.
    • Inventory system.
    • Generic user attributes and variables.

Data blocks

Everything stored in user records is accessed through data blocks API. The data blocks abstraction allows easy access with modification of dynamic data. The user data block is set up in such a way that you can simply read or modify its parameters through the API and forget about the rest. The system will handle the loading, caching and periodical saving to the database. The data blocks API is also extendable with new project-specific data block types.

Next: Server Installation

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.