Skip to content
Rob Bean edited this page Nov 8, 2014 · 3 revisions

General Issues

Lantern

  • Raycasts should be tested when we have a (somehow) real scenario.
  • We can change raycasts' orientation and position according to our needs.
  • To add more raycasts, just do it on the player.xscn scene. Then change the lantern script to add them in _ready() with append_rc() function.

Shaders

Ghost

The ghost will have a shader that changes rendering for it, depending on light influence, like distance or number of raycasts hit. If no light affects, the ghost will be invisible for players.

Relevant docs:

(assigned to raz)

Post-effects

Relevant docs:

(assigned to raz)

Networking

Maybe use peer in server to receive sync data (ie. positions) from client peers, so an initial approach for server on each frame could be something like this:

  • Foreach peer, receive all sync data needed and push that data to a buffer
  • Broadcast that buffer to all peer clients

On client side, it could be something in the mood of:

  • Send my sync data to the server
  • Receive all sync data from all entities, now we have two options
  • Render entities from received sync data

Some questions arise

  • Will movement be computed on each client?
  • Will colision be computed on each client?
  • Will players collide between them?
  • Will players collide with the monster?

Relevant classes

TCP_Server

  • Start listening for incoming connections (listen)
  • Stop listening whenever you want (stop)
  • Accepts connections and returns StreamPeerTCP on taking a connection (is_connection_available, take_connection)

StreamPeerTCP

  • Connects to a server (connect)
  • Sends and receive data across the network ([put|get](partial)?data from StreamPeer inheritance)
Clone this wiki locally