jordan-cottle / game-design-capstone Goto Github PK

Sometimes when the game ends, player instances aren't being cleaned up.

This is likely just an issue with the server side logic for detecting players who haven't sent a logout event.

Cities will be consumers of resources.

Using two client running side by side, they seemed to share their balance. When one ship would sell resources, both clients would end up with the money from the transaction.

Events are great for asynchronous communication between client and server, but if the client needs to send a request and expect a reply, normal web requests are better suited.

Things like logging in and requesting data from the world would be better handled using normal http calls to a REST style endpoint.

For this issue, implement the "/login" endpoint to authenticate a user and create a session.

Players should be able to construct buildings that generate resources over time

Autonomous actions in the game that take time should be controlled by server tracked game ticks

The combat should be turn based to keep simulation simple and easily configurable by players

Combat calculations should be done by the server. Each combat instance should have an appropriate representation within the game server.

Now that there is technically a published version of the client, development shouldn't involve updating/restarting the running server.

Splitting the development server from the production one will be easier with a configurable port since I've only got one device/ip to host on.

Players should be able to use the money they've earned and resources they've collected to found a new city. Player created cities should be maintained by the players. If they end up without enough resources to sustain themselves, they should disappear.

The server should be capable of sending messages to players, and players should be able to communicate with each other.

Right now the server effectively resets between runs. For the game to be playable long term, the server should persist changes across runs.

We can use json and a file system for now

They didn't seem to do the right thing during the early tests

It should have a trading menu that allows for individual items to be bought/sold in various quantities.

Cities should also have an upgrade menu that provides access to player upgrades.

The server should be responsible for what tiles are present on the map.

Players should have things like inventory size, movement speed(cost), mining power, and attack/defense parameters. These values should be tracked per player and determined by upgrades and other details.

For the multiplayer functionality to work, we need a working server.

https://github.com/socketio/socket.io-protocol

This looks like a promising library to communicate with a webgl deployment of the game. The flask server could serve the html/js files to clients that then execute the code to connect via the sockets to exchange events.

Ask user their name/password before loading the main scene

This will be a multiplayer. Client side networking will need to be set up.

Obviously for this to work, a server must also be implemented.

Right now everything is just printed to the console. Using the python loggers to put the logged events into files for easier parsing would help with debugging and tracking of statistics.

Structures should be player owned, take up a space in the game world, and perform some function on each game tick.

The GameController has a lot of components that control different subsystems of the game. This pattern could be nicely mapped to a common GameSystem interface with the GameController acting as the bridge between them.

The server will need to have proper events to receive the updates

Right now a lot of the aspects of the server are hard coded. Things like what kinds of resources are available, and their different parameters, should be read from a config file that can be easily extended/updated.

For the character to move around, we want an intelligent pathfinding algorithm

This will require;

• World structure to contain useful pathfinding information
• An A* implementation that can be called by units that need to move to a destination

Docker containers would make packaging and deploying instances of the server easy. Setting up a long running server without screen would also be easier.

Docker containers would allow for separating the development server from the production server easily without needing to add extra config options for in mentioned in #41

The server should control the timer and push new events to clients when it ticks

Limit maximum amount of resources gathered at one time.

Once the map is read, we need to add a player controlled character to it

Raiders should attack players and attempt to steal resources from cities.

They should take resources gathered back to raider bases.

Over time the raider base converts resources into new raider units.

Player triggered manual actions in the game should have an action point cost.

Each player should generate a set number of action points per game tick that can be spent on actions throughout the game like movement and gathering.

We want to be able to store user data and associate it with a login

This will ensure disconnects without a proper logout are processed properly as well

The game world will be displayed in hexagons

they should be able to trade with each other

The most logic action here is to split this repo into two.

Hello, under what license is this project released under ? I would like to study it to learn from it. Thank you.

While the ui displaying city data is open (as of right now it is always open) the ui should respond to changes to the city made by other players.

When a player engages in combat, a special UI that allows for the player to make decisions should be presented.

Combat should take place within a single tile in the game world.

Allow the character to be controlled by clicking on a tile in the world

This will require:

• Detecting which tile was clicked on by the user
• Moving the character between its current destination and target incrementally

In the rush to get things done for the deadline, proper unit tests have been skipped over. Now that there's a little more time to breathe, testing should be brought up to speed with the server.

To start, we only need a few.

Food, metal, fuel

visuals go into client.

Server side representation will need to come after map data is stored

An sqlite database can be used at first for its simplicity.

The login page currently doesn't report errors when a password or email is invalid.

For a quality user experience it should let the user know what happened and why their request wasn't accepted.