LÖVR – An open source framework for rapidly building immersive 3D experiences | Hacker News Reader

LÖVR – An open source framework for rapidly building immersive 3D experiences

lovr.org

385 pointswsc981122 comments

I have to say, LÖVE 2d holds a special place with me because it's the first 'real programming game engine' (as in language only no accompanying ide or such) I ever actually developed anything that I would consider a fully fledged completed program I made entirely by myself with.

This looks pretty awesome and all but I can't see the benefits over something like unity or unreal or the amazing for the cost and features Godot.

I really like Lua. I've always recommended it to beginners or anyone curious about programming for fun over every other language. I've used it myself extensively

But in this day and age, I can't really see recommendating this or even LÖVE2d anymore to anyone interested in getting into game programming.

There's just too many high quality alternatives these days.

I am a somewhat LÖVE veteran but I have gone in the opposite direction: LÖVE is *too powerful* me :).

I gave PICO-8 a try and ... I found peace.

The strict limitations are strangely liberating. Asset production (one of the most time-consuming parts of game development for me) is a breeze when you are limited to a 8x8 image and a 16-color palette. A similar thing happens with sound and music.

It is the missing link between developing a text-based roguelike and LÖVE.

Then there are a lot of small details like the fact that sin and cos return numbers in the 0..1 range instead of 0..2Pi range. And there is a reason for that (most things in Pico-8 work on the 0..1 range, it saves tokens). And there are "secrets" as well. It might not be something that I would use to create a commercial product, but it is FUN.

It's fun until PICO-8 says "that's enough. I forbid you from adding any more code/sprites/etc."

And then you realize you are being strangled by artificial, arbitrary limits that don't actually have any reason nor justification for existing.

Thankfully TIC-80 offers almost the exact same experience with more lenient restrictions.

> Then there are a lot of small details like the fact that sin and cos return numbers in the 0..1 range instead of 0..2Pi range.

The [0,2pi) interval is rather strange for an output or do you mean the arcus functions?

I've used pretty much every engine there is. Unity for about 10 years, Unreal for not all that long, probably in total about a year (it seems to be the most artist orientated, and with the best will in the world I'm not sure I fit into that camp), and most recently Godot for about 2 years.

But recently, I've been really interested in the idea of a framework over an engine. For my non game-dev job, I of course don't use an engine, I use an editor like everyone else, and the idea of having that kind of workflow for game dev seems really appealing to me.

I've been trying to learn Bevy or maybe Raylib, but LOVE always interested me the most for its incredible combination of performance and ease of use, but didn't want to typecast myself to only 2D. Maybe now, that can change.

If someone wants to get into game dev, I'd recommend Godot or Unity, or possibly Unreal if they're the right sort of person, but if Im talking to another game dev, my first recommendation would be to look into a framework.

LOVE can do 3D now too.

Really? Is that in the way that 2D engines can often "fake" 3D (like someone making a 3D game with pico8) or can it actually handle 3D content?

It's regular 3D GL; put vec3s in your vertex attributes, write your shader, turn on depth testing, the usual.

Oh wow, that's a massive game changer!

Do you have any links? If I just go to the normal Love page I don't see any mention of 3D support

Here's a tiny 3D engine: https://github.com/groverburger/g3d

Oh nice, so this is a fork of Love that just makes 3D easier to work with?

It's not a fork, just a regular LOVE project.

Have you tried Panda3D, because I've been experimenting with it recently, and it seems to work pretty nicely ...

I haven't, but its on my growing todo list. From what I've seen of it, it has a smaller community than LÖVE (which was part of my problem with some of the raylib bindings), but does look very nice.

Personally for me, the dream is a framework that can do 2D and 3D. The game I'm currently working on will most likely be 2D, but I'm experimenting with 3D and its nice to be able to do all that with the stuff framework. I think Bevy is currently my favourite, but I'm always looking for others as well

The real alternatives to löve are not Unity, Unreal or Godot, but maybe raylib or other much smaller libraries (not engines). löve is much different than Godot and good for entirely different projects and different people. The people that would probably end up löving löve in the long run would not be too interested in using Godot at all (such as me and many other löve users that I know).

I don't use it much at all anymore (though I have heavily in the past), but I would still recommend it to everyone for which it would be a great fit. If you just want to have a game running asap, then yes, maybe Godot is a better fit, but it's not categorically.

If you're interested in graduating from LÖVE, try Planimeter's Grid Engine[1], which is based on Quakeworld architecture and comes with fully client-side predicted multiplayer out of the box.[2]

In that regard, it's a lot easier than Unity 2D, which doesn't. It also has commercial support, uses pretty standard de facto formats, like Tiled, for its levels, and has been in development for several years.

It's the most starred Lua game engine on GitHub to my knowledge.[3]

Planimeter also publishes lgf[4], which is a LÖVE 11.3 drop-in replacement which provides PBR support, among other things, out of the box for those concerned with advanced workflows.

[1]: https://www.planimeter.org/grid-sdk/

