I'm curious as to how you came to that conclusion. Did you run any tests, or is it just a general observation? What's your computer hardware like? This isn't an accusation of anything, I promise I'm genuinely curious.

I don’t usually push LÖVE to its limits because I tend to make simple games as a hobby but I do keep an eye on its framerate and often it‘s in the 100s of frames per second. So it may not be impressive (in sense of winning benchmarks) but it’s rarely perceivably slow.

It isn't web based? It's a set of Lua scripts that run locally

Are you taking about Lua or LuaJIT (the one used in Love2D)? Because LuaJIT will stay in 2.1 rolling release forever, the language is feature complete, no more breaking changes ever.

they include a LÖVE demo in their documentation: https://dev.fennel-lang.org/wiki/CookbookPong

I love their stuff, but curious if anyone besides them actually use uxn to make stuff

The fantasy computer by 100 rabbits? I love their philosophy, I'm glad Varvara exists, but I'm personally not up to program assembly for a 4-color screen, and I'm sure many others are the same.

I haven't done it myself, using game engines as UI frameworks is not unheard of :)

The project was started by Norwegians. So I feel like you should apply juuuust the right amount of cheesiness and sort of push that Ø-vowel looong. Not sure if Ruud would agree, though.

I am fairly certain it's a case of https://en.wikipedia.org/wiki/Metal_umlaut

I instinctively pronounce it [løv].

The project predates Github, although the first official release came out about a month prior. So, yeah, not a lot of AI slop 20 years ago.

Love2D uses Luajit and directly calls established game libraries. The CPU usage should be far better for 2D games, luajit is faster than a browser's javascript jit. You can also create single exe games that are a few megabytes and not a few hundred megabytes.

Optimized abstraction layer is still an abstraction layer. The web is like two or three of those.

Explain this to electron haters.

As the open source author in question, I'd politely ask everyone to not draw overly-generic conclusions from an ancient discussion in some third-party forum, which links to a (now) resolved bug report.

Open source is not a one-way street. By publicly disparaging open source projects, you're actually harming the ecosystem you rely on.

LuaJIT was originally made with some x86 assembly wizardry so I'm not surprised to hear that the ARM version is worse.

As you aren't posting code or stats I can't say much, but I'd bet a native app would still be smaller and more efficient, since you have to wrap what you're doing in an entire Chromium instance and deal with a web stack designed for documents, which is definitionally less efficient than a native alternative. Tiles aren't exactly cutting edge technology.

"Heavy processing delegated to webworkers?" That just sounds like threads but worse.

Meanwhile that same computer could probably run Counter Strike at 400 FPS.

Cool stuff!

Yes, idk, and of course

I'm really curious how they do version control.

The Steam version was created by one guy, but the platform ports have a couple different authors. The Google Play and Xbox PC versions, for instance, have divergences.

I wonder how the ports influence the upstream and each other. How do they keep the codebases in sync, while also accounting for platform differences?

yep that works

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 19th century are year numbers 18xx, floors below the first have a varying names when they could have been negative numbers, etc.

The reasoning is to be consistent with C and it's more than enough reasoning for me. I don't know if 1-based indexing is fundamentally better. However, I know the probability that I will need to use other languages in the future is 100%, and they'll use 0-based index.

It's like right-click-to-select.

A JIT is a double edged sword, it _can_ make your code faster, i remember in the early days of smartphone gaming, developers often had to manually "warm up" the JIT to prevent stutters during gameplay

It still is an issue nowadays https://discussions.unity.com/t/app-needs-warmup-first-slow-...

Similar story with the GC, it's nice to have, until it causes you problems (wich it will), so you end up having to avoid using it and instead rely on manual techniques

JIT and GC aren't the panacea people make them out to be

> If it were about making a choice of which web framework to use on the server, obviously you wouldn't want to use Lua.

Wait just a minute, there exist many web frameworks in lua, and programmers who enjoy lua might want to use them.

Good news: the universe is written in LISP. Bad news: with no comments.

Well, it's kind of a machine code for a self-modifying compiler, so there's that.

I'm still waiting for the slackers at CERN to finish decompiling it.

that's great, could read the source code on how to unify gravity and quantum mechanics for all energy levels? vibeing to a nobel price will be cool...

It's not really tables all the way down - Lua has datatypes like nil, boolean, number, string, table, userdata + lightuserdata, functions, coroutines. I think that's the entire list, actually.

So a table is a hashtable. Just about anything can be a key to the hash - a number, a string, a boolean, another table, a userdata. I can't recall if functions and coroutines can be keys but I suspect they could. I definitely know that nil can't be an index.

In Lua - all iterators are implemented as a function + state + current key. When you write "for x in (whatever)", that (whatever) is really a function call like func(state,key). Lua calls it repeatedly to traverse the loop.

