ldemouy / nail_engine Goto Github PK

Implement at least the following:
Context Free Usage of an Item
Context Free Use of One Item on Another

If it can be easily managed Implement Context Dependent Usage

Depends on #5

Is your feature request related to a problem? Please describe.
a message based game engine is by definition ludicrously parallel. However in the real world the number of threads is limited by the CPU it's run on, and throwing a ludicrous amount of threads at a CPU can negatively impact performance, the general solution to this is to use a threadpool. we already pull in Rayon as a dependency anyway due to Crossbeam.

Describe the solution you'd like
switch all instances of thread::spawn to rayon::spawn

This consists of being able to load a list of items from a file, and being able to get a description of the item by typing in a command.

Inventories and Rooms containing objects are not in scope for this feature.

Implement the following functionality:
Load Rooms from a file
allow a player to move between rooms
allow a player to get a description of the room
allow a player to get the name of a room

Create a basic inventory system, this probably ought to be handled as an ECS Component that can be attached to a Room or Player.
Player should be able to get a list of and look at items that are in their inventory and if rooms are implemented have the same capability for the room that they are in.

depends on #5

Is your feature request related to a problem? Please describe.
At the moment the engine cannot add or remove objects that are listening to the messages passed through it. This also prevents the concept of level or game mode transitions. This is fine for the current application of text adventure games, but long term nail could be used in other contexts that need it.

Describe the solution you'd like
Split off the current listeners vector into a containing object that treats vectors of listeners as levels, has the capacity to add or remove (as well as possibly enable/disable), and to which each cycle the engine object listens to, to determine who to send messages to.

Playing with stdin and stdout is all fun and games, but implementing a real GUI would be better, presumably using something like curses for now