axe / axe-go

Axe Game Engine for Go

axe-go

Axe Game Engine for Go

Important aspects of Axe:

• Readable
• Editor
• Debugging
• Modding
• Scripting
• Level of detail
• Multi-dimensional
• Real-time

Readable

Data, configuration, & assets are stored in a human readable format for development. Storing everything in a human readable format accompanied with using a file versioning system (ie Git) allows for tracking changes and merging in a team environment. Tracking changes to specific builds is essential for tracking when bugs are introduced. When an artifact is built data is compiled to a binary format.

Editor

The editor is an integral part of the development experience. You define your screens, configuration, import assets, build your worlds and levels, and can extend the native types and add custom widgets to the editor. When any external file changes the editor should be able to update when the developer wants it.

Debugging

An assortment of debugging tools is essential for a real-time application. Data is constantly changing and you need tools to visualize, profile, record, and replay it for debugging and testing purposes. Being able to do so against any parts of the game data is essential to delivering an accurate and stable game!

Modding

If a game developer wants their game to be moddable the engine should support it to whatever extent they want.

Scripting

Scripting is a quick way to introduce custom logic that can be more easily changed during development and also supports moddability if desired.

Level of detail

Using different assets or behaviors in different scenarios should be supported on everything. Traditional LOD for meshes and textures is supported as well as at the network level, AI, and audio to mention a few.

Multi-dimensional

2d & 3d are equally prioritized.

Real-time

Games are real-time applications, throughout play the requirements on the hardware can change drastically. A good game engine allows you to set priorities and requirements for all the logic that needs ran and visuals that need to be displayed.

axe-go's Issues

UI: layouts

• understands preferred size, the min size as far as placement goes, and how the existing placement should be updated but kept consistent

Base Audio Engine implementation

UI: clipping

Needed for scrollable sections and keeping text within an area.

Space Binary Tree implementation

2d rendering

Quads & Triangles. Add Mesh2 and Sprite2/3?

UI: placement refactor

All those pointer receiver funcs should be returning a new placement.

UI: drag component

Like in browsers, when a drag event starts you can give the UI a visual thing to render at the top and move with the mouse. Either existing component is moved, copied, or a custom one.

Maybe DragEvent has a Start func where you pass all the options for UI to take over. As opposed to using !Cancel.

Bonus: a droppable area demo could render a preview?
Bonus: a constrained dragging area

Implement View2

Examples

Register each stage so a single example can run

UI: dirty

only render if dirty (changed placement, by update, by key/pointer event, state, etc)

UI: visibility & show/hide

Still updated, but not rendered and not considered during layout. Should follow removal logic on hide. Maybe updating is stopped after outro animation. But importantly we keep the element in the parent.

Distinguish between show/hide and visibility. Visibility just doesn't do rendering. Show/hide also doesn't but it's also affects layout.

Implement Camera2

UI: xml based definitions

• define all reusable shapes, visuals, backgrounds and name them
• define components, their layers, and their children
• components can be fed options that are injected into the properties (button text)

FX: poc

package: fx
description:
A particle is a relatively-short lived visual object that's emitted, often moves/rotates/scales/changes color until it dies by fading/transforming/etc. All particles have an age, and max lifetime.

Because the are short lived and more predictably shaped than ECS they are not individually stored in ECS but in a single entity that updates it self.

This implementation will be like a miniature and very specialized version of ECS where there's a straight float buffer and you define a system by it's attributes which determines the number of floats required by a particle (each particle has its attributes stored contiguously). Each system can update its components and also transform the particles generated vertices before they are rendered.

A particle in this system is not constrained to a sprite, it could be a mesh that bounces around the physical world.

Concepts:

• Attribute = a float value(s) that describes the state of a particle. ie: age, lifespan, position, rotation, scale, color, texture, mesh
• Particle = an entity with an age, max lifespan, and any number of attributes
• Effect = a collection of particles that are described by a fixed set of attributes, initializers, an emitter, modifiers, and a renderer.
• Initializer = sets the initial value for one or more stored attributes
  • Shape = describes the initial position and can suggest a direction, velocity, rotation, etc.
  • Velocity = decides the initial velocity given the output of the shape
  • Functional = the initial value for an attribute is defined by a function
  • Constant = the initial value for an attribute is constant
• Emitter = Defines how often particles are created or "emitted" and can create a particle based on the systems initializers.
• System = changes one or more attributes over the life of a particle and can effect rendering output
  • These systems can update an attribute in the following fashions:
    • A function of the particles life. IE the scale is 1 at birth and 2 at max lifetime.
    • A fixed velocity. IE the rotation is 0 at birth but updates at 45 deg/s
    • A stored velocity. IE the positional velocity is stored in particle data and that velocity is itself updated and used to update the position
    • A functional velocity. IE the rotation velocity is a function of the particles life.
    • A fixed acceleration. IE when a velocity is stored in particle data it can be affected by gravity
    • A stored acceleration. IE each particle can have a unique acceleration
    • A functional acceleration. IE when a velocity is stored in particle data it can be affected by gravity and wind at its position.
  • Examples:
    • Aging = decrements age by dt
    • Rotating = updates rotation. Rotation can be function of a particles age, can be a constant velocity, a velocity stored on the particle, have a constant acceleration, or have an acceleration stored on the particle.
    • Scaling = updates scale. Scaling can be a function of a particle age, can be a constant velocity, a velocity stored on the particle, have a constant acceleration, or have an acceleration stored on the particle.
    • Velocity = updates velocity based on constant acceleration, any global forces, or by acceleration stored on the particle.
    • Position = updates position based on a function of a particle age