[2]: https://www.planimeter.org/grid-sdk/api/Tick_rate_and_bandwi...

[3]: https://github.com/topics/game-engine?l=lua

[4]: https://github.com/Planimeter/lgf

I've been using godot for my latest project and I've been fairly happy with it. In the end, the language matters less than what the toolset provides.

Planimeter looks interesting and all, but I find Lua itself to be limiting for large scale programs. It's great as an embedded scripting language.

This is much the same as love or dgame though. The api is nice, but offers less than godot and doesn't provide any kind of IDE or development tools.

When I click tutorials, I get some installation tutorials some small one or two line code about making entities, whereas with godot or unity or even love, and such by the end you've got a small basic game going.

Actually, to go on a tangent about game tutorials in general...

This:

Making an entity

class "npc_monster" ( "npc" )

function npc_monster:npc_monster() npc.npc( self ) self:setSprite( "images/monster.png" ) end

entities.linkToClassname( npc_monster, "npc_monster" )

Is not an entity as planimeter seems to suggest. It's a sprite drawn on the screen.

There is a huge difference between functional entity and that above code that every single beginner, come learn my engine now and make a game totally misrepresents. Same with player code and every other beginner tutorial. It's not the reality of any game. No entity is a sprite with nothing else.

I'm not sure what you're wanting out of an entity, but they provide more than sprites, so your idea of what Grid provides is not an accurate representation of what the engine does.[1]

I appreciate what Godot provides, but we are not interested in building IDEs, because an IDE is not a game engine. We would rather have features that contribute to games than nice editors, which everyone else already builds. Why would we compete with Tiled? Just go use Tiled. We're not competing with 2D animation software either, just go use them, export those files, and see them reload in the engine in real-time.

If Lua is good enough for for major game studios, and nginx, and other software used by the Fortune 500, it's good enough for us.

The point of Planimeter's Grid Engine isn't to provide a game engine for Lua, despite its tagline, it's to provide a game engine that you can build a game with, out of the box, with opt-in multiplayer as simple as setting `maxplayers`.

You cannot do that with Unity 2D. You can't even do it with Unreal. There is no starting up those engines within 5 minutes, launching a server, having a friend connect, and modifying entities in real-time scripting and having them see those changes.

You receive an abstraction over `:spawn()`, `:update(dt)`, and `:draw()`, and can `:getNetworkVar()` and `:setNetworkVar()` for entities, which automatically serializes and sends data and lets the engine perform engine-level, not framework-level decisions on those entities.

They tie into a save restore lifecycle, and have optional physics, that you make a single call to and it's all networked.

Even if you didn't want to do top-down or side-scroller games with this, you have all of the out of the box engine-level mechanics for building card games, strategy games, or anything else in 2D.

To my knowledge, you cannot do that, even with Unreal out-of-the-box.

I think you’re looking at the front-page examples and thinking this is what the engine does, but really it was put up to show a parallel between Grid and LOVE’s front page examples to show how one graduates from sprites, audio, and printing text to networkable entities, emitting networked spacial audio, and creating GUI elements that are composite rasterized.

The fact that they look as simple as they do is the point.

You seem to think this is an afternoon hobby project, but it’s a very old product.

We of course need to update our documentation and marketing to make that all clear, but the parent company has larger priorities and we bring in more revenue than Godot; Grid just isn’t a primary revenue stream.

[1]: https://www.planimeter.org/grid-sdk/api/entity

I wasn't trying to personally attack your engine or anything. I've been there, I've tried many of the comparable frameworks available for games in a variety of languages. They all offer much the same thing. Drawing primitives, physics primitives, vectors, bounding boxes, simple ways to draw sprites or textures to the screen, some basic UI containers, some math functions, a built in camera, some animation helpers, a player class that wraps input, basoc network functions, utility classes, essentially, exactly the same thing most game engines and framework offer.

In the end it comes down to whatever's the easiest, most efficient to use to get a final product. It's the only thing that really matters when it comes to a tool.

If two tools offer the same things, but one tool offers the ability to do it faster, more easily and more efficiently, that's the ideal tool of choice.

Don't you directly run/contribute to Planimeter's products?

Yes, I also run the consultancy that provides commercial support to that group.[1]

[1]: https://www.andrewmcwatters.com

> try Planimeter's Grid Engine

No documentation whatsoever besides a sloppy "getting started", despite being at version 9. By contrast LÖVE has a very comprehensive multilanguage wiki.

OK, thanks for the feedback. Please let us know if you have any other examples you’d like to direct us to that you also enjoy besides LOVE.

Luvit also has okay docs and a ton of examples but they are spread between luvit.io and github.

https://luvit.io/docs.html

> If you're interested in graduating from LÖVE...

Isn't your project an abstraction _over_ LÖVE2D? Odd way to choose to market yourself

Are you still working on that? I saw your comments getting brutalized in a thread about a planesim game a little while ago.

That repo hasn't been updated in over a year. Have there been any success stories for grid-sdk other than what you've used it for?

