Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LÖVE: 2D Game Framework for Lua

github.com

Post reply on HN
Print view View original

151–160 of 229 posts

Re: LÖVE: 2D Game Framework for Lua

#151

Post by embedding-shape »

Gigachad wrote: post #102
wwarren wrote: post #2

I love LÖVE. For me it sits at the perfect intersection between high and low level abstraction. Unfortunately the latest released version is getting pretty long in the tooth now and a lot of devs use the latest HEAD from the repo since it has better performance and compatibility. One day the mythical 12.0 will get released for real…..

It’s been a recurring issue I’ve seen in open source where there is active development but no releases. I don’t get why you’d put all the work in to fixing bugs and building features but not hit the button to build a release.

Been there before, usually because you always feel like there is "one more thing to get into the release" before you consider it "done enough", and that keeps moving. At one point, you've diverged far enough from the previous release, either by time or scope, that now you feel like the next release really should come with major improvements because of other API breakages already, so now you want to fit in more, so the next release after that can skip more breakages.

Rinse and repeat over months, with volunteers, in a game engine no less, and I can easily see many projects being unable to not fall into that trap.

Anyways, I think it's less of an issue for people in practicality, most people who use LÖVE today tends to start with the HEAD source version, which also sets them up to easier contribute back upstream, when they inevitably hit something non-optimal, so maybe it works out in favor for everyone in the end anyways.

Re: LÖVE: 2D Game Framework for Lua

#152

Post by embedding-shape »

xigoi wrote: post #141
widdershins wrote: post #134

Earlier quoted context omitted.

It's more minimalistic, that's true. But there's nothing stopping you writing or downloading an array library so you can do this: enemies = array.filter(enemies, function(e) return e.alive end) Or even setting a metatable so you can do: enemies = enemies.filter(function(e) return e.alive end)

Due to the embedded nature of Lua, it’s often impossible or difficult to use libraries. And I don’t want to reimplement basic functionality every time I start a new project.

> Due to the embedded nature of Lua, it’s often impossible or difficult to use libraries.

Last time I used LÖVE that wasn't the case, nor does it seem to be the case today, you can require libraries or even use LuaRocks if that is what you prefer, and everything just works.

Re: LÖVE: 2D Game Framework for Lua

#153

Post by Gigachad »

embedding-shape wrote: post #151
Gigachad wrote: post #102

Earlier quoted context omitted.

It’s been a recurring issue I’ve seen in open source where there is active development but no releases. I don’t get why you’d put all the work in to fixing bugs and building features but not hit the button to build a release.

Been there before, usually because you always feel like there is "one more thing to get into the release" before you consider it "done enough", and that keeps moving. At one point, you've diverged far enough from the previous release, either by time or scope, that now you feel like the next release really should come with major improvements because of other API breakages already, so now you want to fit in more, so th…

The main issue is that distros will only package the latest release. I had a situation where LMMS on their website had download links pointing to the “beta” builds, while the one on all the disto repos was several years behind.

Right now I have a workflow breaking bug in Inkscape which was fixed last year on main but hasn’t made it to a release yet. So my only option is to compile from source.

There being a stigma about a release being “ready” needs to go. Stuff should get only get merged in to main when it’s ready to go live, or behind a feature flag.

Re: LÖVE: 2D Game Framework for Lua

#154

Post by bajsejohannes »

ufo wrote: post #129
bajsejohannes wrote: post #123

Earlier quoted context omitted.

There are arguments for why 0-based indexing is _better_, unrelated to pointer arithmetic. https://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831... > we had better regard —after all those centuries!— zero as a most natural number Of course, a counter argument is that we've already made the mistake of indexing with 1 in natural language (first, second, ...). That decision is not free of annoyances, though: the…

That EWD is one if my pet peeves. Dijkstra makes an unfair comparison because he lists plenty of examples where 0-based indexing is more convenient but ignores the equally numerous situations where 1-based is more convenient. For example, iterating backwards over an array is much better in an 1-based world. I like the argument that 1-based is better for indexing and 0-based is better for offsets: https://hisham.hm/20…