• Renderer = Outputs the vertices (and possibly matrices) that are required for rendering. They are then passed to the systems for modification.
• Output = One or more vertices and maybe a matrix that describes a particle.
• Vertex = Has position and possibly: texturing, coloring, normal

Add Remove to Iterator

UI: visibility

a component can go invisible and the parent should be dirty. if there's a layout it should be notified. consider it removed?

Maybe visible, invisible, detached, and removed

UI: refactor outline to shape

UI: remove component

Need to support transitions out. A remove is called and we remove it immediately if there is no remove animation. If there is we add a Removing state to the component and effectively disable it without changing its appearance. Base will need a flag for ChildrenOrdered and when removing from children that is either respected or not. The existing order logic should respect that.

UI: child ordering

Add

• Order() int
• SetOrder(i int)
• SendToBack()
• BringToFront()

UI: cursors

global and component specific controls based on component state that decides which cursor is used (cursor could look different on disabled control, on a draggable portion, on a button with an arrow, etc)

Asset offloading

Keep track of asset references in a scene (on draws/updates it calls Asset.InUse). A date is attached to those Assets. If the user has it configured, they can be deactivated and offloaded after so much time of not being used. We should also add a Size to asset and there's a global target max size and once we go over it we remove the least recently used assets from memory

UI: refactor

• stop passing around theme, expose UI as method on component. Use UI or render context
• add name to Base using id
• add map to UI of named components
• animation factories should all be saved on the theme and referenced in component events using id

UI: polygon shape

Vertices in unit space

UI: layout table

• Columns []{ Min/Max Width }
• RowHeight { Min/Max }
• MaximizeWidth? Maybe something more generic
• MaximizeHeight?

Children are the cells/headers and are lined up relative to the other components in their column/row taking into account the possible min/max width/height constraints on the cell.

Add text properties RenderContext

These specify the defaults, and a component could also have these set to affect its layers and children

Examples

Break out glfw_test into examples. Add more examples for 2d & 3d

UI: transparency that all children inherit

multiply alphas of all vertices by (1-transparency)

UI: transitions / transform

Something that is on a component and is updated and the vertices of the component are transformed during render and the component is responsible for communicating events to it.

type Animation struct {
  Init()
  Update(Update) Dirty
  IsDone() bool
  Animate(RenderContext, IndexIterator, DataIterator)
}

A component has certain events and can have an animation set on these events or it can be theme wide.

• Show
• Hide
• Focus
• Blur
• Pointer Events
• Drag Events
• Disabled

Transitions can be made between animations by specifying time and easing and a copy is made of the vertices for the outro animation and the real vertices are lerped away from it to their desired value.

UI: at order

It should go in reverse order since later children are rendered on top

Space Power Tree implementation

Space Linear implementation

UI: clipping in text visual

And expand clipleft and top to include right or left options. Default is clip right and bottom which means if text can't fit in an area it's located top left

UI: add text indent

UI: html helpers

Convert html looking elements into layers

Inheritable attributes: font styles (sizes, name, alignment, colors, etc), disabled
Specific attributes: background, border, margin, padding, position, relative, sizing, transform

UI: data binding

UI is rendered based on the object and inputs can update the state of an object

Implement Camera3

UI: dragging restricts pointer events

Maybe only leaves, not enter or hovers. Definitely not hovers.

UI: Add component events & refactor postprocessing

type Hooks struct {
	OnInit                func(b *Base, init Init)
	OnUpdate              func(b *Base, update Update)
	OnRender              func(b *Base, ctx *RenderContext, out *VertexBuffers)
	OnPostProcess         func(b *Base, ctx *RenderContext, out *VertexBuffers, index IndexIterator, vertex VertexIterator)
	OnPostProcessLayers   func(b *Base, ctx *RenderContext, out *VertexBuffers, index IndexIterator, vertex VertexIterator)
	OnPostProcessChildren func(b *Base, ctx *RenderContext, out *VertexBuffers, index IndexIterator, vertex VertexIterator)
}

UI: layout inline

Similar to text rendering logic.
Each child component has a preferred size+margins. We are rendering for a specific width so we try to fit as many children on a line as possible and we can horizontally and vertically align the children within their line.

UI: add non-rectangular pointer hover

Add Shape and a cache of the coords on Base when it changes bounds. Use polygon ray casting logic to test if point is in shape.

Space Grid implementation

UI: detached children

• Their placement is relative to parent OR root (dropdown/tooltip is relative to parent, modal is not)
• They are drawn by parent in insertion order
• When they or their parent is detached they are no longer rendered
• When they or their parent is removed the are removed

UX: standard components

Put them in ux package. Let's you easily create buttons, lists, data binding, etc.

Also have theme which details all the default values for all the component options

ux.Button{opts...} ux.Buildable with has Build which returns a type (ux.ButtonBase) which implements HasComponent so you can pass Buildable or a built version as a child to another

UI: generalize supported events

Instead of IsDraggable, IsDroppable, etc (it could get carried away) replace with Accepts()

UI: link ui action to input action system

UI: pass events down to visuals

Add ripple effect for demo

Implement View3

UI: state specific vertex modifiers

So if we want global hover/focus/disabled modifiers they can modify the vertices.

UI: traverse focusable UI with tabs/directions

A component can have physical pointers, names, or it can dynamically calculate next, previous, up, down, right, left.

UI: theme/component colors

When you specify colors in visuals you should be able to pass generic colors like "ThemePrimaryColor" and "ThemeSecondaryColor" or "ThemeErrorColor" or "ComponentBackgroundColor". Basically a user extendable enum where colors can be defined at the component level and theme color and colors can even be state specific (so you can define a background layer once but the color is dependent on the state) and on a state change the layer reports a dirty visual.