Yep. Grid Engine 10 is slated to have a lot more infrastructural updates and we’re departing from some technical decisions that should make the developer experience much better.

We are held up by releasing the next version due to existing contracts we’re working on, and expanding the business.

The next version will have explicit commercial support on the website and a community version.

I'm looking forward to it. I've recently started a little game project and opted for Go and Raylib, because I didn't want to use Love2D or Defold. I'd considered grid, but it didn't seem active enough, and I figured if I was gonna settle for Raylib I may as well use go and be able to work a little quicker and with more libraries.

Such a curious thing, how we all want to love Lua so much, and yet it's so cumbersome sometimes to get work done with it. It's the beauty of it, I guess.

I was wondering, are there any games that use Grid? I would be curious to see some real-world examples using the engine, especially the multiplayer component.

Planimeter dogfoods by working on Grid Engine: Sandbox which is a sort of non-game Garry's Mod 2D sandbox which is where the development team makes features production-ready. We integrate with Steamworks for consulting purposes, but will probably not end up publishing there ourselves, and really advise clients to not do it.

We're a bit tied up with with some consulting projects at the moment, so Grid Engine 10 has been in slower development than the last few years.

We're planning on providing commercial licenses for small studios at something like a one-time $999/license with things like out-of-the-box community server support and at-cost multiplayer infrastructure, which is something like $15/yr for roughly 1,000 concurrent players at 20-tick.

I find it to be a competitive advantage that we provide community server browsers in the engine directly (think Source or further back, Gamespy/Quakespy) and no one else seems to do this? We also use the common Gamespy server browser protocol, which is also a de facto standard.

I would be curious as to why major studios don't also do the same, but the answer is that most of them want to control the servers today and not let you run your own communities anymore.

Unity allows Multiplay to basically own that, which I think is telling that they don't care about that developer experience.

Godot has no answer to any of this. You also have to roll your own multiplayer entirely.

Planimeter doesn't compete with Unity 2D mobile games. We try and stay away from that sort of image. Our software and licensing is intended to compete with desktop 2D games.

So there are no released titles? Or at least ones that are publicly playable? I don't see any search results for Grid Engine: Sandbox.

Correct, our two audiences are delivering a professional grade 2D game engine that surpasses what’s possible with Unity 2D to hobbyists with Grid Engine 9 and Grid Engine 10 Community Edition, and then delivering to small studios on Grid Engine 10 Professional Edition.

The company has been around for 11 years and was previously a Source Engine contractor. So if it seems strange that company has been doing nothing for a decade, it’s because it’s not our primary revenue stream, but up until now has been our largest open source product that I plan on commercializing.

It’s a very slow process, but one that I think we can still outpace Unity’s 2D offering on, considering that they do not deliver solutions our organization has needed for several years. And that’s their primary revenue source.

Really? I feel like löve is just amazingly well designed, both in terms of API, and fundamentals. The basic concept of luajit + c++ core is nice, then the API is so straightforward and consistent that you can basically guess most method names and they do what you expect.

What is it missing? I'm honestly racking my brains here trying to think of stuff I've tried to do that was unexpectedly hard, and I can't think of anything. Maybe passing large arrays of vertexes to be drawn can be awkward.

Please share the alternatives.

Godot is great

Open Source alternative? grawprog mentioned Godot

This is cool, but I find it hard to find any use case for it. I did plenty of work as an indie game dev in the past, shipped and made money out of games based on my own C++/OpenGL game engine and also shipped a few indie games with some external indie game engines. Then I moved away from gamedev, but recently started playing around with Unreal engine again and was blown away by how much Unreal does for you. It felt like with Unreal engine, game dev is mostly about art and game design and not so much about programming anymore. Given game dev has become so much more competitive and harder to do than in the old days, and the fact that you can get a AAA game engine like Unreal for free (and only 5% royalty after 1-5M in sales), it doesn't make any sense to use anything else other than Unreal/Unity IMO.

I've watched non-programmer teams start fast with Blueprints in Unreal, but then hit a wall that they can't climb. Especially for mobile. So then the real programmers get handed this hacked-together prototype and have to figure out how to actually make it performant, close to the deadline. Is this still a thing?

* I haven't used Unreal Engine in 6 years.

I've seen the same thing happen in other engines as well (Unity and Frostbite). Not with entire projects, but sizeable deliverables. Luckily most times it's explicitly been treated as a prototype made by designers before the feature is implemented by the programmers. Sometimes, however, you'll have a manager in the middle of the process object that we obviously already have a working implementation.

> game dev is mostly about art and game design

with a lot of low-effort unreal trash games that all look the same and doesn't have good artistic direction nor game mechanics.

I think this is because unreal gives you so much by default that the developer doesn't really push any boundaries and innovate. Case in point : movement from different games made in unreal all feels "the same".

How much experience do you have with Unreal engine and game dev? If you think art-style is dependent on game engine you probably don't know what you are talking about. Modern game engines are pretty much like an operating system, there's little constraint in terms of what you can achieve artistically.

