scriptorum / flaxen Goto Github PK

Support native HaxePunk collisions. Provide a simpler way of hooking into all of the Entity.collideXxx() methods.

Document issues here rather than spread out over numerous files.

Current support for hierarchical transformations is limited:

• Create a "parent" entity with Position, Rotation, and Scale
• For each "child", add these shared component instances.
• Then for each child, define a unique Offset relative to the parent's position

This solution does not allow children to apply their own scaling or rotation. So it's pretty sucky. It also prevents children having their own children. Which is mean.

I thought maybe the first problem could be fixed be refactoring the "View" classes as HaxePunk graphics instead of HaxePunk entities and adding a Parent component to indicate the Entity should be added as a graphic to some other entity. However a Graphic cannot specify rotation or scaling, so all this gets us is child entities can use Position relative to the parent and Offset is not necessary.

OpenFL supports hierarchical transformations built in, but that means abandoning HaxePunk which I'm not currently willing to do. So either I need to add my own hierarchical components and calculations (like OpenFL already does), or bring the conversation to HaxePunk to see if there's interest to add such capabilities to that project directly. (Perhaps allowing HaxePunk entities to accept additional entities in a GraphicList?)

Instead of doing newSetEntity("mySet", "myPrefix") I'd like to be able to eliminate the prefix, and have the prefix picked up from the set itself. For example, newComponentSet("mySet", "myPrefix").

Also it might be nice to be able to peel off an entity or singleton from the ComponentSet returned by newComponentSet. For example: mySet.newEntity().

The preloader belongs in Threadbare, which I'm using as my game jam base code.

When referring to time, always refer to them as ms or sec, so that the unit is clear. There are some places that are vague, although some of it is just passing on the vagueness from the dependent libs.

Hey there,

I am learning a ton from this engine, I am working on a similar project. I would like to know whether you'd be willing to add a license to this project to allow for some more freedom in the usage of this code.

Thank you!

Nodes and helper classes that have no use to a user or the rest of Flaxen should be moved into the class that uses them as internal classes.

Add proper physics forces and mass. Rework gravity to work with this.

Note on Flaxen.removeTransitionedEntities: I like this idea, but I don't like how it's implemented.

Move demo XML files to a subfolder, or come up with a cleaner directory structure for dealing with all demo files.

I suspect it has to do with the combination of the optional second parameter combined with allowing Float and Int as typed parameters. Will have to test it some more. For now, stick to Math.random()...

Add an Entity mixin class, so we can extend the behavior of Entities.

Layout system is fairly basic and buggy right now. Reimplement it with an a new manner of cascading/inheriting transforms and/or other properties.

Look into adding some mechanism for creating and caching static components on the fly. Some ideas:

var image = Image.cache("art/mybutt.png"); // cleanest but possibly most work; macro magic?
var layer = ComponentCache.get(Layer, [30]); // easiest to implement but not pretty
var offset = @singleton(Offset.zero()); // not sure if anything like this is even possible in Haxe

It seems likely these techniques will take too much memory or runtime, but I wanted to spend some thought on it. If it's not worth doing, the user is better off caching the component themselves. They could always do something like:

f.newComponentSet("layer30").add(new Layer(30));
f.addSet(myEnt, "layer30"); // would add the same instance each time

Also, add enough parts to put together an in-ECS particle system as a substitute for HaxePunk's Emitter when you want greater control. Examine some particle engines to get an idea of what else to implement and put together a particle emitter demo, or implement an importer, maybe from Particle Designer.

Add Flaxen.getNodeList convenience method.

Also add Flaxen.getNode that returns first matching node and throws an error if there are more or none. That's a more typo-safe alternative to getEntityByName, and doesn't suffer from the hard-to-diagnose issue of having too many singleton entities.

You have a MovementSystem and Velocity there with as an example, but fledge it out with Immutable checking. You've got Friction (drag) but no FrictionSystem. Add components and systems so you can do more basic physics out of the box: gravity, angular velocity, forces.

Also, add enough parts to put together an in-ECS particle system as a substitute for HaxePunk's Emitter when you want greater control. Examine some particle engines to get an idea of what else to implement and put together a particle emitter demo, or implement an importer, maybe from Particle Designer.

Consider moving the default activated systems to their own system.default subfolder, or move non-default systems into a system.opt folder.

Consider moving the default activated systems to their own system.default subfolder, or move non-default systems into a system.opt folder.

Or std. Or lib. Something like that.

Look into supporting alternate frame rates, such as a time accumulator (semi-fixed time step), variable with min/max limiter, and dual frame rates (fixed for physics/game logic, variable for particle effects etc).

Articles on the subject:
http://gafferongames.com/game-physics/fix-your-timestep/
http://www.koonsolo.com/news/dewitters-gameloop/

Objects show as having no properties.

Consider moving into InputService?

Not sure why this happens yet.

When monospace is used and a space character is passed, bitmap text returns "Error determining space width."

Because radians kill my mojo.

The reason you should subclass Flaxen is because f = new Flaxen() doesn't wait for HaxePunk to finish setting up and call the Scene's begin().

1. That's not necessarily an earth-shattering thing. It could be fine! I should run some tests to see if Flaxen and Ash ever get out of sync.
2. It would be reasonable for the Flaxen engine to add a marker to Ash to indicate when this has happened. Either a new component, or adding a field to App.

Add a NapeSystem for integration with Nape physics.

I should be able to pull what I need from this failed Jam attempt of mine. :)

    override public function update(_)
    {
        nape.step(com.haxepunk.HXP.elapsed);

        #if nape // Nape debug
            napeDebug.clear();
            napeDebug.draw(nape);
            napeDebug.flush();
        #end

        for(node in f.ash.getNodeList(NapeBodyNode))
        {
            node.position.x = node.body.position.x;
            node.position.y = node.body.position.y;
            if(node.entity.has(Rotation))
            {
                var rot = node.entity.get(Rotation);
                rot.angle = node.body.rotation * 180 / Math.PI;
            }
        }
    }

Srsly.