deedlefake/plane

Yet another attempt at making a simple game framework/engine.

plane

Yet another attempt at making a simple game framework/engine.

plane's Issues

Add Audio System

Maybe using golang.org/x/mobile/exp/audio/al?

Add Support for Different Backends

The plan is as follows:

• Replace engine.CreateWindow() with engine.Init(), and have it take a new type with global engine initialization parameters.
• One of the parameters will be an instance of an interface called something like Backend. This will provide all of the necessary details for running everything. Window initialization, event mapping, etc. It'll have several other interfaces as well, such as Window.
• If the Backend parameter is nil, a default will be used. Probably pixel.

This, unfortunately, could get annoyingly complicated as the engine becomes more complicated itself. The plan may have to be altered to make things a bit simpler. The main complication is likely to arise from requiring clients to load images and whatnot through the backend system's abstractions.

Implement UI System

The engine should provide a UI system in a separate ui package.

• The UI should provide an Object that can be added to an ObjectGroup and functions as a widget manager.
• Widget should be a relatively simple interface with a variety of implementations provided. Widgets should be able to draw themselves, but, unlike an Object, the bounds that they must be drawn into are provided when Draw() is called. This allows their sizes to be managed by the UI system.
• The system should be designed to allow usage in a declarative manner, probably using callbacks. For example, rather than a progress bar widget having a SetProgress() method, the bar is initialized with a reference to a func() float64 which is called during the update step to get the current progress value. This allows the client to simply link a, for example, health bar to the character's actual health by having the function just pull the real-time health value when it's called.
• All layout should be handled by a single Container widget implementation which can be given several different implementations of a Layout interface, or possibly Layout function. This flattens the hierarchy and simplifies things quite a bit.
• Instantiation of a GUI should be possible in a simple way. So, rather than having to construct and configure a widget through multiple function calls, all widgets, including Containers, can be instantiated and configured in a single function call.
• The system should be themable in some way. This is not a priority, but is kind of a necessity for general usage.
• The event system should be very simple, possibly responding only to clicks. It may be possible to integrate this into the declarative values by having widget state (ButtonUp, ButtonJustPressed, ButtonDown, etc.) be passed to the value functions.
• No built-in focus system. Possibly. If the client wants to send events to a widget, such as typing in a text field, they must do so manually. Alternatively, this could be integrated into the event system.

Widgets:

• Label (func() string)
• Button (func() string)
• Bar (func() float64)
• Entry (???)
• Image (func() engine.Sprite?)
• Container