There's definitely little constraint in what you can achieve. But a lot of low effort games are made by only setting up simple game logic and creating a few models and textures. This means they all use the same default lighting calculations, post processing steps, etc. That gives them a similar look.

Contrast this with more ambitious games and you'll usually end up with an array of custom shaders, a stack of custom post effects, etc. That really lets you define a look that's all your own.

> can achieve artistically

of course you can achieve any art style. I'm saying that low effort games you can find on steam, for example, don't do this.

This kind of feels like complaining that you can buy canvas frames and acrylic pour paints, so many people are nowadays making basic pour art / fluid art that looks almost identical.

Is this really a problem? Would we be better of if the process was a lot more difficult?

As a game developer who learned things the hard way I'm happy there are so many great tools now which let people express themselves and share in the joy of making your own digital experiences.

The lower the barrier of entry, the more people have the opportunity to try their hand at game development. That means more developers providing more exciting ideas! It might mean there's more low-effort stuff out there, but there's always been tons of low-effort stuff out there, anyway.

People are often complaining about a lot of poor quality stuff on the market. I don't actively seek it out and I rarely come across it. So, why would it bother me?

I don't think problem is with what is easier or harder. It's problem with tools that give you ready solutions, that make it possible to just use cookie-cutter approach without adding anything from yourself. Actually it's not even a problem it's just a consequence. Of course not everyone has time to write everything themselves, but doing that practically ensures that what you make will have unique feeling.

On the other hand, even if you use cookie cutter approach to game mechanics you could make other stuff more unique (like story or universe).

I suggest trying to make and release one of these "low-effort" games to see how much effort is actually required

that was the same for all those quake III engine games and I remember thoroughly enjoying every single one of them tho... soldier of fortune... jedi knight: jedi outcast and jedi academy... those star trek games...

Some of those games were certainly not low effort, though. The Jedi Knight games for example. I spent a few months of my spare time modding Jedi Knight Academy and from familiarizing myself with the code base I can tell you they put a lot of effort into it. And while it's based on id Tech 3 it very much has its own feel.

This framework is what I use for most of my hobby projects. There are some videos here: https://twitter.com/j_miskov

I went through Unity and Godot before picking it up. I like LOVR because it's so code-based, with boring boilerplate parts hidden away. I'm no artist and I prefer simple code editor to full engine IDE. The Lua API is easy to understand and remember, and even the framework code is simple to read and modify as needed.

Are there any drawbacks that you have experienced? Seems a lot more simple than using most game engines...

It really depends on your use and expectations, if you expanded the question I could answer better. Maybe you expect things like scene manager, asset loader, animation rigging, pathfinding and network syncing to be built in, but LOVE2D/LOVR philosophy is to expose a sane and well thought out low level API and let the community provide the rest, in a bazaar sort of way. To put together something with complexity, you need to look around for various libs, and then design a way to put them together.

Beside this trade off, the one "downside" is that this is largely a single person's effort with small community around it. LOVR is quite ambitious with supported platforms, and some platforms will exhibit bugs. Anyone working on a serious project will have to get their hands dirty with the framework code, which is thankfully rather easy on eyes.

I think others already mentioned that LOVR is closer to raylib than to Godot. Once I experienced the flow of quickly iterating and hot-loading Lua code, I couldn't go back to Godot's flow adding entities in an editor, clicking around their properties, making OOP scripts and compiling to target platform to test.

LOVR's sweet spot for me is making weird one-afternoon VR projects, for example conjuring thousand or so shapes and moving them around in interesting ways. I like having the option to evolve any those projects into something full fledged and more serious, even if it would require a substantial effort. That's just me thought, some other people in community are building a full business/social platform [1] and a full indie game [2] using the LOVR framework.

[1] https://alloverse.com/ [2] https://www.youtube.com/watch?v=HLBAjKQNmFI&

Is this by the same people who made LÖVE? The naming and use of LuaJIT suggest it.

I love LÖVE. It's a great way to throw together rapid prototypes, and Lua is a joy to work with. Exciting to see a 3D framework along the same lines, hope it can work well for non-VR apps.

I believe that if LÖVE weren't inextricably tied to Lua and were instead exposed as a C library that 2D game development would become a lot easier in someone's language of choice. You don't have to muck around with low-level details like initializing SDL or using raw calls to OpenGL, but you don't have to be constrained by the complexity of larger frameworks like Unity. It's like the one proper wrapper API for all the individual hard-to-use libraries.

I don't like LÖVE because of Lua, I like LÖVE because the framework itself is so well-designed and easy to use. Other people seem to agree to the point of reimplementing LÖVE's API in Rust, as ggez.

Love can actually be used directly as a C++ library. It's a bit of work to get the build system going but then you can use the Love API like: https://github.com/castle-xyz/castle-client/blob/7bfffa10e84... -- we used to use the Lua Love and have since worked on porting our engine to C++. It even runs in the web with the same code through Wasm. No Lua VM ever gets initialized. I may create a minimal starter template repo showing an example of this at some point...

