LOVE Critical Development Suggestions and Comparision.

[Zorbatron]

I'll make this short.

There are some things the absolutely have to be added to the engine before it can ever reach v 1.0.0. I'm not sure if the dev team is aware of this or not, but I want to throw it down here for good measure.

I will be taking a look at the LOVE source to make efforts towards implementing the things listed below. All the below things can technically be more or less implemented via lua, however, for all practical reasons including performance reasons they should be implemented into the engine core.

• 2D Scene Manager - I recommend something dynamic like a loose quadtree implementation such as the one featured in this 2d engine (their project is not open-source thus lame)
• Simple Built-in Entity System - This would probably go along with the Scene Manager, Physics, and Drawing. Entities are objects in the game that act as engine objects and can be drawn and physically simulated and are handled by the scene manager. Entities can be given collision groups, layers, physical properties, and can throw togglable callbacks from things like physics and user mouse clicking. I can't think of any game that wouldn't need to implement an entity system of some sort to function effectivley.
• Built-in Camera Functionality - A basic system supporting moving and scaling cameras as well as multiple cameras.

I haven't gotten to look at the source code just yet, but I'm sure there are some internal memory related issues that need to be addressed as well.

The engine would really progress if these things where handled and it would certainly allow users to focus on developing their game rather than worrying about implementing low-level functionality.

[kikito]

I'm sorry, but I don't agree with the first two points.

A scenemanager for a 2D game seems overkill. What reasons are there to use it on the first place?

The performance gain isn't so big once you take into account the time it takes to interchange data between C++ and Lua. I'd rather have (several) entity-managers done in Lua rather than having one hard-coded into LÖVE.

I agree with the camera functions. The thing is, they are already implemented. Have a look at love.graphics.setScissor, love.graphics.push, love.graphics.pop, love.graphics.translate, love.graphics.rotate, love.graphics.scale.

[Robin]

• Built-in Camera Functionality - A basic system supporting moving and scaling cameras as well as multiple cameras.

You mean as a higher level above love.graphics.push, love.graphics.translate, love.graphics.scale, love.graphics.rotate, love.graphics.pop?

EDIT: got ninja'd by kikito

[zachwlewis]

Yeah, I was going to say that, even larger frameworks like XNA don't have that stuff. You've got to write what you need depending on the game.

They do have support for RenderTargets and custom blend modes, though...

[Zorbatron]

I'm sorry, but I don't agree with the first two points.

A scenemanager for a 2D game seems overkill. What reasons are there to use it on the first place?

The performance gain isn't so big once you take into account the time it takes to interchange data between C++ and Lua. I'd rather have (several) entity-managers done in Lua rather than having one hard-coded into LÖVE.

Do you honestly know what you are saying or are you making things up? The performance gain is huge and is an absolute requirement for any professional product with moderate to large levels and a fair amount of objects in them. The functionality for this behaviour already exists in Lua. They're called user data and can bind engine objects to lua easily. I don't understand why you would want a scenemanager made in lua rather the core, it would probably be n^3 times slower (where n is the number of entities) than the engine implementation.

However, scenegraphs where not invented purely for optimization's sake either. They can be designed to implement a hierarchical system in which objects in the tree (called entities) can have child entities that can move relative to their parent. Changes to the parent node would also pass down to its child nodes. Position, scale, rotation, and other elements would flow down the tree when applied to a parent. Every 3D engine has a scenemanager with the hierarchical system I described and there are other 2D engines which follow suit so I don't see why it can't be done here. I can't think of one project that would not benefit from it. This takes a lot of the love.graphics.translate/push/pop grunt work out of the picture considering you'll end up implementing something pretty much identical on your own anyway.

I agree with the camera functions. The thing is, they are already implemented. Have a look at love.graphics.setScissor, love.graphics.push, love.graphics.pop, love.graphics.translate, love.graphics.rotate, love.graphics.scale.

I've already made a camera system with LOVE, even before those functions existed by overriding the draw functions. My point is this shouldn't be done lua side and would be much faster (for multiple cameras) to be done engine side instead. Though this feature is sort of minor compared to the first two.

Yeah, I was going to say that, even larger frameworks like XNA don't have that stuff. You've got to write what you need depending on the game.

They do have support for RenderTargets and custom blend modes, though...

XNA isn't really a game engine by itself. It's like a bare-bones setup for anything really and was really just intended to let people make things for xbox. People complain often about XNA's lack of robustness.

