keyslam / babble Goto Github PK

It's generally a good idea to diminish the number of dependencies in a library.

Middleclass is a complete class library, which has inheritance, mixins and complete support for metamethods, but none of this features are needed for Babble.

Also as seen here it's one of the slowest class libraries (due to the added complexity).

All the uses of Middleclass could easily be replaced with setmetatable and constructor functions

As discussed in Discord:

Namespaces make weak relationships between modules. This means that for dialogue.lua to work init.lua needs to correctly place node.lua in Namespace.node which is a possible point of failure.

You may later revisit node.lua and or init.lua and then dialogue.lua would stop working because it can't find what it's searching for in Namespace.node

Directly requiring node.lua in dialogue.lua would fix this issue, since you can clearly see what file depends on what other file.

Namespaces are generally useful when you need to require tens of files in a single file, or when you have recursive dependencies. But neither is the case, Babble is pretty module and all the files require 1 other file or none at all.

Boolean conditions such as OR, AND, and XNOR could be useful. Including the inverse.

I think it would be cool if we could show nodes (And potentially their transitions) in a graphical manner.
Potentially using a force directed graph.

This could be inbuilt into Babble, or as a separate module. Either one works. I just think it would be cool.

We discussed some of this in Discord, scripts, links and options functionality is pretty similar and could be merged into a single thing.

Components are currently able to return true to continue evaluating the node, or false to halt, which means that the component will be updated until it returns true.

My request is the addition of being able to return a string value, that represents the Node to move to.

This would make it possible for conditions and more complex stuff to be written inside of this nodes

dialogue:coolstuff(function (node, dt, ...)
  if love.keyboard.isDown('a') then
    return 'dialogue1'
  elseif love.keyboard.isDown('b') then
    return 'dialogue2'
  elseif love.keyboard.isDown('space') then
    return true
  else
    return false
  end
end, ...)

coolstuff is a placeholder name haha. Note that any other argument passed to coolstuff will be passed to the callback after node and dt, making it possible to reuse the callback functions as much as possible

Currently all components are stored in one file. This is messy and hard to maintain as the number of components increases.

We should look into a way to easily support and add new components. Perhaps a Component constructor.

Originally link would have a argument to function as a "returning link", in the way that dialogue would snap back to the current node (and position) when the branch finished.

Instead we should handle every link as a returning link, and add a component that notes the end of the dialogue.

This will allow for easier to use and more advanced dialogue.

The node stack will require to keep track of the current components to make this feasible with recurring / looping nodes.

Currently the "current node" is stored at a string.
We should switch to a stack (table) to allow for returning links.

Potentially append recent nodes to the end of the stack so we won't have to deal with insert/remove. We will need to use #stack to get the current node index.

Components with internal values such as pause won't work smoothly with node instances. To fix this each node instance should re-instantiate all the components. Thus making Node's more like a blueprint.

Basically goto("nodeid") short syntax for link(function () return "nodeid" end)