v4nz666 / roguepy Goto Github PK

The current pattern for init.py (importing all modules in the package) may not be desirable or Pythonical. Investigate best practices.

X-offset is off by one

In Demo 3, the Slider bar goes all the way to the left (covering the arrow) for the minimum value, but stops two characters short of the right for the maximum value.

Determine where and how to handle these two fundamentally different styles of rogue-likes.

Either the State, or the Ui should get a setFocus(element) method, which would set a self.focused property to the given Element. Further input not handled by the view would be passed to the focused element. View-bound (global) inputs should still be considered, but we shouldn't need to bubble down to all child elements, only the focused element.

Provide gotFocus and lostFocus methods on elements (views?)

If one-line messages are added, they scroll properly, i.e., top messages are removed at the appropriate time. With multi-line messages, however, sometimes the last / latest message is cut off. Repro steps needs. (Related to #30, since currently a multi-line message may get removed from the top / oldest, leaving a blank space at the bottom of the scroller.)

Allow users to register different tick handlers (including rendering the UI!) at different tick intervals, allowing for separate physics/ai update/ui rendering intervals

Package (maybe implemented as class, maybe some other Python idiom) which gathers together everything all prototypes will require (e.g., UI, StateManager, game-world state and logic).

Migrate Key and Color (yeah, programmers are required to spell "color" the American way :/)
"enums" (probably just module variables?) to RoguePy so applications don't need to import libtcod just for those.

It'd be nice if libtcod rendered the bottom-half of wrapped, multi-line strings whose heads are chopped off. We need to either find a way around this (it must have some concept of scrolling?), or roll our own string wrapping.

Bare minimal item handling. Items simply have an item type with a name, can exist on the map, or exist in a character an Entity's inventory. Prototypes will certainly have vastly different concepts of what an item is, so don't have too many assumptions.

Send it messages, it scrolls as they come in. Automatically group identical messages, e.g.:

scroller.message('You attack!')
scroller.message('You attack!')
scroller.message('You attack!')

Should result in:

You attack! x 3

In Demo 5, scroll right. When the marker reaches the point where the map should start scrolling, instead columns on the left start vanishing. This bug probably was introduced with the bounds check I added in 91a8d81, though I'm not entirely sure how o_O

If Python 2.7 supports property methods via decorators, properties should be used instead of getters and setters wherever possible.

With the focus concept added in #19, modals no longer make sense as Elements, since, when one is active, our regular view-bound inputs are not processed, and you may want to have focus on individual elements within the modal, giving no good way to bind input to the close method on the modal.

If modals were Views, and opening one was a concern of the state, we could have a stack of view/focus pairs.

Whip up a couple more demo states, demonstrating different handler registration patterns to achieve a real-time and a turn based game.

Allow for input triggers like "SHIFT+TAB".

Currently, chars bound to input will accept either upper or lower case, should this be the case?

DemoOne -> Demo1, etc.

Things aren't right.

thoughts:

• setBlocking should live in the state manager.

Create one. Outline what each demo state has to offer. Add new ideas for demos, to be fleshed out as we go.

Allow objects (initially just GameObjects, i.e. "models") to post events based on internal state changes. This will allow Views that hook events and automatically update (e.g., an HP counter which only needs to be bound, rather than constantly / explicitly updated), without requiring GameObjects to know anything about views.

Perhaps inputs could be bound at the Game level, for things like ALT+Enter to toggle fullscreen

Pretty things up by allowing animations / effects (e.g., rain, water rippling, etc.) to play, even while the game clock is not advancing in turn-based games.

Simple framework for saving and loading the Game object

Pull in the demo

Elements should track when they're dirty, and only update their console when they are. Provide an interface to trigger a dirty state, in case we find ourselves in need of a redraw, without having gone through the "normal" channels (setItems(), centerOn(), etc)

Implement simple sound support. See http://www.libsdl.org/projects/SDL_mixer/docs/