To be honest, I actually agree that Dijkstra's argument seem a bit one sided. It's also interesting to see the argument in your linked article that offset and index doesn't have to be the same.

If I get the root of the argument in the linked article, it is that zero-based indexing is more of a optimization than anything, but I would disagree; there are reasons beyond that (see the examples in my previous comment).

Also, here's an example of an 1-index based system that has caused me some headaches: In music theory, the first note of the scale is called the "first", etc. It also talks about e.g. "stacking thirds", which means take the third of the scale, than take the third from there. However, the offsets are two. (first=offset 0, second=offset 1, third=offset 2). Which is hard to work with in my opinion.

You have an interesting argument about iterating backwards, although I would say; if we need a tie-breaker between the two, iterating forward should have more weight than backwards.

I appreciate your comment, and while trying as best I can to be convinced of the "other side", I still land on 0-indexing. The only argument I buy, is that it matches our natural language starting at 1. Which, of course, is a strong argument.

Re: LÖVE: 2D Game Framework for Lua

#155

Post by 0x3444ac53 »

HiPhish wrote: post #146
rigonkulous wrote: post #127

Earlier quoted context omitted.

There is nothing stopping you from doing someArray[0] = "the first item", you know. For me, the table is extremely powerful. I like it that it can be used as a sparse array, a hash, a vector, whatever. Of course one must know, at heart, the difference between pairs() and ipairs() and what it means for your data, though ..

> There is nothing stopping you from doing someArray[0] = "the first item", you know. Yes, there is: local l = {[0] = 'a', [1] = 'b', [2] = 'c'} for i, c in ipairs(l) do print(i, c) end This will only print the last two pairs. Lua is 1-indexed, end of story. You can store values at index zero, but it's no different than storing values at index -1 or index 'lolrofl'. It does not exist in the array-part of the table as…

I've always assumed that there is some technical reason for Lua being 1 indexed, rather than it being a design choice.

Either way, I think it's a nitpick to complain about. I've written a decent amount of Lua and there's only been a handful of times where 1-indexing was even relevant to me.

Re: LÖVE: 2D Game Framework for Lua

#157

Post by 0x3444ac53 »

emptybits wrote: post #96
opan wrote: post #37

Earlier quoted context omitted.

TIC-80 is a nice free as in freedom alternative to PICO-8, and it allows more inputs, which makes for better Tetris games (gotta have that hold piece).

TIC-80 is wonderful to play in. Besides being free/open, another advantage over PICO-8 is TIC-80 has native support for Fennel. i.e. you can code within the system editor in Lua OR Fennel (or half a dozen other languages!) You don't have to edit and transpile to Lua on the desktop as you would with PICO-8. This has some value in debugging with error messages and line numbers. It's also just plain cool to rock the TIC…

Wait really? I looked into tic80 a while ago and I know it had native support for moon script, but I had to play with it to get fennel to work

Re: LÖVE: 2D Game Framework for Lua

#159

Post by 0x3444ac53 »

onehair wrote: post #40
alprado50 wrote: post #36

Is Love2D a decent option for gamedev compared to Godot? I finished a really simple game using Unity3D and it was fun, but it sucks to use a closed source engine.

Godot will be familiar to you if you then. Löve on the other hand is 100% just code. You'll not have the gui things and the pletora of different components that go with them. Still gives you freedom. Just too much freedom and not as much helpful preset tools.

For me this is a plus. All the games I've made are small and hobby stuff, and I much prefer writing code to playing around with a UI.

Re: LÖVE: 2D Game Framework for Lua

#160

Post by functional_dev »

PacificSpecific wrote: post #19

I generally very much dislike dynamic languages but for some reason I've always really liked Lua. I'm not exactly sure why to be honest. Maybe because you can fit the whole language spec on a single sheet of paper and adding more advanced features is pretty easy. Love looks really cool. I never got into it personally but I still might

exactly, the simplicity is its beauty!

A single data structure (tables), no built in OOP (you build it with metatables).

Coroutines instead of threads.

I was curious and explored it in detail here - https://vectree.io/c/lua-language-design-metatables-coroutin...

Post reply on HN