Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: