[HN Gopher] LOVR - An open source framework for rapidly building...
___________________________________________________________________
LOVR - An open source framework for rapidly building immersive 3D
experiences
Author : wsc981
Score : 353 points
Date : 2021-08-06 00:05 UTC (22 hours ago)
(HTM) web link (lovr.org)
(TXT) w3m dump (lovr.org)
| grawprog wrote:
| I have to say, LOVE 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 LOVE2d anymore to anyone interested in getting into game
| programming.
|
| There's just too many high quality alternatives these days.
| dxuh wrote:
| The real alternatives to love are not Unity, Unreal or Godot,
| but maybe raylib or other much smaller _libraries_ (not
| engines). love is much different than Godot and good for
| entirely different projects and different people. The people
| that would probably end up loving love in the long run would
| not be too interested in using Godot at all (such as me and
| many other love 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.
| [deleted]
| bodge5000 wrote:
| 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.
| edflsafoiewq wrote:
| LOVE can do 3D now too.
| bodge5000 wrote:
| 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?
| edflsafoiewq wrote:
| It's regular 3D GL; put vec3s in your vertex attributes,
| write your shader, turn on depth testing, the usual.
| bodge5000 wrote:
| 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
| w_t_payne wrote:
| Have you tried Panda3D, because I've been experimenting with
| it recently, and it seems to work pretty nicely ...
| bodge5000 wrote:
| I haven't, but its on my growing todo list. From what I've
| seen of it, it has a smaller community than LOVE (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
| pasabagi wrote:
| Really? I feel like love 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.
| otikik wrote:
| I am a somewhat LOVE veteran but I have gone in the opposite
| direction: LOVE 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 LOVE.
|
| 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.
| pvitz wrote:
| > 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?
| hypertele-Xii wrote:
| 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.
| [deleted]
| paraph1n wrote:
| Please share the alternatives.
| evv wrote:
| Open Source alternative? grawprog mentioned Godot
| [deleted]
| get52 wrote:
| Godot is great
| andrewmcwatters wrote:
| If you're interested in graduating from LOVE, 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 LOVE 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
| adenozine wrote:
| 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?
| andrewmcwatters wrote:
| 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.
| nonbirithm wrote:
| 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.
| andrewmcwatters wrote:
| 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.
| nonbirithm wrote:
| 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.
| andrewmcwatters wrote:
| 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.
| grawprog wrote:
| 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.
| andrewmcwatters wrote:
| 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
| grawprog wrote:
| 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.
| RaycatRakittra wrote:
| Don't you directly run/contribute to Planimeter's products?
| andrewmcwatters wrote:
| Yes, I also run the consultancy that provides commercial
| support to that group.[1]
|
| [1]: https://www.andrewmcwatters.com
| pull_my_finger wrote:
| > If you're interested in graduating from LOVE...
|
| Isn't your project an abstraction _over_ LOVE2D? Odd way to
| choose to market yourself
| petre wrote:
| > try Planimeter's Grid Engine
|
| No documentation whatsoever besides a sloppy "getting
| started", despite being at version 9. By contrast LOVE has a
| very comprehensive multilanguage wiki.
| andrewmcwatters wrote:
| 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.
| petre wrote:
| Luvit also has okay docs and a ton of examples but they
| are spread between luvit.io and github.
|
| https://luvit.io/docs.html
| jmiskovic wrote:
| 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.
| tudelo wrote:
| Are there any drawbacks that you have experienced? Seems a lot
| more simple than using most game engines...
| bodge5000 wrote:
| 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
| hypertele-Xii wrote:
| VR is just 3D rendered twice (once for each eye).
|
| You can trivially disable VR in LOVR and use it for 3D.
| bodge5000 wrote:
| 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
| wsc981 wrote:
| 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.
| bodge5000 wrote:
| Just what I wanted to hear, cheers!
| jakearmitage wrote:
| 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.
| robertwt7 wrote:
| 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.
| kvark wrote:
| 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.
| alice-i-cecile wrote:
| Have you seen Bevy's new rendering experiments? Very much along
| the lines of what you're describing.
| cmdr2 wrote:
| Nice, I hadn't come across Bevy, thanks for mentioning this.
| For others: https://bevyengine.org/news/introducing-bevy/
| soylentgraham wrote:
| 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)
| ranguna wrote:
| 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
| meatsock wrote:
| heres a good demonstration of LOVR showing a unique selection
| interface
| https://twitter.com/mcclure111/status/1214638887173099520?s=...
| redweer wrote:
| is there any relation with LOVE? https://love2d.org/
|
| I don't see anything called out about this on the website. LOVE
| is a great 2d game framework written in Lua
| [deleted]
| lioeters wrote:
| > LOVR is heavily inspired by LOVE, a 2D game framework.
|
| https://github.com/bjornbytes/lovr
| animanoir wrote:
| Yeha, also that it uses Lua. I think I should try that
| language; always hear good stuff about it.
| memorable wrote:
| The syntax of LOVR looks very similar to LOVE, so I think it is
| heavily inspired by it.
| senthilnayagam wrote:
| have installed the mac version how do I run the getting started
| example on Mac , dragging folder or main.lua seems not running
| anything
| wsc981 wrote:
| What I do is create a symlink of the lovr binary (inside
| LOVR.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.
| senthilnayagam wrote:
| you are a life saver, it works now
| newsyyswen wrote:
| Is this by the same people who made LOVE? The naming and use of
| LuaJIT suggest it.
|
| I love LOVE. 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.
| nonbirithm wrote:
| I believe that if LOVE 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 LOVE because of Lua, I like LOVE because the
| framework itself is so well-designed and easy to use. Other
| people seem to agree to the point of reimplementing LOVE's API
| in Rust, as ggez.
| Koshkin wrote:
| Lua can be embedded in a C project as a library.
| nikki93 wrote:
| 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.
| nonbirithm wrote:
| 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.
| nikki93 wrote:
| 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.
| gavinray wrote:
| 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
| lasagnaphil wrote:
| 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.
| nonbirithm wrote:
| 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
| nikki93 wrote:
| 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).
| qbasic_forever wrote:
| 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.
| wishinghand wrote:
| Would Raylib fit your ideal?
|
| https://www.raylib.com
| wsc981 wrote:
| From what I understand it's made by different people, but the
| LOVR API tries to stay close to the design of the LOVE API.
|
| It can work well for non-VR apps as well by just disabling the
| headset module.
| nabakin wrote:
| 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 LOVE, have started working on this
| project since then.
| apineda wrote:
| 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. :)
| andrehacker wrote:
| 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/
| ungamedplayer wrote:
| 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.
| etaioinshrdlu wrote:
| 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.
| Koshkin wrote:
| But this one is a framework _for_ Lua.
| voxl wrote:
| 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.
| trainsplanes wrote:
| >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.
| etaioinshrdlu wrote:
| In particular, shadow maps, raytracing/global illumination
| were built-into Unreal but basically a Phd project in LOVR.
| jmiskovic wrote:
| 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.
| brainless wrote:
| > 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.
| mastax wrote:
| 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.
| signa11 wrote:
| may you please elucidate why you dissuade the use of lua ?
| thank you kindly!
| lasagnaphil wrote:
| 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.
| vkka wrote:
| 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
| lasagnaphil wrote:
| 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)
| billfruit wrote:
| 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?
| nonbirithm wrote:
| 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.
| etaioinshrdlu wrote:
| 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.
| hdjjhhvvhga wrote:
| 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.
| codelord wrote:
| 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.
| chii wrote:
| > 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".
| semi-extrinsic wrote:
| 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?
| Agentlien wrote:
| 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?
| Jataman606 wrote:
| 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).
| codelord wrote:
| 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.
| Agentlien wrote:
| 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.
| chii wrote:
| > 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.
| teamonkey wrote:
| I suggest trying to make and release one of these "low-
| effort" games to see how much effort is actually required
| jcelerier wrote:
| 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...
| dang wrote:
| One past thread:
|
| _Show HN: LOVR - VR framework for Lua_ -
| https://news.ycombinator.com/item?id=15177549 - Sept 2017 (23
| comments)
| 7OVO7 wrote:
| https://www.virustotal.com/gui/file/a02339a89e1964522325f798...
| TonyTrapp wrote:
| 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.
| alexissantos wrote:
| Any idea if this currently has support for the Vive trackers?
| (Would love to track objects as well as hands.)
| ranguna wrote:
| Yes, it says so in their homepage.
| wsc981 wrote:
| This is an interesting video of some of LOVR's capabilities and
| how it compares to some other popular gamedev SDKs:
| https://www.youtube.com/watch?v=u9cYW6ffkPM
| [deleted]
| billfruit wrote:
| 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?
| zxspectrum1982 wrote:
| Makes me remember POV Ray times. I must be old.
| weswayward wrote:
| 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.
| Verdex wrote:
| 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
| stavros wrote:
| 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.
| finjo wrote:
| 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.
| stavros wrote:
| 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.
| philsnow wrote:
| I want to get my 12 and 10 year old children into
| programming, but I won't show them love because of this
| naming issue. It's otherwise an ideal library for them, but I
| show them pygame/qbasic/logo instead.
| jmiskovic wrote:
| Some of worst offenders have since changed lib names, you
| should be OK if you ever decide to jump back in.
___________________________________________________________________
(page generated 2021-08-06 23:02 UTC)