jacobalundgren / economy-game Goto Github PK

To allow for strategies to be able to evolve, prices at which resources can be sold need to change in accordance with the actions of the player.

The game and its strategies will most likely be somewhat less degenerate if production takes time rather than being instant.

The code base is littered with typical prototyping unwrap calls. Obviously a proper error handling system needs to be established. I'm not sure, however, at what point this is appropriate as given my very limited experience with Rust it will most likely slow down progress on the core functionalities that will guide further development.

Currently the accumulation of resources has no ultimate goal. A first iteration of providing such a goal would be to be able to sell resources to an abstract "consumer sector". This would yield money which could for the moment serve as a form of player score. As a first step, the consumer sector buys at fixed rates, but through multiple iterations the price function could be made both more realistic and more conducive to actually allowing for the formulation of strategy.

When someone runs the game for the first time, all three of the available workers are mining iron. It's not immediately clear what to do to reallocate them for mining other resources, and also this gives some initial skew in favour of iron. Probably it would be more fair to begin with all workers idle

Currently, each tick causes the visual elements to be recreated, while in reality they will generally remain unchanged. We should introduce caching for this data to improve performance.

The initial terminal user interface would benefit from having various tabs presenting different views on the game state and options available to the player.

With #7 adding a tab system for visualization, the top priority is to add a help tab that gives any information that is not immediately obvious from the interface (for now, hotkeys in particular).

Currently the processing of user input is done in a dedicated input unit, but as the set of tab types widens the interpretation of input sequences will need to be defined by the active tab to allow multiple tab types to use the same key bind for different purposes.

Many of the tabs use the resources of the player, and they are currently a rather central concept. They should be shown in their own field irrespective of which tab is active.

Currently the client is running the game loop and instructing the game state to step. This should be inverted and the game state should instead be taking steps independently, and instructing the client to refresh.

In order to enable the addition of player actions in the game, the execution flow must first be changed to be under the direct control of the user. Make the main event loop perpetual and listen for keyboard input. Add command keybinds for quitting and pausing/resuming.

The "game" is not much of a game without allowing the user any control. As a first step the player should be able to change the allocation of workers through an interface, perhaps beneath the table showing the resource count.

Currently, the logic for player-facing input-output is rather mixed up with the internal logic driving the game. This boundary needs to be clarified in order to

1. Improve readability and maintainability
2. Allow different types of interfaces to be defined
3. Allow the game logic to be run in its own process

Most of the project is not yet planned or formulated, but the basic goals and design principles should be described in the readme to get things started.

There should be a tab for general production improvements, with the first one being recruiting new workers.

In #18 prices were made to respond to player actions. In the absence of player actions, however, the prices should probably recover toward a market-neutral price. Initially, this can presumably be the fixed number of the initializing price. As resources are made more interconnected, it is possible that this can be evolved into some more interesting simulation of anonymous market actors, but that is for further down the road.