jnaglick / ezrl Goto Github PK

The game package class hierarchy:

Right now, the engine just progresses the game based on commands its gets. This ticket is for the engine doing its own thing to progress the game.

Maybe have a different subsystem to issue commands that do this stuff, and then the engine will just interpret them?

Proof of concept: could be "bleeding" of EoT; death for cause/effect (layer dies based on hp or hunger)

Right now, the Map class imposes its own bounds-checking by returning None from getType() and setType() if the parameter coordinates are out of bounds. Places that call getType() and setType() don't care about the bounds of the Map and simply handle the None return case.

This makes the code much simpler for the sake of a minor performance loss.

When the player is near the edge of a map, the DisplayManager's map drawing loop hits this performance loss in a big way. It would be fairly easy to change the loop so that imposed the map's bounds on itself.

Not much else to say on this right now...

These classes are needed so freaking bad. They are just wrappers that give names to 2-tuples (pairs). Coordinate is for x/y, Size is for w/h, Range is for min/max.

It's debatable if you really need 3 different classes just for different names but I think that abstraction would be nice.

Right now a ton of stuff is just passing around these paired-values, usually as multiple arguments to a method or as methods returning a python tuple. This worked for a while but I'm finally starting to see places where it's limiting code flexibility

Right now, the Player statusMessages list grows indefinitely as addStatusMessage() is called. Instead, this list should be self-clearing so as to not keep glomping more and more memory.

Use configuration (or "settings") files or modules so certain config options can either live outside the code completely or at least aren't as tied in with an implementation.

If this is a file, it should use a simple format like yml. A file reader class will have to be added.
If it's a module, it should be simple python that, once imported, provides easy to use constants.

I can think of two types of config right now: (1) general game settings (stuff like the location of the font file and the console width/height). (2) consoleItem configuration, which would translate internal *type (mapTileType, itemType, more in the future) constants to a consoleItem, which in our ASCII case is just a character and fcolor/bcolor. This would replace stuff like the MapTileToConsoleItem class.

Build on the "partial commands" thing. Will allow for chaining lots of partial commands together and switching between command lists.

Proof of concept: target subsystem that can be used while building a command. Throw command will be a good candidate.