Though, for a 'simple C library for 2d (and actually 3d) game development' -- I would highly recommend https://www.raylib.com/. I really, really dig the API design there. One of the main 'downsides' I guess is it doesn't out of the box build natively for iOS -- but the Wasm support makes it run there pretty fine out of the box and raylib-fork can be used to get a native iOS build going with some work. It's got a lot of stuff out of the box including a GLTF loader and skeletal animation.

I was hoping for a C API specifically to use LOVE with a statically typed language, but because C++'s ABI is unstable writing a C wrapper is about the only way for the engine to be bound to other programming languages besides Lua. Also everything needed to quickly make a game is already included in LOVE provided the correct libraries are available in the system, so it's quite convenient.

But raylib sounds pretty simple to use if you want a library-driven approach, and the WASM support is interesting. There was at one point a project that ported LOVE to asm.js but it's since went unmaintained. I was actually able to run one of my >100MB projects on it, but it was pretty unstable and I soon ran into asset size limitations.

Love does work through wasm in the pure C++ approach, have been using it on a project for a bit now. It's definitely better that way vs. also using Lua since you can't use LuaJIT and vanilla Lua running in wasm esp. with a GC isn't geat perf-wise.

Agreed re: C API -- would definitely need a wrapper there. The C++ API is also a bit less ergonomic in some ways than the Lua one (particularly how images are initialized) but also more in others (type checking and autocomplete is great). Lovr (topic of this post) uses LuaJIT's C FFI actually with a C API internally so it's more in that direction, FWIW.

What does "library-driven approach" mean in raylib's case and how is it different from Love's approach? In both cases I just have a CMake project that builds my application to either a native executable (including mobile in Love) or web, with all dependencies vendored, calling functions and using types from either API.

I do think raylib's C API fits this well and with the least impedance mismatch, having used all of them -- Love in Lua, Love in C++ and raylib in C -- extensively. eg. you can directly manage and render vertex buffers in raylib and go down to the 'rlgl' level, in constrast I found Love's default image rendering to have perf issues in web (it uses buffer orphaning) and I had to do something more manual with Love's meshes.

You can use Typescript-to-Lua, which has static types over LOVE's full API and then transpiles to Lua.

https://typescripttolua.github.io/

https://github.com/hazzard993/love-typescript-definitions

