madbence / spacegame

hello world!

spacegame's Issues

Sync state across clients

Right now, the server does not store the application data.

progress

• do calculations on the server (with the same code!)
• sync state regularly (to handle state divergence caused by floating point math)
• sync state on init

Make FlowType pass

Implement user management

Based on #12 implement user-management using Mongo and a REST API.

Config management

there should be a config.js file, where all configuration variables are assigned.

Implement weapons

Proper implementation of thrusters

Strength should be 0-1, scaled with a hardcoded value

User management

This issue is a simple placeholder for tracking the state of user-management progress.

• #12 Design user model
• #27 Implement user-management

Come up with a better name for the project

i mean it took me 2 seconds to come up with spacegame, but i guess we can do better 😺

Add simple HUD

• health display
• summary of others ships (#153)

Prevent clients to join a game more than once

Introduced by #72

Scriptable ship controls

• should run on the browser
• it should have access to the low-level game api
  • dispatch actions
  • simulate state

Add crosshair

it looks great 🔫

Write documentation

Create room abstraction

Windows dev environment

current state

• Flowtype has no pre-built windows binary (see facebook/flow#6)
• todo

solution

Obvious choice is Vagrant.

problems

• symlinks broken (workaround here)
• todo

Remove obsolete events

Eg. remove explosions from renderer after they disappear.

Handle projectile collisions

• ships have health (remove destroyed ships)
• ships cannot hurt themselves
• ship-ship collision
• ship-projectile collision

DOM-independent keyboard control

Figure out user model

It should support multiple providers:

• facebook
• google plus
• local (user + password)

Create client-side scaffolding

Debug client time sync

It seems that sync is not that simple

Handle implicit events

Some events happen as a result of some other action(s). Like a ship is destroyed, etc. Right now, in the handleCollisions reducer, every event (projectile is destroyed, ship is destroyed) is appended to state.events. There might be a better way to handle this.

Design chat protocol

@gerawba feel free to comment 😉

messages

• ADD_MESSAGE
• SYNC_MESSAGES
• CLIENT_JOIN
• CLIENT_PART

architecture

todo

Upgrade to Babel 6

Refactor websocket <-> simulation

They are highly coupled, simulation (business logic) should be separated from websocket (transport mechanism).

Uncle Bob has a really great talk about this topic.

Add code coverage reports

istanbul & isparta

Add navigation map

players might drift away from each other quickly, but they should be able to find each other again

Roadmap

ideas

• more ships
• custom ships (ship editor?)
• better simulation (now mass is ignored)
• #135 custom controls (user scriptable controls)
  • related: AI
• save/share custom controls
• better graphics (webgl!)
• achievements
• save/replay games
• better app lifecycle management (rejoin games, etc)

todo

• chat
• user management

Code reviews

i think we should implement a simple review process before merging pull requests

my proposal

for daily work, our team (@purposeindustries) developed a similar, very simple process:

1. work in feature branch
2. push & create pr
3. if you're ready, put a review-needed label on it (it should pass travis tests)
4. someone else reviews it, removes review-needed label, puts ready-to-merge label
5. pr opener rebases the brach onto master & fast-forwards master

feedback is welcomed 😉 @Thegaram

Design layout

Create some mockups, etc...

Game modes

For start, implement free-for-all:

• respawn (predictable spawn positions)
• spawn protection (#142 + #144)
• point system (for start, 1 point for 1 kill)
• round system (point or time limit)
• rejoin game (#146)
• keep points after reconnect (?)

Simplify require paths

../../../foo/bar is ugly. there are several options to simplify this:

symlink from node modules

eg node_modules/server -> src/server, so everything can be imported like server/x/y or client/x/y etc. this works on windows too afaik. setup is a bit fragile, since you need a postinstall script that links stuff.

submodules

eg. move src/server to node_modules/server (and add them to git), etc. makes dep reinstall quite hard, since you usually just do $ rm -rf node_modules && npm i.

$NODE_PATH

set $NODE_PATH to src. this might work on windows too, but i'm not sure that the syntax is supported (eg. $ NODE_PATH=./src babel-node src/server/app)

local modules

modules can be installed from local directories, but then we have to maintain their own package.json files, etc.

i have experience with the symlink approach, it definitely works. i have tried also local modules and simple submodules, but they are weird (but they do work). i was not aware about $NODE_PATH until a few months, but it looks nice (if it works on windows).

App lifecycle events

• game lifecycle
• chat lifecycle
• ws lifecycle
• login lifecycle (?)

Improve phy model

Thrusters should behave like in real life, they apply both force and torque to the ship.

progress

• Custom thrusters
• Apply force
• Apply torque
• Configurable delta-t

Generate only one sprite for collisions

relevant code

Make ESLint pass

Maybe adjust some rules if needed

Store explosions in state

they might become relevant later (eg. they might deal constant damage to ships inside them), also rendering the scene becomes simpler with this.

Add shields

see #142

it might be refactored into something more general:

type Ship = {
  shield: Shield | null
}

type Shield = {
  ttl: number,
}

Create client abstraction