How to make a game from scratch using Lua and Löve
github.com
github.com
Lua Rocks package manager includes basically every library you could want. Lua doesn’t even include proper object oriented programming, but is so powerful you can add support for it quite easily, and is a good learning experience for aspiring Lua programmers.
Lua is a great language, I wish it was mentioned and compared against more popular languages like Python and JavaScript.
If it helps, you can think 0-indexed as referring to the offset, and 1-indexed as referring to the position. It’s a shame to dismiss the entire language due to what one might argue is a minor aspect.
You can certainly argue it is unfair, but it is still something that increases the risk of mistakes.
Of course, in Pascal you actually can pick any number where the index starts/end.
NodeJS is an obvious counterpoint to my thesis - it’s minimal stdlib as augmented with tens of thousands of NPM packages to implement every feature. This is my preference, but maybe Lua was too early for this strategy to succeed. The vicious attacks NodeJS gets (read about the leftpad.js debacle) because of their philosophy shows that a lot of people disagree with me, but I like the small language augmented with a rich third-party ecosystem.
I don't recall anything particular to comment on small vs big std library. The above complaint would apply to either case
It doesn't matter if either language might not be competitive with Lua or any other language in terms of design / features.
I think Node was in large successful because web developers already have to use JavaScript so the promise of unifying on one language and set of libraries is appealing to many.
OpenResty and Lapis are quite capable in the web space, but they haven’t seen widespread adoption.
I really love the simple elegance of Lua, but the build everything yourself ecosystem made Python and Ruby naturally better choices for larger non embedded solutions.
These days the package management problem has been solved with LuaRocks, but many packages are unmaintained.
The language is so old that it’s place seems to be set and unlikely to change.
I've since used Lua on numerous occasions, and I still love it. But I always reach to Python because of it's pure, raw usability.
I'm actually surprised JavaScript hasn't surpassed Lua for the kind of things Lua is designed for -- but Lua seems to hold on and people aren't generally embedding JavaScript as the scripting language for other programs.
[0]: https://mongoose-os.com/docs/quickstart/using-javascript.htm...
I needed to work on zip files the other day and the Python standard lib included a great implementation with high quality documentation. Languages with minimal stdlibs tend to fall flat on the documentation front, and it adds a lot of friction imo.
Though lua being embeddable is very nice, just coming from trying to embed Python and having a bit of frustration at managing it.
It'd be nice if a package-managed language could import the huge awesome standard library, automatically drop whatever goes unused, and that mechanism worked well enough that everyone but the most restricted embedded programmers were fine with it.
The standard library exists partly because packaging was hard, so it's easier to ship a bunch of stuff. But nowadays it could simply be "core libs" that get pulled in on use.
Quality, available documentation, guaratee of supporting every OS targeted by the language toolchain, and future updates in sync with the language version also matter.
Chez Scheme [1]. It's a R6RS Scheme, so bigger, but Chez has much better embedding support, is backed by Cisco instead of a single dev. Chez doesn't make standalone executables though, because Chez is jitted. It may be the fastest Scheme. It also includes a compiler, a profiler, a great debugger, live memory-introspection, and an enhanced REPL [2] that can dump out it's definitions and any comments into a lovely Scheme file.
[0] https://github.com/gambit/gambit
[1] https://github.com/cisco/ChezScheme
[2] https://cisco.github.io/ChezScheme/csug9.5/use.html#./use:h2
> Whether compiling on the fly or precompiling, the compiler produces optimized machine code, with some optimization across separately compiled library boundaries. [0]
> Chez Scheme compiles source forms as it sees them to machine code before evaluating them, i.e., "just in time." [1]
Chez can both JIT and pre-compile. But it absolutely has a JIT, and has had as far back as I could trace.
Take a hypothetical example: (for ([i (in-range a b c)]) (display i)). At compile time, chez has no way to know whether c is positive or negative (if it is set at runtime), thus making each iteration check whether c is positive or negative. In racket such code has negligible performance impact because the runtime will generate native code "just in time" with optimizations deduced from run-time information.
The JIT of chez is just a side effect of the AOT being fast enough to run on the fly. SBCL does the same.
Huh? Then what do you consider a JIT?
> In computing, just-in-time (JIT) compilation, also known as dynamic translation, is a way of executing computer code that involves compilation during execution of a program – at run time – rather than prior to execution. Most often, this consists of source code or more commonly bytecode translation to machine code, which is then executed directly. [0]
It is just fast enough that AOT compilation isn't a noticeable delay even at the repl.
Cisco says Chez compiles code just before it uses it, at runtime:
> Chez Scheme compiles source forms as it sees them to machine code before evaluating them, i.e., "just in time."
They refer to it as a "incremental native compiler". Incremental compilation happens at runtime. An incremental compiler that runs at runtime is a form of JIT compiler.
> JIT compilation is a combination of the two traditional approaches to translation to machine code – ahead-of-time compilation (AOT), and interpretation – and combines some advantages and drawbacks of both
Everything I know and Wiki says that is a JIT.
Are you saying it isn't a JIT because it isn't a tracing JIT? Bearing in mind tracing JITs came about in the 70s, but JITs themselves are about a decade older.
Do we at least agree that Chez does not generate code at runtime? Because I am very certain it does not (I have spent a lot of time with the chez codebase)
If you still want to call it a JIT then every language that compiles code to an intermediate representation and then executes it is a JIT language,which means just about every friggin language.
I have also ported a non-trivial amount of code making use of rackets JIT optimizations (based on hot paths) to Chez and have spent a lot of time compensating for the lack of the same optimizations in Chez.
SBCL compiles code fast enough to not have a distinct compilation step for most software in a way similar to chez and no one would consider it a JIT.
Edit:
Let me quote Andy Keep (akeep on github. One of chez schemes developers):
Chez Scheme does compile at the REPL, but in general I would not call it a JIT compiler. It just compiles everything the same way regardless of if you are compiling it ahead of time or while you are running in an interactive session.
https://groups.google.com/forum/m/?utm_source=digest&utm_med...
I have found LuaJIT to be about that fast as well, but with quite a lot of exceptions where it is within 1.5x of C. I would say it is still the fastest dynamic language implementation.
The work done by the racket7 folks on Chez might change that though. I have been reading Gustavo Massas patches to chez, and he is a pretty bright guy :D
It is nice to embed though, and is a lot faster than python for things that isn't only using python things that are implemented in c.
T= process(T,
function(element)
if type(element) == "number" then
return element
end
end
) Lua is a great language
1. Arrays start at 1
2. "begin" & "end" instead of {}
3. No ++, +=, etc.
4. No bitwise operators
5. No "continue" statement
6. Uses "~=" instead of "!="
1. array[0] is syntactic sugar for *(array+0). 0 is an offset from an address, not an index.
Lua has tables. Tables have indexes. Indexes start at 1.
2. a design goal was to be easy for new users, not just existing programmers.
begin/end was borrowed from SQL.
3. Less operators is less to learn. New users are familiar with +, -, *, /. Operators like ++, --, *=,
increase the learning curve. x = x + 1 is not hard to grasp.
4. No bitwise operators because no integers. numbers are
floats.
5. continue statement is not necessary, adds more
complexity.
6. Why should it be '!=' and not '<>'
Indexes start at 1.
2, 3.
Using "it's easier for new users" is not a good argument for a good programming language.
x = x + 1 is not hard to grasp.
4. Javascript has bitwise operators even though it only has doubles. It simply casts it to an int32 before doing the operation
5.
Continue is very much necessary in loops like this, unless you want some deeply nested code:
for(...){
if(...) continue;
if(...) continue;
if(...) continue;
if(...) continue;
if(...) continue;
...
}
--
Garry Newman blogged a bit about this too. His game used Lua extensively, but he changed his opinion about it: https://garry.tv/2014/08/16/i-fell-out-of-love-with-lua/.
Now, I don't like JavaScript, but at the moment, it's the best scripting language for embedding out there. I have embedded both lua and v8, and I consider v8 simpler in terms of getting it to work with your code.
for ... do
if ... then goto continue end
if ... then goto continue end
...
::continue::
endIt's not my opinion. In any area other than programming, the term index has a specific meaning and indexes start at one. The term used in C for arrays should be called an offset, not an index. It's the wrong word. We called 2^10 a kilobyte too, even though kilo means 10^3.
2. Lua's usage of `begin`/`end` was borrowed from "Modula" according to the HOPL paper[1]. Probably Modula-2, but the timeframe would not exclude Modula-3 as a possibility, though I suppose it doesn't really matter.
3. I find this to be a poor argument, but I've never felt like I was missing out on a whole lot by not having modification operators in Lua, either. It's not something that comes up often enough that the couple extra keystrokes should be a deal-breaker.
4. Lua added integers alongside flonums in 5.3, along with bitwise operators, but it's been possible to configure Lua's number representation at compile time for as long as I can remember. Prior to 5.3, anyone with a usecase that really necessitated bitwise operations could easily add them with a dozen lines of C code, or they could use LuaJIT which has offered bitops for some time.
I agree completely with points 5 and 6; nothing to add there :)
why the heck not have both? x += y is more elegant than x = x+y. I understand not including ++ (Python) to not enforce 1 as a standard value, but it also doesn't seem to help anyone.
Also the barebones standard library wouldn't be much of an issue if there would exist a stable ecosystem, LuaRocks is one attempt but fragile at best.
Thank goodness it didn't. The number one benefit you should get from a scripting language as opposed to a compiled one is higher productivity – otherwise, you could just write it in C and have higher performance and lower resource usage. What good is a scripting language where I have to either implement every utility function myself, or look for and include an external library? Lua does not even have a round() function! [1] You can't just write print(some_table) [2], which makes using the REPL needlessly burdensome.
Sure, as an embedded scripting language in very small, resource-constrained devices this is a good strategy, but that's a niche application.
Even worse is the "arrays are hashtables in disguise" concept, because even though it might appear to be elegant, it doesn't work well in practice. In the end, you have to treat arrays and hashtables differently (see, e.g., pairs() and ipairs()), because – big surprise – arrays and hashtables are very different conceptually, so you don't gain much from unifying them.
Also great is that if you set element #5 in a 10-element array to nil (maybe you write foo[5] = arg1, and arg1 comes from a caller), your array suddenly only has 4 elements. That's because the first nil in a hashtable demarks the end of an array. Similarly, you might get an array argument from a caller, check its length (4 elements), append a single value, and suddenly your array has 10 elements, instead of 5! That's terrible design.
[1] But it does have functions to convert degrees to radians and back. How is that more important than round()?!
[2] Lua will just print the address of the hashtable, which is completely useless if you want to see its contents.
I don't think I complained about the Lua interpreter itself?
> it's not because it's designed to be easily embeddable that it doesn't work just fine on its own.
I don't understand that sentence.
What is the problem you describe about Lua? That you can't just say "import module" and have many modules available? Sure you can if you have a distribution that provides them, which I think is the kind of thing that the previous comment was referring to. What's the big difference with Python?
I guess the lack of round function is surprising too, but the explanations I see online about it being a minimalism and ease of implementation make sense. I think it's a fair choice and I don't think a core library's choice should be an argument to judge the whole language.
1) A minimalistic scripting language is appropriate for a few niches only, therefore Lua would be a bad replacement for Python in most cases.
2) Missing basic functionality (e.g., printing the contents of the language's fundamental datastructure) decreases productivity, the one thing which scripting languages are supposed to excel at.
3) Pressing arrays into hashtables-as-arrays-but-not-really is a very bad, unnecessary design decision with few upsides and many downsides.
> I guess the lack of round function is surprising too, but the explanations I see online about it being a minimalism and ease of implementation make sense.
I have read those implementations and they are all unsatisfying:
1) The "minimalism" argument: How is that consistent with the existence of math.deg() and math.rad()? Both are easier to manually implement and less rarely used than round().
2) The "ease of implementation" argument: The C standard library actually provides a round() function, so binding it would be negligible in terms of both resources and implementation effort.
> I don't think a core library's choice should be an argument to judge the whole language
The lack of round() is symptomatic of Lua's standard library, it's not a singular example. Another one is that there's no function to copy a hashtable (neither for shallow nor for deep copies). How can a language offer such a bad support for its most important datastructure?
As I understand it, neither lua nor python are compiled languages, they're both dynamic, scripting languages. Which one do you think is a compiled language?
OP is saying that since Lua is cumbersome to write you might as well write in C and get increased performance.
That this bubbled up, sums up the true power of javascript. No good arguments, but lots and lots of people who know and use it. Lua should just attach itself via script converters to that ecosystem and convince via time and better syntax the unwashed masses.
My knowledge of Lua is limited, however, so could you elaborate on the comparison criteria? I mean I wouldn't personally compare Python and Javascript. To be honest I wouldn't compare Javascript with anything.
Python's design is around readability. It is interpreted, while Lua runs via a VM. I guess they are both extensible, although I don't have Lua experience in this area to compare. Would you care to add a bit more information?
"Lube" is used in non-sexual context. You can escape the puritan "inappropriateness" by referring to mechanics.
Also, how about replacing all sexual names by something else? A little sed script should be enough, right?
Also, it's easy to say "oh kids, just tell them it's a joke", but in today's society, that is the kind of thing which could easily get one fired. If just one library was named sexually, it would be easy to say "oh, you are misreading that", but the pattern is obvious.
It's illogical, but emotion often trumps logic and rationality.
These guys can live on code, hentai and ramen alone for months- and that is not a clichee.
My suggestion is to introduce a safe version of code and documentation via a repository and offer to get them any library they via that central repo.
Yes its more preparation work, but its going to keep the project alive.
Github wikis can be cloned, https://help.github.com/articles/adding-and-editing-wiki-pag...
But it doesn't look like github wiki pages can have issues/comments associated with them.
One thing that also made me laugh a lot (despite some people labeling it as unprofessional) is the funny love-related names people give to libraries. Stuff like: HUMP, Gspot, flUIds, Polygami, Swinger, Love Bone, etc. Such a funny community :D
I always wondered how to make an open source game but still sell it. This seems like a plausible way to do. Hope you have a decent income from it!
That said, Love is a really great framework and I always wish there was something like it for Go. While I like Lua, I prefer compiled languages and I think Go could be nice for games but it is still lacking in that domain.
edit:typos
I think raylib is really great. It is very comparable to Love in greatness :-) and I keep recommending it to people.
However the go bindings have one problem (all go bindings for game frameworks i know of have this problem): it is not so easy/impossible to leverage the build target capabilities of raylib. E.g. the web target will just not work at the moment and the mobile targets will also involve a lot of fiddling.
It is cool to play around with but if you really want to make a game and deploy it to many targets none of the current go "solutions" is great. Maybe "ebiten" is good in this regard but there are some other showstoppers for me (no shaders.. etc.)
Other things on my list to try are Phaser for the easy cross platform distribution (it's JavaScript) and Godot, because although I enjoy coding little games "from scratch" I feel like I would be much more productive with the tools that Godot or Unity offer.
Here's my little game: https://github.com/dj/dinojump
A much better approach would be to calculate how much extra time we have and then sleep that long (optionally minus 1ms to allow for that rare case where you get 2ms sleep). This can be #ifdef'd for non-Windows platforms only.
I don't really see why this would be a problem for a game which, while running, is generally the most important process for the end user anyway. Of course for services and such background tasks this would be intolerable.
Regardless it is a good thing to avoid over-computing. It helps those with lower powered computers or people on battery-powered machines.
I haven’t thought much about what languages to use for the ports yet but maybe I will give Lua a try.
I want to target iOS first. Personally I am excited to port it to iOS but not so excited about Android because I want to try Swift and because I have an iPhone whereas my Android devices were all disappointing and I don’t like Java.
According to https://love2d.org/wiki/Game_Distribution it is possible to target both iOS and Android with Lua + Löve. If it turns out to be comfortable to work with and sufficiently performant I would prefer using Lua and Löve to target both of iOS and Android instead of Swift and Java respectively.
Has anyone here had experience writing for iOS or Android with Lua + Löve? Did it work well both in terms of tooling and coding and performance of the finished game?
As a non-game developer, it's been one of the most invaluable resources I jump too when trying to optimize something.