[kikito]

Do you honestly know what you are saying or are you making things up?

I'm making things up.

It would probably be n^3 times slower than the engine implementation.

Do you honestly know what you are saying or are you making things up?

However, scenegraphs where not invented purely for optimization's sake either. They can be designed to implement a hierarchical system in which objects in the tree (called entities) can have child entities that can move relative to their parent. Changes to the parent node would also pass down to its child nodes. Position, scale, rotation, and other elements would flow down the tree when applied to a parent. Every 3D engine has a scene-manager with the hierarchical system I described and there are other 2D engines which follow suit so I don't see why it can't be done here. I can't think of one project that would not benefit from it.

What is applicable to 3D isn't necessarily applicable to 2D. For instance, rotation needs some sort of "top-down-ish" perspective to work properly; otherwise it isn't usable unless you also have a 3D-to-2D projection system. Scale isn't a typical thing that you change in 2D - at least not individually: the most common scenario is having one single camera for drawing all the objects and then another for the GUI. Position calculus might get some benefits from this, but I would not expect any dramatical performance increase then - once you take into account that the scene-manager would also need some managing code.

I could probably think of a game that would immensely benefit from this. But my point is that for the average game, the gains of that system would be negligible. I'd rather have the developers spend their time on something more mainstream.

The fact that other engines provide this just doesn't impress me.

On my view this is more like a "nice to have feature" rather than a "critical requirement", i.e. for LÖVE 2.0 or 3.0. But I'm open to hear other arguments.

This takes a lot of the love.graphics.translate/push/pop grunt work out of the picture considering you'll end up implementing something pretty much identical on your own anyway.

What do you mean by "grunt work"? You should not be making more than 2 or three calls to these per draw.

I've already made a camera system with LOVE, even before those functions existed by overriding the draw functions. My point is this shouldn't be done lua side and would be much faster (for multiple cameras) to be done engine side instead. Though this feature is sort of minor compared to the first two.

I don't understand. This is done by the engine itself now. What do you have in mind?

[vrld]

2D Scene Manager - I recommend something dynamic like a loose quadtree implementation

What now: Scene Manager (Tool to model logical relationships between objects of a scene) or a QuadTree (Tree where a node can have 0 or 4 children which [usually] divides the space in squares for a number of purposes, such as fast collision detection, culling and path-finding). A Scene Manager can easily be done in Lua. I doubt the performance gain would justify the complexity of an implementation in C++. If you are worried about performance, you could give LuaJIT (http://luajit.org/performance.html) a try. This benchmark is impressive.

However, scenegraphs where not invented purely for optimization's sake either. They can be designed to implement a hierarchical system in which objects in the tree (called entities) can have child entities that can move relative to their parent.

Yes, I believe this is the main purpose of those things.

I've already made a camera system with LOVE, even before those functions existed by overriding the draw functions. My point is this shouldn't be done lua side and would be much faster (for multiple cameras) to be done engine side instead.

What features - other than translating, rotating and zooming - should a camera have in your opinion? How many cameras do you want to use at the same time in a typical game? Again, the implementation complexity would outweigh the performance gain.

XNA isn't really a game engine by itself. It's like a bare-bones setup for anything really and was really just intended to let people make things for xbox.

Now were talking. To quote the FAQ:

What is LÖVE?
LÖVE is a 2D game engine in which games can be made by using Lua scripts. Actually, it's more like a framework or library, but "engine" sells much better. So we lie.

I'd much rather have a lightweight library that makes it easy to hack little games in Lua than a fully featured, totally generic engine of which the most features I will not use.
A personalized engine tailored to the needs of your game written by you would be better anyway.

[zachwlewis]

Yeah, I was going to say that, even larger frameworks like XNA don't have that stuff. You've got to write what you need depending on the game.
They do have support for RenderTargets and custom blend modes, though...

XNA isn't really a game engine by itself. It's like a bare-bones setup for anything really and was really just intended to let people make things for xbox. People complain often about XNA's lack of robustness.

I don't ever recall saying that XNA was a game engine, and I think you're mistaken thinking LÖVE is a game engine. XNA is a framework built on DirectX. LÖVE is a framework built on OpenGL.

I'm not going to argue with you about XNA here (this place is a place for lovers). I was just using XNA as an analogy for the feature parity we should be shooting for with LÖVE.