Pool of ideas

[loopier]

Opening this issue to list random ideas. Then we can pick any we want to develop and open a dedicated issue for them. Not all of them have to be implemented, it's just a pool for crazy thoughts.

• Load sources dynamically: create sprites with other programs and import them at runtime. (Initial version handled by dd1ce3b and a1c8e1f)
• Camera feed
• MIDI In: I don't see a use for MIDI Out
• Recursive OSC implementation: OSC messages should be able to map to either godot functions or other OSC messages. This way, OSC can be used to compose complex behaviors out of simpler ones. (Will open a dedicated issue because I already did an implementation for it and will explain it there)

[loopier]

• Fade-in Fade-out: characters and scenes
• Groups or Layers of characters/assets: can be easily done with a dictionary, then use a command iterating over them. Render order can be used to create overlays and layers. This would also provide a way to create scenes, by grouping all assets in a scene. Dictionaries are powerful.
• Animation sequences, ranged loops and modifiers: create animation sequences that can be chained. For example, a character can run, jump, stop, jump, run again. Not sure about the syntax, but an array comes to mind. Also, loops could be played in a range, from frame X to frame Y. Modifiers would be also nice, like play direction and speed. Sequences would ideally include that, so a range of run.range(3,end) could be chained to a jump.range(start, 4), or run.loop(3 times) then jump.loop(4 times).

[loopier]

• Image format: can it load and use formats other than sprites? PNGs, animated GIFs, movie files, JPGs, Webp, ...?

[totalgee]

Ideas/notes from meeting today:

• ~selections (special group) - add to/set (nodes or groups):~ #4 (Resolved by 6daa8b2)

• ~other named groups (add to/remove from)~ #4 (Resolved by 5317327 and 6daa8b2)

• macros / dictionary of commands (text archive): #2

• walk in different directions to a specific point

• use same frame for different "directions" when changing between animations

• load images at runtime: #3 (Initial version handled by dd1ce3b and a1c8e1f)

• shaders (blur, etc) - changing in live coding

• interaction with audio (tempo match)

• bocatas (thought/speech bubbles) -- use child nodes, they follow (Initial version by 7113f89)

• MIDI triggers (chords to do multiple frames, create multiple nodes, ...)

• sounds (e.g. footsteps for walkers, other animation-linked or event sounds?)

• collage

• camera feed

[totalgee]

Ideas/notes from meeting 2021-10-24:

• GF: need to document new commands /def and /wait, plus command script files. (f530f5f)
• Scale rotate actors (bd19350)
• Alpha adjustment (transparency/fading) (6ded14e)
• add support for Animation sequences (in sub-directories) (89ac1d1 and 4273b68)
• Sequencing of animations (go to next when the current one finishes)
  • first: experiment with Animation node in Godot, see what's possible and how it works
  • RP idea: /loop actor anim times first last (GF: or /repeat 3 "/square om1" "/wait 1" "/square om2" "/wait 1")
  • GF: what about looping/repeating OSC commands/lists, or behaviours (may not be just animations). When one finishes, start next (without having to worry about timing/duration).
  • /seq /loop /repeat /do etc... For OSC commands and/or for behaviours and/or animations.
  • FSM vs behaviour tree
• add command to load/reload command "def" scripts (f530f5f)
• Support {1..5} notation in commands (/create om{1..5} om-walk)
• Walk in different directions in ortho view (test using 12x16 (24x8) sprite sheet from Roger)
• MIDI input

[totalgee]

We talked about OSC commands with optional arguments, and where you can get ambiguity with positional (when combined with optional) arguments... One possible solution is to use named arguments, so OSC args would be sent as strings, with the arg name followed by colon and then the value. As an example:

/scale myActor scale:0.5 dur:4
/scale myActor sx:0.5 sy:2

Essentially, args could be a dictionary rather than positional (or some combination). In the extreme, one could send a JSON string with the arguments...