amour - a basic scene graph library

[alexanderdna]

As the title suggests, amour supports creating a scene graph, basically a hierachical structure for drawables.

GitHub: https://github.com/flatgames/amour
Documents: https://github.com/flatgames/amour/wiki

A piece of sample code:

Code: Select all

local Scene = require 'amour.scene'
local Rect = require 'amour.rect'
local Text = require 'amour.text'

local flux = require 'flux'

local scene

function love.load()
    scene = Scene(480, 320, 'expand')

    local bigRect = Rect(scene.w * 0.5, scene.h * 0.5,
        200, 200, { 0, 0.5, 1, 1 })
    scene:addChild(bigRect)

    local topLeftRect = Rect(10, 10, 50, 50, { 1, 1, 1, 1 })
    topLeftRect:updateAnchor(0, 0)
    bigRect:addChild(topLeftRect)

    local bottomText = Text(bigRect.w * 0.5, bigRect.h - 10,
        love.graphics.newFont(12), 'Bottom Text',
        { 1, 1, 1, 1})
    bottomText:updateAnchor(0.5, 1)
    bigRect:addChild(bottomText)

    bigRect:flux(10, { r = math.pi * 2 })
end

function love.update(dt)
    flux.update(dt)
end

function love.draw()
    scene:draw()
end

function love.keypressed(key, scancode, isrepeat)
    if key == 'escape' then
        love.event.quit()
    end
end

Result:

demo.gif (327.98 KiB) Viewed 10083 times

Dependencies:

• classic: https://github.com/rxi/classic
• flux (optional): https://github.com/rxi/flux

Current limitations:

• No z-index: nodes are rendered in the order they are stored in their parent's child list. This is to make the library simple.
• Transform values must be set using an updateXXX function instead of setting them directly. I hope to fix this in a future update.

Any feedbacks are very much appreciated. Thank you for reading.

[D0NM]

I like the light weight and readability of the user's code.
But I have no idea where to use it yet. Some menu, cut scenes, scene editing....

[ivan]

Welcome to the forums, Alexanderdna.
I think it's a cool idea, in fact I use a similar scene graph in my projects.
I have released my code too - it's not perfect but I hope that you might find it useful:
https://github.com/2dengine/love.scene

I like your idea of using width/height for nodes and querying that against a point.
Had the same feature implemented a while ago, but later decided to remove it.
Nice to see the newTransform object used in your lib!

[alexanderdna]

I like the light weight and readability of the user's code.
But I have no idea where to use it yet. Some menu, cut scenes, scene editing....

Thank you. I think this library is useful for someone (like me) who comes from other game engines that support scene graph (e.g. Unity, Corona, cocos2d-x). It'll make them feel comfortable while getting to know the basics of love2d.

Welcome to the forums, Alexanderdna.

Thank you. It actually took me a few days to figure out how transforms and stuffs work. I am trying to remove the need of updateXXX functions by using newindex metamethod but haven't had success so far. (I forgot most of Lua's infrastructure after years of using other languages.)

Your code is interesting too, and I am going to dig into it when I get home today.

[pgimeno]

The idea is interesting, though I have difficulty thinking about the game as a scene graph. That's also why I haven't started with Amulet, which is a scene-oriented engine with many similarities to LÖVE.

[JoshGrams]

I have difficulty thinking about the game as a scene graph. That's also why I haven't started with Amulet

Interesting. A scene graph is basically just a big list of objects to be updated and drawn each frame, plus support for nesting objects and drawing children in local coordinates relative to their parents. What part of that do you find difficult? Is it the putting-everything-in-a-single-list thing? You can (and usually do) have other collections that aren't related to the nested-drawing hierarchy. How do you usually structure your games?

[pgimeno]

I guess I'm very imperative in my programming style Keeping the scene as a tree sounds like an unnecessary complication to me. It doesn't seem usual to need to transform elements as a block, anyway, and I can do it manually if needed. Tracking what each node means, or finding the node you need to act on, sounds difficult at first glance. I guess that by duplicating structures you could do it, it just seems too convoluted in my mind.

[ivan]

There are significant advantages when scene graphs are used correctly.
In my experience it's really about grouping things together.
For example, if rendering things in order is important,
then you are going to need some sort of scene-graph-like structure anyways.
...or let's say that you want to transform several graphics together.
...or you want to use cameras in your game.
Another advantage is that all the rendering code is neatly contained within the scene graph - all you have to do is port the scene graph and your game could easily work in another engine.
Some people even use the graph for culling and querying things which is another advantage.

Tracking what each node means, or finding the node you need to act on, sounds difficult at first glance

Sure, it can work very nicely, since the graph separates the rendering from the game logic.

I don't want to hijack Alexander's topic, but check out the examples:
https://github.com/2dengine/love.scene