Skip to content

Design

Jump to bottom Edit New page
sashman edited this page May 25, 2018 · 30 revisions

Game

Inspirations/Aspirations

  • Graphically inspired by Legend of Zelda: Link to the Past
  • Procedurally generated open world, alike Minecraft and Terraria, but mostly DwarfFortress
  • Procedurally generated settlements, mainly DwarfFortress, but I'm not sure if there is a game that creates them to this extent
  • Combat system: simple on the outside, like Legend of Zelda, complex under the hood, like [Dark Souls] (http://en.wikipedia.org/wiki/Dark_souls).
  • Procedurally generated populations, generated as a tree (or a forest of trees), so should be able to trace back to a common ancestor
  • Using the population, generate quests based on the quest givers needs, example being: A lumber jack would give you money to collect wood for him
  • Generate a destiny multi-part quest for each human player, this should take in account the pacing and monitor the players involvement in the quest, hence adjust it accordingly.
  • Alike in [Mount & Blade] (http://en.wikipedia.org/wiki/Mount_%26_Blade) games, you should be free to join factions or create your own one if you wish.
  • Start off with two nations/major factions, stylistically resembling [medieval western and eastern Europe] (http://s3.amazonaws.com/criterion-production/stills/10247/Nevsky.jpg?1328128299).
  • Each major faction should have a state religion, minor religions should be procedurally generated.
  • Religions should be defined in game and make the player believe that faith is rewarding. There is a lot of room for experimentation here.
  • Generated dungeons/fortresses/temples should be scattered around to give the player something to explore outside of the settlements and get loot from.
  • [Weird shit] (http://www.youtube.com/watch?v=0O6-1sp6yvM) should happen when players go inside ;). The weird shit could carry on to the outside world.

Software architecture

What we have so far

Goal

The aim is to have 2 distinct use applications:

  • Web base game client
  • Game server

And at least one managed service:

  • Database of users
  • Web front end allowing to create accounts

User applications

The game web client should be available for the clients to access at all time. The initial phase of the server is to only have one instance running on our own physical machine, later the server should be available for download.

Web client

Most of the underlying architecture for the game client is already in place. However it might still change to accommodate the server development.

Server

The initial design of the back end should be as follows:

  • [Authoritative approach] (http://www.gabrielgambetta.com/?p=22).
  • The server should consist of the web-facing nodejs server.
  • The nodejs server should govern only high level tasks such as passing data to the client.
  • The meat of calculations should be done by modules written in C++ and using nodejs native extensions.
  • A lot of the code has to be shared between the server and the client to accommodate for server side calculations. But how can this be done elegantly with a lot of calculation code being in C++?
  • The server has to store the current state of the the game world and all of the entities ([for now] (https://github.com/sashman/kingdomforge/wiki/Roadmap#foregrounding-and-backgrounding-architecture)).
  • The server should also accommodate for a database for keeping state when it has been shut down.
  • The server should have a unified logging system, most likely stored in a database as opposed to a raw file.

Useful links for research:

User database

This will be a database for users to authenticate against. Good candidate would be a ruby on rails instance.

Network protocol

Protocol for multiplayer communication

Based on realtime-multiplayer-in-html5 example

Server side pseudo code

Init
  • Set up players
  • Set up time
  • Start time loop
  • Start physics loop
  • Clear last state
Update loop (subject to delays)
  • Set time
  • Save last state
    • Save player positions
    • Save player inputs
  • Send snapshots to players
Physics update loop (happens at fixed frequency)
  • Handle player
  • Process player input
    • for each input in buffer
      • LERP together
      • get new direction
    • add to player's current vector to get new direction
    • clear input buffer
Server handler for messages
  • "i" message for the input handler
  • "p" echo the ping message back to all clients
  • "l" set fake lag to give lag value

Client side pseudo code

Init
  • Set up players
  • Set up prediction entities for players
  • Set up time
  • Start physics loop
  • Set up server update buffer
  • Start ping timer
Update loop (subject to delays)
  • Handle input (build up input buffer)
  • Send input buffer
  • process net updates
    • get current time
    • find oldest update in server update server, this update has to be closest to our current time
    • if none found, use servers lastest server update
    • keep a target (next state) and a previous (last state)
    • work out difference between target time and current time (diff)
    • work out difference between target time and previous time (max)
    • calc a time_point = diff/max
    • FOR ALL PLAYERS
    • get latest server pos for all players
    • get target and previous pos'es for all players
    • save the latest server position
    • vLERP between prev and target using time_point
    • if client smoothing
      • vLERP between the current player's pos and predictions entity's pos
      • use client physics time * a smoothing coefficient for this
    • else set the player's pos to prediction entity's pos
    • if not using client prediction
      • apply above calculations for self player
    • else
      • set self player pos to pos in current state
Physics update loop (happens at fixed frequency)
  • if using client prediction
    • vADD all vectors in the local inputbuffer to self player's pos

Messages:

  • onhostgame
  • command: s
  • subcommand: h
  • data: time
  • ...
Add a custom footer
Add a custom sidebar
Clone this wiki locally