LÖVE

After spending months creating various editors for my engine, I decided to try and create some prototype entities and a behavior module so I can make enemies easier. It's a lot of work. What I have right now isn't perfect. I'm not trying to replicate Mario Maker as much as I'd love to be able to implement a lot of the stuff it does. For instance, the stacked entity recursion doesn't work as well as it should yet. So stacks with more than 2 entities don't work right. Notice in the GIF above how when the blue Shyguy catches the white one with the black one on top, the black one falls off instead of coming with the white one like it should in theory. Maybe in time. I've had to take advantage of a lot of Bump checking and sensors to get a single entity working like it does now. All those Shyguys are a single prototype with different flags set. That way I can just drop the behavior module into an entity, set a few flags and have a mostly working enemy or other entity.

Just trying to figure out a good way to create behaviors was hurting my brain so much that I was tempted to just shelf the project again and switch to a top-down engine instead. Possibly my 3D RPG engine which I am still proud of. I might use some of its technology in this game actually. I have a plan to make a 3D overworld like NEW Super Mario Bros. U using the 3D World library I made. And maybe a Yoshi's Island style title screen with a 3D rotating island or something.

Jasoco does it use ECS?

I don't know what that is.

Entity-Component-Systems... which can mean a dozen things really.

Is there an ECS library that might be useful or was it just a general question? I like writing my own stuff, but am not opposed to using libraries if they work for me and it's easy to implement into my own code and I don't really want to write my own. (Like Bump, Cron and Flux)

A ECS is basically when your entities are just tables of data. It makes things easier because whenever you want a new entity you just make a table of components. For example you can make a dog entity by giving it a sprite and position and physics components. The ECS then based off of the components of the Entity will pass it to various systems you define. One that I know a couple people use is tiny-ecs. Although if you don't already, it might require you to do your updating in draw. Or atleast that's what holo and karai do with their LDs.
https://github.com/bakpakin/tiny-ecs

Some examples that I know use ECS are
https://github.com/excessive/ludum-dare-34
https://github.com/excessive/ludum-dare-33

I'm sure there are plenty of others who use ECS.

bobbyjones wrote:A ECS is basically when your entities are just tables of data. It makes things easier because whenever you want a new entity you just make a table of components.

What i meant before with "...which can mean a dozen things, really." was that ECS may to refer to a few other similar but not quite exact designs as well, not just one. For instance. Also wiki.

• Should the entity be just a number, or should it be a table having keys as component names, and values as references to those components (tables)?
• How would one handle state that should be accessible by more than one component? (The GPP article does mention two solutions, and both that and the wikipedia link say that there are multiple solutions)
• How would multiple systems work relative to each other, if multiple ones modified a shared component('s field)? That is, would the order, which the systems would be executed in, matter?

Things like that are the interesting questions

I am working on a game. The objective is to drop bombs on the enemy's. So you move the plane with the arrow keys and you drop bombs with the space bar.

New level editor for loophole, a puzzle platformer.

I'm working at a simple game, due by end of february and I start to get paranoid. Are you watching me?
My game will feature a dog and use an ECS.

I mostly read the ECS stuff by t-machines (http://t-machine.org/index.php/2007/09/ ... nt-part-1/), which made sense to me. I had a brief look at tiny-ecs and another one, but they work very differently from the t-machines approach, so I started to implement my own, as simple and minimal as possible. No OOP, no nothing, not even an entity table. If it works out I might make a library out of it, but I guess that would make it a bit more complex.

As for the game, there is no game yet, just basic game states thanks to hump.gamestate, sound thanks to SLAM, a simple menu thanks to SUIT, asynchronous resource loading during intro video playback thanks to love-loader and the awesome löve 0.10.0 video playback capability and that's it so far. Oh, and really crude concept 'art':