LDME - Love Danmaku Maker Framework

[zorg]

Me, circa 3 years ago:

So, i skimmed through the forums, saw a few games (or at least talk about games) of this type, but i figured, why not make a framework/engine that could handle games that are specifically this type?
Danmaku or Bullet curtain is a sub-genre of shoot em up games; the gist summed up: "bullets shooting bullet shooting bullets".
The engine will be able to do this list of things after they have been implemented (some of them are already):

• Customizable Resolution, Background, Viewports, Overlay
  Ability to Create new bullets (also behaviours), enemies, bosses, characters, stages, bullet patterns
  Support for multiple Viewports (canvases where the actual game is played, good for versus mode)
  Up to 4 player single-player, utilizing keyboard or controllers (fully definiable, with exception: controllers' d-pads always move characters)
  Per-stage per-difficulty per-character high scores
  Replay system
  multiplayer <- least important

If anyone is interested in helping out with this, let me know; development will be that much faster

So, despite nothing visible happening, i thought that since i've been getting just a bit smarter, maybe i should try this again;

Love Danmaku Maker Engine

This open-source & free framework allows one to make games that are in the bullet hell shooter genre; an alternative to Danmakufu, if you will.

The current (unreleased) version is v0.1.3

Code: Select all

-- Changelog:
-- v0.1.0 (15/07/18)
--     Initial design and codeup - single script works, no real module/file structures.
-- v0.1.1 (15/07/25)
--     Initializer code written, started to code a menu system that was to be a built-in solution, wrote a song for it. Lots of modules written.
--     Using vrld's hump gamestate system for state management (as always)
--     Started working on the script selection screen, used ffi to get a file's last modification time, noticed that the code started to spaghettize.
-- v0.1.2 (15/08/01)
--     Redesigned the code flow, now it's all comprehendable neatly.
--     Made the inbuilt menu be a regular package-type script, just like any the users might create/load up.
--     Created wrapper modules to sandbox and populate the script states with relevant functions and vars.
-- v0.1.3 (15/08/08)
--     Further code cleanups
--     Working script menus, listing of scripts, sorting, dynamic refresh, execution of scripts
-- v0.1.4 (15/08/20)
--     Putting the core up on github
-- v0.1.5 (Planned for 15/08/29)
--     Adding more modules (Layers [Canvas], Bullets, ...)
--     Modifying the default package to use them
--     Further default package cleanup
-- Later Still...
--     Implement an i18n lib, utf8-compatible.
--     Implement at least the generic wrappers fully (that any script type can use)
--     Implement the remaining 5 script wrappers
--     Write logger calls to all modules for faster debugging
--     Implement local multiplayer support (more than one simultaneous player scripts; player dependent functions having player id parameters (think getAngleToPlayer and stuff) )
--     Implement a replay system, that basically just sends the serialized and loaded per-tick keystrokes to the player scripts, and probably the prng seeds as well.
-- After initial release (core + default package + basic modules) ...
--     Implement online multiplayer capability (same as the replay system, but we should pass the ticks around as well)
--     Optimize modules with FFI

The code will slowly creep up to github as well, but i wanted to delay that until one can actually run at least one kind of script with this, and having the wrapped functions be somewhat near DNF's amount. I project that with the slowest speed of 2 days per week of coding, i'll push it onto github around the 29th of august.

Edit: GITHUB REPO

Attached is an early demo showing the yet-uncoupled main and single pattern menus; do check it out!

A Screenshot of the main menu of the default menu "package" that comes with the engine:

(bigger version here)

Some gfycat videos:
The default main and single script selection menus
Testing a very basic single script
Script menus in all their glory (dropbox, not gfycat)

[Davidobot]

Looks neat.
I remember making a danmaku for the second (ultimately failed) LOVE jam: http://davidobot.itch.io/danmaku--fusion-omega

[zorg]

Edited the first post to reflect my coding progress, and i've also added two gfycat links.
This time, i'll continue to be on schedule

[radgeRayden]

I'm interested in this, hope to see the source soon

[ArchAngel075]

Oh the irony that i too love danmaku styled games (though i ultimately suck at playing them)

In the past i was working on a project myself drawing on inspiration from the Touhou series.
Mainly the following ones :
Touhou 06 - Embodiment of the Scarlet Devil
Touhou 07 - Perfect Cherry Blossom
Touhou 7.5 - Immaterial and Missing Power


But i too wanted to make it extendable by users, as i knew i was horrid at planning bullet/enemy AI and events - so i created my engine ontop of LOVE to allow injecting mod packages that allows rewrites of existing packages (mod A extends/overwrites mod B) while treating my 'BASE' bullet and enemy etc code as a mod that can be extended and disabled in favor of other preferred mods.

The result was amazing, BUT as the fool i was i was horrible at optimizations as-well, that and due to many failed class implementations it didn't see completion, But i leave the implementation to you (a obviously more capable person)

My only suggestion is the possibility to use a graphical method of bullet-AI/enemy-AI/stage/level etc designing...

[Wall of ramble incoming]
My method was to use a graph and node system. in its simplest form the user(designer) plots nodes (indexed or named uniquely) on a graph. The graph represents the "game world space" and so can display perhaps a box that indicates the width of the level.
The nodes link like a polyline, and each can specify unique variables that code can access.
Additionally the "code" can be package/level/stage specific or entirely unique to the node (while allowing further plugging into it by the packages used etc)

For instance, i have two nodes named by index [1] and [2].
[1] is at point (0,0)
With variables :
"delay" = 100
"velocity" = 2

[2] is at point (15,0)
With no variables

The code for the system will automatically know to use the variables to determine how the attached object moves - what delays it makes, what velocities it uses.

The most fun part of such a implementation is that technically the 'path-system' designed can be attached to either bullet or enemy. Thus making for some really interesting customizations available while still being easily understandable visually - the best part is its most likely optional to use the visual designer.


If i do find my Node Grapher application i wrote Im wondering if you would like to look at it.


[End wall of ramble]
Anyways, i do greatly wish you luck on making an awsome danmaku framework

[zorg]

(...)

Thank you for your extensive reply; I'll try to tackle most of the points you have mentioned!

Indeed, i'm doing this mostly because of touhou as well.

I had about 3 prior tries with this thing, but all of them had problems owing to me not really thinking ahead, and just creating the structure of it as i went along.

Your approach is similar to what i decided to use, but in a slightly different manner; i'm wrapping a "base" script the user wishes to execute into a sandbox environment populated by functions; this way, i can have short function names (either within sub-categories, or barfed into the sandboxed _G similar to danmakufu).
The bullet / collision / etc. things are like modules, accessible from any script (if the script's type-specific wrapper "exports" it, that is), and i also have functions that can load scripts into other scripts; using a FSM, this theoretically will allow me to build up hierarchies, since i'm guessing danmakufu does it similarly too.

As for optimization, after failing for this reason more than for any other, i decided that this time, i will code neatly, and after everything works, will i only think about optimizing things; and by that, i do mean the FFI

I did think about a GUI script editor, but i concluded that it would only matter after i have something under it, and that it would be mora work than i am willing to risk atm.
And i did think about having each object have a doubly linked list, with movement and other events, having start-(and computed end-)tick information, so we could "seek" via a slider into the script's execution... but i also abandoned this idea, since imo, it's pointless to force this kind of restraint to everything.
And besides, implementing a replay system will be hard enough work for me (though i do want to create an (online) multiplayer functionality for this, but after an initial release; that will have local multi support, though.

I'd be interested to look at your node grapher, if only to see if i could implement something similar into my codebase

Thanks again! I'm hopeful that i'll finish this.

[ArchAngel075]

Ok..
so I Managed to find my old filthy repo setup. It had the two latest builds of my NodeGrapher tool (aka UramuEdit)
One supported exporting files, the other somehow doesnt but then supports bezier curves. Dont ask me how this happened as i coded it a year or so ago.

Ill record a video explaining usage later after collage (And my NVIDIA shadow play updates over the day...)

I did remember one thing about my node graph utility that i didnt like, the .unp extension i created (uramu node path files) made every point the object would be at save during a "preview" - this means LOTS of points and thus very convoluted. The reason in my mind why this method though was to prevent any usage of DT altering say a specific segment. (though now i understand that is falsely assumed)

The best part of my editor was i designed it initially to handle any extension lib user designed. The lib will be fed a series of data that describes nodes and can be left to provide the formatted string to write to file. It also handles the importing ofcourse.

Expect an upload in the next 24h..

[zorg]

So, despite the lack of visible updates, i successfully implemented the default script selection menus.
Since i won't be near my PC next weekend, i'll try to finalize the core, and push that onto github.
After that, tasks will be the addition of many modules, and further default menu cleanup.
I did record a video of it, it's edited into the top post.

[ArchAngel075]

sorry i havent provided my old NodeGrapher video. I decided to remake the utility.

This time focusing on using events (designed in behaviors) applied at times. For instance a behavior can be set to apply forces at times 1s,10s etc. The editor can seek to and playback the motions the affected entity will take, with pause; rewind etc supported.
Also i'm using free coordinates as opposed to nodes that are moved to and from for more freedom - the user/designer themself will need to worry about matching points along axis etc.

Video of this WIP to come in say two days or so once i add dynamic event creation at least (sofar hardcoded adding on load)

As a question (hijacking abit here) what features would you like to see in this visual editor of behaviours for bullets and enemies.
Remember the utility will output a readable events table. ie you can pull an named event from a table such as "addForce" "MoveTo" "ShootBullet" and extra values attached with such names - interpreting those events and values into a game is up to the game designer.

[zorg]

I just pushed the core up on github; will probably not run, but at least it's there.
I'll be back sunday, and will continue the work then.

ArchAngel075: Since you are remaking your utility, you should totes create a new thread for it!
My suggestion for features regarding object behaviours are nil at the moment, but i will think about them.