flixel
flixel copied to clipboard
HaxeFlixel
Add basic component system for FlxObjects
it can be used for things like animation, movement, path following, flickering, particle behavior, etc.
This would be a huge change, not only regarding API. Flixel is based on inheritance from the ground up. Do you want both approaches to exist at the same time (inheritance + composition)? I think that might turn out to be a mess.
Also, there's no point in a flickering component.
Yeah... HaxeFlixel is definitely an inheritance based game engine. Changing that would be like changing the entire engine. Don't think this is a good idea.
it's only my thoughts. maybe i'll play with it in separate branch, but only after render refactoring
The two patterns aren't 100% mutually exclusive also. If used in the right places mixing the two might reduce clutter and add flexibility
I worked on a form of component overlay, but it always felt like I was trying to make HaxeFlixel into something it really wasn't designed for. I would herald having more flexibility in that regard.
I just wanted to add graphics to the list. It would be so much cleaner if the different kinds of graphic, FlxText, TileMap, TileBlock, etc didn't have to extend sprite. If this were done, it would probably just remove the need for a sprite class altogether, though.
And yes, this would be a bit of a major paradigm shift, but I think it would be a very good one. :P
If people don't want to change the core too much, I do this at a scripting-level with the aid of an hscript pre-processor. In haxe you write "packages" that you can attach arbitrarily to objects (Agent, Dialogue, Sprite, Body, Controller, ...). In hscript you write scripts that you simply attach the packages to and write code for [ add, update, and destroy ] events, and can call the package functions/set their instance data etc. So its similar to unities component system, but not the same as an entity-component system (where you need explicit systems), yet the packages themselves still support inheritance. I like this approach as you don't need to recompile and it supports modding. If people want to write an addon for this, i'll happily share the code.
Sounds interesting, I would like to learn about it.
If people don't want to change the core too much, I do this at a scripting-level with the aid of an hscript pre-processor. In haxe you write "packages" that you can attach arbitrarily to objects (Agent, Dialogue, Sprite, Body, Controller, ...). In hscript you write scripts that you simply attach the packages to and write code for [ add, update, and destroy ] events, and can call the package functions/set their instance data etc. So its similar to unities component system, but not the same as an entity-component system (where you need explicit systems), yet the packages themselves still support inheritance. I like this approach as you don't need to recompile and it supports modding. If people want to write an addon for this, i'll happily share the code.
Ok, the code is here: https://gist.github.com/cwkx/6032771b4e8f5c74e848 - basically you'd just need to change the Instance.hx class to strip it out to remove the physics stuff, and just make it extend FlxObject and it should otherwise do what you wanted and make a good addon. I attached my example player controller script, which is one of my most complicated scripts. And an object can have multiple scripts for modular/complex behaviours.
How does performance compare when using scripting instead of complied classes? Not very familiar witht hscript :cry:
Depends how you do it: the reason I have "Instance.hx" is because instances only get created from a BodyType.STATIC spawner, when they're in the camera region-of-interest, triggered by a InteractionListener - InteractionType.SENSOR. Because I call "pre-process" only when instances are created, where the pre-processor only binds the relevant code from the packages, nothing gets processed or allocated in memory until it becomes "important" (near the camera region). You can easily have 100,000+ STATIC spawners in a scene with no performance overhead. The scripts themselves are sufficiently fast: http://snag.gy/GEi3U.jpg - that's what my game looks like, with 9 FlxTilemap layers, 9 nape physics layers, and about 15 "important" scripts existing and being executed each frame in the update event, and I tested it with 100,000 script-spawner objects in the scene at 60fps.
Your scripting system is very interesting! I wonder if we could add a subset of it to flixel-addons repo.