Lua will take the first returned value and use it as the new key in the next call to func(). Once the function returns nil as the first value (or just returns no values) - the loop stops.

There are two functions - pairs and ipairs - that really just return the built-in next function with a starting key. pairs returns (lua's next(), the table, nil), and ipairs returns (next(), the table, 0).

(there's a bit more to it than that and some under-the-hood changes between Lua versions but we'll just go with that explanation).

Lua repeatedly calls that next() function with the table and previous key.

Say you had an array like table like { [1] = some_value, [2] = another_value }.

When you write something like "for i,v in ipairs(a_table)" that roughly expands to:

  * pairs() returns next(), the table, 0. 
  * Lua calls next(table, 0) and next returns (1, some_value)
  * Lua calls next(table, 1) and next returns (2, another_value)
  * Lua calls next(table, 2) and next returns nil.

So - when is a table an array?

When you can iterate through it with sequential, integer keys.

Note - you don't necessarily need to use ipairs to iterate. Lua also has a numerical "for" loop so you could do that. Or - if you want to start your arrays at 0 instead of one you can write your own ipairs() like function in just a few lines of code. Observe:

  local zpair_it = function(table, key)
    key = key + 1
    if table[key] then
      return key, table[key]
    end
  end

  local zpairs = function(table)
    return zpair_it, table, -1
  end

  local tab = { [0] = 'yay', [1] = 'huzzah' }
  for i,v in zpairs(tab) do
    print(i,v)
  end

There - now instead of using ipairs(), you can use zpairs() with zero-based indexes.

As far as using like objects, that's getting into metatables and stuff but - basically lua has a syntactical sugar to make object-orientation nice.

If you write "obj:func()" - that's the same as writing "obj.func(obj)" - assuming "obj" is a table, Lua will fetch the "func" key from the table, then call it as a function with "obj" as the first argument (this can be referred to as self within your function definition).

If Lua tries to fetch "func" from your table and it doesn't exist - it will check to see if your table has a metatable defined with an __index metamethod (or table) and pull func from that. So - your table could just have your object's actual state data on it, and functions are referenced in a separate metatable.

Observe:

  local dog_methods = {
    bark = function(self)
      print("bark bark I'm a",self.breed)
    end
  }

  local dog_metatable = {
    __index = dog_methods
  }

  local huskie = setmetatable({
    breed = 'huskie'
  }, dog_metatable)

  local collie = setmetatable({
    breed = 'collie'
  }, dog_metatable)

  huskie:bark()
  collie:bark()

huskie:bark() is equivlanet to huskie.bark(huskie). bark doesn't actually exist on huskie, but huskie has a metatable with an __index table where bark is defined. So the function call is really more like dog_methods.bark(huskie).

Anyways wow that was a lot. Highly recommend going through the Lua manual. It's not a long read.

Tables are kinda-sorta hashes that can hold anything, not unlike JavaScript objects. The array use case is just a table with automatically assigned numeric keys.

If you're going to use a table as an array, use it as an array:

    local l = {[0] = 'a', [1] = 'b', [2] = 'c'}
    for i = 0,#l do
      print(l[i])
    end

    .. prints:

    a
    b
    c

Lua haters usually don't get past their misunderstanding of tables, but its really quite unfair on the language and those who have used it quite well to do big things ..

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.

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.

Alright, here is Janet, which is designed to be embeddable just like Lua:

  (set enemies (filter |($ :alive) enemies))

Though JavaScript has QuickJS, which is also lightweight.

Game developers sometimes make the “randomness” favor the player, because of how we perceive randomness and chance.

For example in Sid Meier’s Memoir, this is mentioned.

Quoting from a review of said book:

> People hate randomness: To placate people's busted sense of randomness and overdeveloped sense of fairness, Civ Revolutions had to implement some interesting decisions: any 3:1 battle in favor of human became a guaranteed win. Too many randomly bad outcomes in a row were mitigated.

https://smus.com/books/sid-meiers-memoir/

Some threads on randomness and perceived fairness in video games can be found here on HN too, for example https://news.ycombinator.com/item?id=19399044

The original link being discussed in that thread is 404 now, but archived copies of the original link exist such as for example https://archive.is/8eVqt

The 8-ball joker is even more BS. I think I’ve only seen it trigger once ever.

For a small while I've had the idea of a [game engine/fantasy console/Scratch clone?] that comes packed with a bunch of example games. The example games should be good enough that people download it just to play them, but they are also encouraged to peek into their source code. I'd hope for it to be a sneaky gateway into programming.

For that, I'll keep this in mind: "Unlucky players may look at the source code of a chance-based effect to check if the odds are actually as stated."

I’ve 100%’d Balatro and wheel of fortune is quite strong. It’s never worth taking before you’re at max interest though.

I figured it had been tested by someone more motivated than me, haha, thanks! Will look for it when I'm back at a computer.