A question: would it be too much work to port Love2D to a different embedding language? (I'm currently having looks at Squirrel (http://www.squirrel-lang.org/) I always thought Lua was tightly coupled with the framework, but what you've mentioned seems to imply that's not the case.

Having attempted this myself, the answer is "a lot of work." Even with the classes and bindings separated, there is still a lot of C++ code used in the binding layer, and some of the C++ code is tightly coupled to Lua data structures. If a transition to a C API were to be made, that C++ code has to be put behind a corresponding C wrapper, so basically opaque pointer types to all those classes and functions/methods have to be wrapped to fully support using LOVE as a standalone library.

I still think that a C API would be a better option than trying to fork the project to replace Lua with Squirrel or some other language, so that at least others can have a chance to write bindings for their favorite languages without having to do all the porting work again.

Here is the tracking issue: https://github.com/love2d/love/issues/1640

I don't think it's "too much work" if you really need it or are really interested in doing so and the approach results in incremental benefit vs. one big blob of benefit at the end. It would be quite a bit of work and not super automatic, probably. You have to implement all the files named 'wrap_*' in the Love codebase, kind of. It's definitely possible to start working on a game project to test with and do it incrementally, which is probably strategically the best path and also fun, which can make it worth it. Something like:

- Get direct Love C++ project working without Lua

- Make some level of test cases with it to get a sense of C++ API usage

- Embed squirrel interpreter into test

- Start binding API to squirrel and testing more and more of API incrementally from squirrel

- Port more and more test cases till it's all covered (or prioritize based on need of game(s))

The nature of the thing you are increasingly covering in Squirrel could be a particular game or a set of demos (maybe both).

Check out OpenFrameworks: https://openframeworks.cc/about/ It's a C++ library that uses all the same kinds of libraries as love (and a lot more) but wraps them up into a uniform C++ object model and scene graph. I've used it for some simple 3d scenes + opencv processing and found it very enjoyable and easy to use.

Would Raylib fit your ideal?

https://www.raylib.com

Lua can be embedded in a C project as a library.

From what I understand it's made by different people, but the LÖVR API tries to stay close to the design of the LÖVE API.

It can work well for non-VR apps as well by just disabling the headset module.

I can confirm this was the case 3-4 years ago when it was in its early stages. Although, I wouldn't be surprised if developers who worked on LÖVE, have started working on this project since then.

One past thread:

Show HN: LÖVR – VR framework for Lua - https://news.ycombinator.com/item?id=15177549 - Sept 2017 (23 comments)

I actually have a decent relationship with Lua. It's not my favorite language in the world. But it works.

I hated Love though. Not for any technical reason. I really wanted to use it. But, every damn library seemed to be a play on Anal or Lube.

I realize that's a silly reason to give up on a piece of technology. But it's also silly those things had to have unfortunate names to begin with.

Software names are the worst. Even "highly respectable" library/framework/etc names sound ridiculous. I found the microservices[1] joke video to be funny (in a you have to laugh or you're going to cry kind of way) mostly because the names are so off the wall and true to life in a way that the muggles probably wouldn't believe is accurate.

Saying, "Sorry guys, I just can't get past the names," is totally a legitimate thing to do. At some point you have to be able to talk to other people about this stuff and it's going to help a lot if you can say the names of the things you're working on without dying of shame. And it's not just about common decency. People are going to believe you're messing with them if you say something like, "Oh yeah, I've been working on getting `buttplug` to send ip packets correctly, however it's been giving me some problems."

[1] - https://www.youtube.com/watch?v=y8OnoxKotPQ

Some of worst offenders have since changed lib names, you should be OK if you ever decide to jump back in.

Well, personally, I wonder why you consider sexual names "unfortunate". Sex must be the single biggest thing that everyone does yet pretends not to. I'm not a fan of this "why I never" mindset. It just seems prudish to me.

A library called "huge red buttplug"? I don't love the length, but I'll use it, why not.

We're in a profession where women are constantly exposed to unwanted sexual advances and innuendo. I don't think it's prudish to not want to think about "huge red butt plugs" while programming, unless I'm working on the source code for a butt plug.

Unless someone wrote the library specifically to expose women to it, I think it is. Sex is something common, and this might be my European culture talking, but I just don't see what the big deal is.

Maybe ask a bunch of women developers what they think? Europeans too. If you don't get it maybe it's BS, or maybe you don't know enough.

As a really smart, sometimes empathetic young person I used to think that I could understand most issues by observation, without having to live through them. One of the bitter lessons of getting older is that this is just incredibly irritatingly wrong. The phrase "lived experience" makes me barf a bit in my mouth due to weaponization, so maybe I'll say "walk a mile in someone else's shoes".

EDIT> Try to imagine what it's like to be creeped on almost all the time, everywhere you go. Want to forget for a bit and concentrate on some coding? Nope, the dude you work with is going to giggle about anal something when he's not trying to catch some side-boob or blather nonsense to you because he's crushing hard on his brilliant female coworker.

EDIT 2> I'm okay with kink, but I don't want to be distracted in a professional context saying ridiculous things like "butt blug". It's just juvenile and dumb. I really wouldn't take a pro-sex, anti-prude stand on such nonsense.

I want to get my 12 and 10 year old children into programming, but I won't show them löve because of this naming issue. It's otherwise an ideal library for them, but I show them pygame/qbasic/logo instead.

Every time I look at cool project like this, I add it to github star and plan to play around over the weekend. But then got too busy with something else and just forget that it exist in my pile of interesting starred project in github.

https://www.virustotal.com/gui/file/a02339a89e1964522325f798...

Only one false-positive? That's quite an achievement worth posting here. Snark aside, it's almost impossible to release (non-malicious, obviously) indie software these days that doesn't at least trip two or three AV products on VirusTotal that noone has ever heard of.

This is an interesting video of some of LÖVR's capabilities and how it compares to some other popular gamedev SDKs: https://www.youtube.com/watch?v=u9cYW6ffkPM

For those of you who don't like lua but love LOVE2D and want to try LOVR, you can code in typescript and use this[1] transpiler to turn it into lua. Someone already did LOVE2D type definitions, it shouldn't be to hard to make some for LOVR. [1]: https://github.com/TypeScriptToLua/TypeScriptToLua

I don't like Lua. I prefer three.js and js because that's what I'm best at. That being said I did have some fun learning experiences with love 2d back in the day. This looks like an interesting tool just like love 2d was. I'll be envious of those who can use it to achieve their creative visions. :)

A lot of us hate and loathe javascript. I'm not 'the best' at lua, but compared to javascript it makes me feel like I'm not taking crazy pills.

It seems that A-Frame (built on top of three.js) would be the way to go if Javascript is your thing. https://aframe.io/

is there any relation with LÖVE? https://love2d.org/

I don't see anything called out about this on the website. LÖVE is a great 2d game framework written in Lua

> LÖVR is heavily inspired by LÖVE, a 2D game framework.

https://github.com/bjornbytes/lovr

The syntax of LÖVR looks very similar to LÖVE, so I think it is heavily inspired by it.

Yeha, also that it uses Lua. I think I should try that language; always hear good stuff about it.

I'm stuck between a state of absolute excitement and absolute disappointment, so I've got to ask...

Is this "VR and 3D" or "VR...or traditional 3D". The second one implies its not really "meant" to be used for traditional 3D, but can be, which would be disappointing to me at least.

Edit: To be clear, I'm fairly new to 3D game dev, up until this point I'm far more familiar with 2D, and never done any VR dev, so maybe its the case that a VR engine handles 3D without a problem

I think it’s VR and 3D in that you can choose to develop 3D apps and games on Desktop systems without VR headset or you can choose to target 3D headsets or both.

By disabling the headset module (lovr.graphics.headset = false) the app functions as a normal desktop app.

Just what I wanted to hear, cheers!

VR is just 3D rendered twice (once for each eye).

You can trivially disable VR in LÖVR and use it for 3D.

Yeh that makes sense actually. I guess the control methods would be different, but I can see on the LOVR docs that keyboard and mouse are also supported.

Maybe my concern with it comes with using 3D engines that can "also do 2D", but then when you try to do 2D with them, you find out its a bit of a hack job

have installed the mac version how do I run the getting started example on Mac , dragging folder or main.lua seems not running anything

What I do is create a symlink of the lovr binary (inside LÖVR.app/Contents/macOS) and store the symlink in: ~/.bin

On shell start-up the ~/.bin directory is added to my PATH env variable.

Then I can just open terminal, navigate to project directory and do:

$ lovr .

To run examples or develop.

you are a life saver, it works now

Looking at the API here, it feels very much driven by OpenGL. You create a shader, send some parameters, push/pop some of the state, and bam - here is some rendering.

I'm curious if there is still ideas to discover in the space of code-only 3d engines. Something more tied to modern API concepts, such as render passes and pipeline states.

Have you seen Bevy's new rendering experiments? Very much along the lines of what you're describing.

Nice, I hadn't come across Bevy, thanks for mentioning this. For others: https://bevyengine.org/news/introducing-bevy/

I've gone back to an approach from the mid 2000's where high level i generate the most basic draw calls (setrendertarget,clearcolour) (Draw shader+geo+uniforms) As data, which i can serialise, stream, debug, pause&tweak, generate on multiple threads, etc and then low level batch together, generate pipelines, reduce state change, whatever the renderer needs, or just pump to a gui. Finally starting to build up little libraries of commands (generating text "draw calls", gizmos etc) which work project to project. Not very cutting edge tech, but lots of room for lower level (or even high level) optimising (culling, front to back, transparency sorting etc)

heres a good demonstration of LÖVR showing a unique selection interface https://twitter.com/mcclure111/status/1214638887173099520?s=...

Is there examples or a single page document of how to get start upto a finished working example?

Does it support interactive applications, I mean does it handle inputs? Does it have physics/collision detection?

This is great news! I love Love2D! I just have one gripe with this: "Designed for VR". You see, not everybody wants to put a helmet on their head just to play motion-controlled game. Kinect obviously is not an option as it's no longer manufactured, but there are many toolkits for motion tracking using normal cameras such as webcams most people own. I wonder how difficult would be to add this kind of functionality to LOVR.

Any idea if this currently has support for the Vive trackers? (Would love to track objects as well as hands.)

Yes, it says so in their homepage.

I enjoyed playing around with this a lot, and it was infinitely easier to make progress hacking around than Unreal or Unity.

I got stuck because I couldn't get over the lack of AAA graphics and physics that LOVR lacks, compared to Unreal... Lua also shouldn't be used. It's a beautiful tiny embedded language, but I don't want to use it, and I don't want you to use it either.

>I got stuck because I couldn't get over the lack of AAA graphics

That's an artist problem. Not a programmer problem.

I've used Lua for gamedev before. I've also used C#, C++, Python, and Javascript. Nothing was more fun to work with than Lua. If Unity announced they were dropping C# support and switching over to Lua, I'd probably buy a bottle of top shelf champagne to celebrate.

In particular, shadow maps, raytracing/global illumination were built-into Unreal but basically a Phd project in LOVR.

Just this week I got the shadow maps working in LOVR, so that at least should land into example section soon. Raytracing shouldn't be too hard to get started, just draw a full screen plane using a standard raytracing shader (but it's not well suited for VR because you cannot keep the camera steady while scene is traced). GI is way above my level.

