- Unlike Godot and others, Flixel has no concept of "nodes", just FlxSprites and stuff, so this will open up a window with all available flixel things that one can insert to the scene. If I pick a FlxSprite, what the engine could do is instantiate a FlxSprite in the current scene class (is tracked), and finally appear in the scene viewer.
- And what happens behind the scenes when an object is added? Well, macros
could come powerful here, but I don't think it's neccessary. If you add
a FlxSprite, the engine could probably add that to some global data structure (persisted in local FS) that keeps track of scenes and their objects. And everyime the project is loaded, the scene viewer and browser would load up that
data structure and render accordingly.
- Example:
- [scene1 => [objectA, objectB, "scene2" => objectC, objectD ]]}
- Each object would have another object representing its props e.g.
- ["x": 1, "visible": true]("x": 1, "visible": true)} where scene1 is the FlxScene or whatever flixel uses for scenes, object* are just normal flixel objects that are loaded into their respective scenes. The scene viewer would load this up, so it finds scene1, looks up its elements (position e.g) and render them accordingly.
- There would be a script icon besides each object's name (I'm taking godot's editor as a reference).So, if I add an object called "foo", the data structure discu ssed would above would pick it up. If the user decides to not use a script, then the object will be normally instantiated and added into the scene, but if the user decides to use a script, then a new class with the object's name (and extends the appropriate class) would be added into the scene's current list of objects. After that, an editor for that object should be ready and the user can freely edit it. (see the snippet below for a little bit more info about this would work)
- There would be multiple tabs, each representing a specific scene. To render a scene, you extract the objects that belong to scenes and render them at their right coordinates (using their x/y props)
- Moving the sprites around with the cursor would just modify the object's internal x/y's
- I think this one is simple, just list everything in
assets
-
Assuming there's something keeping track of the object currently selected, this panel would list all the props of that thing, and modify its props according to the user's input. So I'm editing objectA in scene1, the editor will modify its current list of props (toggle visibility).
-
So what happens when the user runs the game inside the editor?
- Take the example of the DS above, a macro could run through it. E.g, it finds scene1, so it instantiates a new FlxScene and adds code to instantiate the objects that belong to that scene.
Example pseudo code:
class GameLoader {
public static macro function load() {
// we find sceneA, and objectA
var sceneA = macro {
class SceneA extends FlxScene {
// each object could probably have an object of all the props it
// contains so it's easy to add them here
var objectA = new FlxSprite(...);
objectA.option = value;
add(objectA);
// in case that object is a new class that extends another class (i.e a script)
// i'm not sure if that's a good idea, but that could probably be just represented as a string of whatever the user has in the editor, and just load this here... if there are any errors, it's easy to catch.. since all this runs at compile time
}
}
}
}- Catch errors at compile time
- Completion (the macro loader would run each time a change occurs)
- you would have to figure out a way to a render an opengl/other framebuffer into a haxeui widget, I don't know much about that but I think it's doable
There are of course other components trivial to implement:
- Output console
- Help
- ....