monofuel / badmars Goto Github PK

The world might looks nicer if cliffs are exaggerated vertically to appear more steep.

SSAO or other effects on the frontend that threeJS supports would be cool.

animations are jumpy and need to be fixed

• refactor how the client handles location
• tell the server where the camera is looking
• server should remember where the player has been when they log back in
• server should only send unit movements for chunks the player has loaded.

Currently, unit selection will show a square. It might be more intuitive to show a circle that conveys the health and storage of the unit

Switch from es6 / flow / babel to typescript for the nodejs portion of the server, or possibly to golang for more of the backend.

haven't tested this in a while

might be neat to have an automated test for, but also might be too much work for now (we'd need a way to spawn tanks within range of each other during the test)

when refactoring the database interface and setting up the simple standalone mode for debugging, i broke a ton of the services and networking stuff.

• need to update rethinkdb database code for the new database interface db/index.ts
• should probably get rid of the 'map' service because it was silly and weird.

Adding shadows (at least for the terrain and buildings) could be really nice

Switch from es6 / flow / babel to typescript for frontend

Decrease ambient lighting and add lights to buildings to better highlight visible parts of the map.

• Add lights to buildings
  • Optional shadows
• decrease ambient lighting
• Change the moon to be a static light at night, instead of a moving light.

I already use Oauth on japura.net and on ffxivmc, we should use Oauth for login on badmars.

If the user data changes, we should push it to the user so that they can know the latest colors of all users.

I used Material-UI for the main japura.net website and for ffxivmc, i like it and should change to it from react-bootstrap

fuel usage should be turned on for units eventually. atm it's disabled to make things simple to test.

resource transfers between units would be nice with something to visualize the transfer

The ability to cancel a unit or building being constructed would be nice

for notifications of attacking when offline

Factory queue is processed on the backend now, but needs to be updated for the UI.

Might also need some new fixes on the backend for unit delta changes.

a countdown for how long the unit has to live with the current fuel usage would be nice.

Each backend service should probably provide a system for periodic healthchecks

Previously, badmars used babel-watch to watch for changes. Because i want to get typescript into the mix, the project is transpiled with babel into ./bin/server/nodejs. The problem with babel --watch is that it does a full rebuild, and then watches for file changes, however I want it to only watch for changes since the project should already be built.

I started a script buildWatch.sh that can be ran in a container via make dockerWatch which should watch for file changes, but it's having some issues (multiple events are fired, specifying -e modify doesn't seem to generate events, %w%f doesn't seem to ever specify filename, i'm probably doing stupid mistakes)

The end flow that i want a make target to build all the containers (docker-compose build) and build the project (dockerBuild) and then another make target to run the server with server code hot reloading.

the database class in server/db/db.js keeps track of all the tables. When a new map is added, it should load them. currently they're only loaded on startup.

the DB, util and logging components are used almost everywhere as singletons, and this has led to a lot of mess and circular dependencies issues. This should be refactored, and there are a few possible solutions.

• initialize them once and pass them down (dependency injection)
• initialize them once as globals and use them everywhere (globals suck)

ghosts remain hidden after construction, refreshing fixes this visual bug.

Atm players can set a color when they first login, a proper flag / color system would be cool.

The current spawning system is very slow and buggy. It turns out that spawning is actually very hard! It needs to have no race conditions and be able to reliably spawn players quickly. This probably should be separated into another service

• Spawn flag on the user document. if a user is being spawned, atomically set a flag so only one service can spawn that player.

• Find a spawn location

  • Should find it quickly
  • could be pre-calculated. Could spend free time finding spawn locations, storing them and picking them off to spawn users.
  • spawn locations should be spread out from other users
  • spawn locations should have a lot of open space

• spawning could possibly modify the map to flatten terrain

• Once a spawn is found, actually place the user in that area

Should switch to protobufs for websocket IO for efficiency and typing consistency.

Switch to winston for logging and profiling

• remove util logger stuff
• make andrelytics winston transport

currently, a moving sun and tweaking the normals on the mesh are used to convey the 'tiled' look. It might be nice to look into a better way to do this.

Maybe only show a grid while building (eg: starcraft) or add a light grid texture to the terrain.

It looks like units that use fuel are being put to sleep in some cases, this should not happen.

(in hindsight, 'sleep' was probably an awful premature optimization and should be removed)

Internal faces on models (like the factory smoke stacks) should be filled in with a black 'internal' material that does not reflect.

The current UI is really hacky, it needs to look pretty. The first step probably is to get some nice UI mockups done.

UI features required:

• chat input and chat history
• menu for options
  • performance settings for how much of the map to load
  • about page with copyright and github links.
• Selected unit information
  • HP
  • storage
• buttons for selected unit
  • if no unit is selected then building placement menu

would be cool

The game lacks music

Ability to define trade routes that transports can run along

transportation towers that can be chained together to form a route.

Currently when starting up, multiple services might create a table at the same time and break rethinkdb. There should probably be a separate service responsible for setting up the rethinkdb tables (probably in go)

Currently the only solution is to go into the UI and delete the bad tables.

Programmer artwork is awful, units need to look nicer.

Material-UI secondary buttons are set to a bad color.

• secondary button color should be better
• A better way to signify that the build bar has switched to 'factory' could be nice

currently the server keeps track of the last 60 chunks a user has viewed ( #29) The client should send some config info to the server to be more intelligent about this.

being worked on in the way too big PR #1

• break apart state on units into components
• allow loading and unloading of components from the unit stats on the fly
• ability to change, add and remove unit types on the fly

add password resetting for verified emails

Construction does not work atm

send an email on registration for verification

• implemented visuals
• should not show enemy units that move into fog
• should keep track of buildings that have been seen
• server should not send data for hidden units
• units that can attack should be limited by vision

Currently there is a custom profiling system on the dashboard, it would be nice if this used andrelytics instead.

small colored sprites to optionally show over units would be nice to make it easier to see different units and friend or foe at a glance.

broke resource transferring again.

• fix this (both backend and frontend)
• add it to the go test in tests/

Come up with a timeline and a release date.

add an editor to change unit stats on the fly

• UI for editing stats
• have stat changes update units
• stats are on a per-planet basis
• if no stats are saved, use defaults from units.json