I agree it is much harder than clicking a checkbox in Unreal/Godot. The LOVR exposes low-level OpenGL to Lua, but in a boilerplate-free way, hiding many obscure and obsolete options. This means that there is a steep learning curve, on the other hand you have power to do things differently. Not only the code architecture of project (functional and dynamic VS object-oriented and stateful), but also how you utilize the graphics card. While it can be painful and frustrating, iterating Lua with low level bindings gives you a powerful way to experiment with gfx.

I guess LOVR would mostly appeal to people who want to learn details of hardware, but don't necessary want to create (and support) another engine. LOVR is high quality readable C code and Lua API is well thought out.

Many game development scripting applications disagree with you. Including: DotA Workshop, Tabletop Simulator, Galaxy Editor (for StarCraft 2), and many others unlisted.

Of course, this only matters because you're pretensions about what other people ought to use to develop or script games.

But this one is a framework for Lua.

> It's a beautiful tiny embedded language, but I don't want to use it

It seems like you have some unresolved issues with it. If a language is "beautiful" then, yes, I would like to use it.

Its beauty comes from being small and orthogonal, but flexible enough to expand to accommodate the project. It's great for embedding, batteries-not-included; when you're writing your `class` implementation you can integrate it with your engine's object system.

But many modern engines lean more in the data driven direction. Most or all of the game logic is implemented in config files and the embedded language. You're not writing scripts that manipulate game systems built into the engine, you're building your game systems in the embedded language. Now you want a bit more heft from your language.

