jimbuck / brewmasterengine Goto Github PK

Make sure sound works seamlessly and create a platform-independent wrapper if needed.

Auto-scale the rendering to handle different screen sizes.

Default input will be touch, but for devices that don't have touch, convert the mouse to simulate touch.

Right mouse button could be used for pinch/rotate. For example, try Hammer.js with a mouse (but instead of using shift you would just click with the right mouse button).

A collection of structs that reduces the number of memory allocations by reusing "free" structs.

Sprite Atlas: All textures in one file. (static images)
Sprite Sheet: Similar textures of same size in one file. (animations)

After working on a few games, its clear that Brewmaster needs a StaticImage and StaticText class that can be instantiated. Maybe changing Sprite2D and SpriteText to not be abstract might be the best thing.

Rectangle, ellipse(circle), polygon, etc.

The spriteBatch.FillRectangle command does not work when passing Vector2's for position and size.

Very basic and simple GUI system. Inspiration comes from Bootstrap and what Java Swing tried to be. It will start as only a layout manager, but if it makes sense to add things like IClickable and IDraggable then it might expand.

Update:
The layout system will be very simple and flexible, only implementing a layout manager and an easy to implement element class. Currently the layout manager is working as expected, which is good enough for this version. As I create other games with it the element class may change to better handle various interactions.

Handled by the SceneManager

They don't do much good unless in the corresponding namespace...

SnappedSmall, SnappedLarge, NotSnapped, Snapped

I'll probably handle this in a dedicated event listener, that should clean up a lot of the code access.

Create bounding box and collision mesh from sprite texture.

Console, Profile Graphs, and possibly object inspection. Maybe mouse translation (to help with positioning).

When trying to run comparisons between 2 GameObjects the code must live in one of the objects. Creating a flexible event system would be better, allowing the events to be attached to the scene. Probably something as small as giving the Scene an Update method might do the trick.