Overview of engine ideas about lovr HOT 7 CLOSED

Hey got a request for the ECS side of things. Would it be possible to get nested prefab support?
Example: A prefab within a prefab.

from lovr.

Can you give me an example of what you mean by this?

from lovr.

Hey @karai17 sure.
So I am making the assumption you know what a Unity Prefab is. That is what I am basing this on.
Lets say I have 3 prefabs and a generic script -

A red bird, yellow bird and a crocodile. Each are their own prefab.

The Crocodile is the top level prefab.
While the yellow bird and red bird are nested bellow the crocodile prefab.

Here is what the hierarchy looks like.
Crocodile (Prefab)
| - Red Bird (Prefab) (1 layer deep)
|---------- Yellow Bird (Prefab) (2 layers deep)
| - Generic Script (1 layer deep)

In unity this is not possible At the moment and it is really limiting. If LOVR supported this it would be really beneficial to making the engine a bit more flexible.

from lovr.

From @shakesoda on Slack:

the ecs has nothing to do with prefabs
prefabs would be a tree in the scene hierarchy, that flattens out when you get around to processing it with systems
(our engine works this way)

from lovr.

I have nothing to do with this framework, but this at least seems a bit out of what this framework is trying to do. Like love2d, this is a tiny framework that you build off of. Nothing more, nothing less. This isn't an engine.

But even if I did like this idea, I have a few issues:

• IMGUI? It seems like a weird choice since it's something primarily used for debugging and really rough interfaces, and it's 2D only. Having a 2D only framework is... manageable, but less than ideal. I really don't see the benefits here.

• I see no advantage for a Blueprint-esque system to be integrated. Lua is fairly verbose, but I only feel that a node editor would make it more so. I feel like something like integrated Moonscript support would be neat and wouldn't boggle down development so much since Lua and Moonscript are two sides of the same coin.

• Actually, the idea of a debug mode sounds pretty neat. Only problem is that this would require a prefab system, which I'm not entirely convinced is a good idea. But I still am fond of some thing like a lovr.debug namespace existing.

Oh, side note, hotreloading can be solved by just holding a copy of the unchanged data, then loading in new data whenever you need to reload. If you want to save any changes (like the scene), you need to do this explicitly.

Finally, I do think that LOVR is way too early in it's life cycle to consider transforming it into a game engine. It's come a very, very long way since even 6 months ago, but it still lacks some features vital for making proper, larger games. This is cool, but unnecessary, at least at this point of time.

from lovr.

• IMGUI is great for debugging. While it is a 2D UI system, there is nothing stopping you from rendering it to a canvas and rendering that in 3D space. Are there other GUI libraries that are better suited for 3D?

• Nodes are super handy. You may not personally like them, but they are really good at doing a lot of different things. Designing AI systems, designing shaders, designing other types of systems, etc etc. You may not want to build a whole game with only nodes, but they do serve a very useful purpose.

I don't think timing is particularily important here. Having a quick and dirty framework you can use to get something on screen right away is definitely cool, but having built-in engine tools makes the middle and long term development cycle of your game go much smoother. It might be more immediately benefitial to the framework itself to get a few more checkboxes ticked, but I think if LOVR wants to be more than just a fun little toy, some of these bigger features shoudl at least be thought about now so they can be acted upon sooner rather than later.

from lovr.

I'm going to close this since there hasn't been any activity for a while, and for now I'd like to keep things less opinionated. Lately I've been having lots of related ideas about ways to better integrate developer niceties like hot reloading and VR debug overlays, but I think it's best to demonstrate success in external libraries and then integrate them into the core afterwards.

from lovr.