may you please elucidate why you dissuade the use of lua ? thank you kindly!

Lua is a language that I started programming with, and has a special place in my heart even if has some crappy parts.

The main issue I have with the language is with table accesses and 'nil'. Tables in Lua are the most fundamental type of object in the language, it can be either an array (1-based index) or a hashtable. In this language objects are basically just tables with fields in them, and with metatables you can basically emulate all the features in a typical OOP language (classes, inheritance, traits, operator overloading, etc.) Field access in objects are just table accesses (like what you can imagine with Javascript).

However, when you try to access a field in a table that doesn't exist (such as 'print(table.key_that_doesnt_exist)'): no errors or exceptions are explicitly raised, it just silently returns nil. This is such a dealbreaker that makes the language much harder to debug than other languages (at least Javascript returns undefined, which is different from null! Oh well, that actually has problems of its own though....) Some more horror: global variables are also implemented as tables (imagine that there's a table _G at the top of the scope). This means that any spelling mistakes with variables will also just silently return nil, since if it doesn't find any variable names at the local scope, it tries to find at the global scope.

The global variable thing was actually such a big problem that people came up with some voodoo metatable trickery script like strict.lua (https://github.com/deepmind/strict/blob/master/strict.lua) that prevents this from happening (a showcase of the language's power, but probably not its proudest). I'm sure you could also do this with table creation (make a wrapper function tbl() that automatically adds metatables to tables to prevent invalid field access, so every time you need to do things like 'pos = tbl({x = 1, y = 2})') But still, there isn't a solution baked into the language, and it's cumbersome to do this (and I'm not sure about the performance implications of this addition).

Right now I'm trying to integrate Squirrel (http://www.squirrel-lang.org/) instead of Lua as a scripting language into my game. Squirrel is an embedded scripting language that's hugely inspired from Lua, but also fixes this shortcoming of the language by making invalid table accesses runtime errors. And when you want to add new fields to a table you need to explicitly do so via the <- operator:

    table = {}
    // print(table.x) (Runtime error)
    // table.x = 1  (Runtime error)
    table.x <- 1
    table.y <- 2
    print(table.x) // Outputs 1

which is much more explicit and less error-prone.

Lua gives you means to build your object system anyway you want. A trivial example to protect a table below:

  local p = { x = 1, y = 2 }
  print( p.x, p.y )
  
  setmetatable( p,
  {
      __newindex = function() assert( false ) end,
      __index = function() assert( false ) end
  } )
  
  print( p.z )    -- you get assertion failure
  p.k = 12        -- you get assertion failure too

I’ve already mentioned how to do this with metatables. But you still need to wrap this in a function and call it every time, it’s quite cumbersome. And the whole thing falls apart when you start using other people’s libraries (For example, you enabled strict.lua in your codebase, but then it starts affecting other libraries which relied on the original Lua behavior… Or you’ve made your own object system, but that one library you’ve imported uses middleclass and another uses rxi.classic, and you need to go though the headache of making sure they’re all compatible)

Lua feels so rigid, inflexible compared to something like JS. If you want abstractions, and want functions to be first order objects etc, does Lua help. Does Lua have "eval" or something similar?

Yes. You can compile Lua code with `loadstring("return 1 + 1")`, which returns a function that runs the provided code. `loadfile()` does the same thing with files. You can also change how the import mechanism works to load compile-to-Lua languages or similar. There are also first class functions and functional programming libraries. I'm personally a fan of luafun.

Usually when programming Lua I can remember every detail of the language without having to consult a reference or wonder which library does what, because it's so simple. I understand that too much simplicity might be an issue for other people, though. I sometimes wish that JavaScript was as simple and easy to understand as Lua is, and Lua is also free of many of JavaScript's warts, but the lack of proper OOP support seemed to kill adoption of the language in projects like Torch. It's still possible to use Lua's prototype-based paradigms to implement OOP, but the implementation details vary depending on which OOP library you choose, and the lack of first-class support is unsatisfying for many people. For me it was more of a mindset thing, and I found I was happier settling for a limited version of OOP or eschewing it for prototype-based programming instead, as it was simpler and satisfied all my needs.

It's the automatic type coercion (strings <=> numbers), the overusage of tables as a universal data structure with bad API, the bizzare syntax.

It might as well be Perl. I don't want you to use Perl either.

I think this would be really interesting if it wasn't lua only.

Makes me remember POV Ray times. I must be old.

I just can't get my head around Lua and it's usage of local. The impedance mismatch caused by using . and : is also terrible. I find it tragic that such a sloppy language design has one of the most impressive JIT runtimes ever written.

Reply on news.ycombinator.com