I made one of the first big commercially successful games with with LÖVE (Move or Die - https://moveordiegame.com/). Highly enjoyed it.
We had a devblog, doesn't exist anymore unfortunately. The thing I enjoyed the most was the flexibility of Lua, and the whole framework seemed to adopt that mindset. It gave you all the core pieces you need it (audio, input, physics, rendering), and then got out of your way.
The drawback to the full flexibility is having to spend time thinking about what design & workflow your wanted (but, really, wasn't a drawback, that's what I wanted, just took more time). We ended up designing a really flexible engine that allowed us to pivot from a 2D puzzle platformer with a story (Concerned Joe) to the action packed fast multiplayer game that Move or Die became.
Off-topic, but your username reminded me of the episode of The Office (yes, the UK one, it's the only one that exists) where Neil (the manger from the Swindon office) brings in a home baked cake. Everybody loves it. David said "I prefer a flan"
Yeah. I'm of the school of though that thinks nearly all web content should be preserved at it's original url. Wayback is a godsend but it should be a last resort.
My guess would be one of the main causes of this is "can't be arsed to migrate Wordpress." I've done that and it's surprisingly straightforward (with a plugin), but I guess FTPing a folder involves less mental steps (so has a lower "activation energy".)
That's a really interesting question. I created some small games with Löve and really loved it. However I always found the whole packaging/distribution/deployment a bit of a problematic topic.
If you don't just want to distribute a .love file (e.g. you do not want your user to get the Löve runtime themselves) this was basically unsupported and you had to come up with your own solutions..
I still think if the Löve community could improve this part it would help the most.
There is nothing built-in for it per se. I think you just have to sign the application from a postbuild hook, I think. I remember discussing this with the person that contributed the Mac build, but I don't remember the result of the discussion exactly. I think that was it though.
That looks very interesting. Thanks for creating and sharing. This wasn't available back when I used Löve. Maybe I should give it another shot. I will certainly try your tool!
oh god, no. Please stop trying to push javascript (and your damned node packages) into everything.
There are community tools to package LÖVE games for win/mac/linux.
(The JS runtime doesn't make it past the salt line while the WASM modules do, causing the the app runtime to fail to find critical exports and go into an infinite loop which persists after Chrome is closed because boot was managed by a service worker)
But you can distribute e.g. a zip file with both the run time and data in it, can't you? How is that any different from how any other game is distributed?
I'll throw in my 3c, it was 2016 and I've been trying to create a fully static x86-64 Linux binary, to hopefully avoid all the problems with DLL hell (as Löve links to an awful lot of stuff, and judging by the .so numbers it was unlikely to work in a year or two). TL;DR I've spent more time fighting the linker than writing the actual games ;)
I didn't want to rely on whatever-version-of-löve-this-distro-has-packaged because Löve at the time would break API compat quite frivolously. You can probably use an AppImage these days but I think this goes against the intent and spirit of Löve. It should be trivial to build entirely self-contained binaries; and in case of Windows/Mac, it was indeed the case (modulo code signing).
It's impressive to see the versatility of LÖVE in action. Flexibility can be both a blessing and a challenge, but it's clear you made the most of it with 'Move or Die'.
LÖVE + Zerobrane for IDE is my single favorite to write software that puts pixels on the screen.
a few reasons why I love it
-Both the IDE and the framework are lightweight enough to run comfortably even on an RPI.
-The single best documentation I've ever used for any piece of development tool. Lots of examples, concise and made for max velocity.
-Excellent forum with friendly people. It has taken a bit of a backseat to project Discord, which I find a bit sad. But everyone is helpful there too.
-Great ecosystem of just about any library you can ask for.
It has kind of spoiled software development for me. I tried getting the hang of similar technologies many times without success. Atleast now I understand the people who still go on about how great their QuickBASIC / TurboPascal workflow was back in the days.
That being said there ARE a few areas in LÖVE that leave things to be desired:
- I feel like the devs are a bit too trigger happy to make API changes. Though fixing a big chunk of these are a matter of a few search + replaces.
- The rendering can feel oddly slow?? Especially on Android I kept bumping into weird scenarios where I felt like it should hit 60 FPS no problem, even with the Lua JIT inactive.
- There aren't many resources about how to make good use of threading features to speed up common performance problems. There is definetly room for a "LÖVE2D Performance Necronomicon" to be written by someone who is more knowledgeable in CompSci fundamentals than me. :^)
I personally believe that Love2d is the best modern framework to learn and teach game dev with.
The only drawback is that it is a little bit too minimalistic for situations like shorter game jams where people with more kitchen-sink engines like Godot will have a much easier time. For example there is no native way to support multiple resolutions/fullscreen as well as lack of accessibility features. These things can be easily implemented or you can find libraries but it is definitely a concern.
On the other hand, learning Love2d first, paid huge dividends in my game dev journey because I learned how to actually program instead of relying on cobbling together engine features. And for the right project, especially those where a predefined engine structure does not not fit, it can still be the most productive choice.
> And for the right project, especially those where a predefined engine structure does not not fit, it can still be the most productive choice.
Right on. While interning at an oil refinery, I developed an application in LÖVE that processes and displays data from spectrometers. In hindsight it may not have been the wisest choice, but hand rolling all the GUI elements I couldnt force out of the Nuklear[0] bindings for LÖVE gave me a strange sense of satisfaction.
You can also use Emacs and fennel-mode and then M-x fennel-repl to get a live repl from your Emacs session and then use lisp-eval-last-sexp, doc lookup and other Lisp conveniences.
Agree on the rendering speed, I was working on some experimental visualizers in LOVE which drew lots of individual pixels. I ended up having to rewrite a bunch of it in shader language to get decent FPS. This might be true with other frameworks too though, I understand graphics are not an easy thing to just automagically optimize.
Agreed! The LÖVE community could benefit from more advanced resources, especially on performance optimization. Perhaps it's an opportunity for experienced developers to contribute.
I love love2D. It's really a breath of fresh air. I've made many little games and prototypes with it. Lua is fun, and the doco is great. I highly recommend it as a very first dive into game programming.
If you're looking in that realm I also have to mention RAYLIB [1]. It might remind you of the XNA days, except it runs on many platforms and it actually works! (sic.) It's a Borland C style one-file include with some serious power. It's also a ton of fun until you segfault 3 mins into gameplay and you have no idea why. But then you can only blame yourself!
Final plug is of course PICO8. Very different style once again but so much fun[2]! Simple, cheat-sheet style programming, with all batteries included (pixel/spritesheet editor, mini DAW). And the productivity might surprise you, as you don't agonise for days on your third redesign this month.
All of these have vibrant, helpful, communities. You can't go wrong for fun.
Cannot not mention a Tic80. It is a FOSS alternative to PICO8.
Main differences are: 16:9 aspect ratio, no cpu limits and many languages to tinker with: lua, js, moonscript, ruby, squirrel, wren, fennel, janet, wasm, ... and just recently - a Python support was added.
You don't even necessarily need bindings to use Raylib in Zig. It uses Zig's build system so you can just clone Raylib's repo, add a couple of lines to build.zig, and it's ready to go with autocompletion and everything.
Both Raylib and Zig include all dependencies too, so I was able to build a single 700kb .exe from Linux, copy that to my Windows machine, and it just worked immediately without any issues. Pretty amazing.
Would you have any tutorial on how to do this? I am unable to get zig .11 to work with the latest raylib without binding libs. I am not sure what all changes I need to make to build.zig
Thank you. It worked perfectly for me. I was doing most of these but I was messing up the include path. your code samples helped me fix the issues in my build file. Have a great day!
What is so fun about lua? The few times I've come into contact with it I've been...less than thrilled with what I've seen. Looks like a lobotomized version of a language I'd like, with ugly, verbose syntax.
it's kind of like lisp's ugly cousin. Super-duper simple at its core, built around a single data structure (tables instead of lisp's lists), and flexible enough, thanks to meta-tables, that you can build extensions on top of it to fit it to what you need
I wish PICO-8 and TIC-80 doubled resolution for the IDE part. The fonts make it hard to do serious long work and working in an external IDE isn’t as fun for kids.
I've been working on a fantasy console for several years now that is essentially that: a sort of "16-bit" scale version where PICO-8 is more "8-bit" scale.
No idea if it will ever see the light of day, but it's been a very therapeutic hobby project.
I love open source: my two books are open source, I work in open source, and almost all of my hobby projects are open source.
But after spending all day coordinating with users and combing through the issue tracker, there's something very relaxing to me to have a little project where I don't feel "on stage" whenn working on it. It's good for me to get a social break.
Seems like a good way to teach about sub-pixel rendering and HighDPI. Perhaps abstract so the screen is an addressable pixel (so as not to break the world), divide each virtual pixel into, say, a 4x4 submatrix (or even 8x8, 16x16, etc), and have new (prefixed?) functions that work on the sub-pixels (which ideally map 1:1 to actual screen pixels). For back compat, address pixels with two offets..one in the virtual grid, and one for the sub pixel.
Great to hear about the diverse tools available for game development. Whether love2D or PICO8, there's something for everyone, from beginners to seasoned developers.
Also do not forget the VR/3D version, LÖVR: https://lovr.org/
It is a very good "mini" base that's easy to get started in but gets progressively harder to make anything finished looking, at least presently.
Also do not expect Desktop 3D to have first priority although mouse and keyboard is supported.
I feel somehow unclean or dirty using Godot and Unreal and the like since they force you to work on their editors.
The editors are basically immediately off limits for anyone who wants to mod the base game rapidly for their own enjoyment. A concept like http://sauerbraten.org/ is interesting, but seems to not have taken off for various reasons. Lesson learned I guess is that being able to customize is not everything.
I made an Android app in it, a collection of musical instruments to play. The engine was a joy to work in. Everything in its API is laid out neatly and easy to remember. The code-only experience fits me perfectly - instead of stringing together some static assets I can focus on procedural animations and fun dynamical behaviors. The result feels more alive, like what Bret Victor describes in "Stop drawing the dead fish" talk.
Using LÖVE on Android was also pretty effortless. I could fire up a mobile text editor and fix Lua bugs or tweak animation constants. Every desktop feature worked the same on the phone. I could even tweak the audio framework to get optimal latency values. I would never get the chance to tweak under the hood had I chosen some closed source engine.
Since then I've "graduated" to 3D with LÖVR. It is completely different code with the same philosophy of surface simplicity and ample room for growth.
The next step would be to try LÖVE's official interpreter [1] and see that it runs. That app & the docs are actually all you need to develop a full application right on your mobile phone. You could fetch Hexpress's source code and put it on the /sdcard/lovegame and the official LÖVE interpreter should run it fine, just with more latency.
If you'd like to pursue this further, please reach out on GitHub issues.
I love the concept of Lua, but the linguistic features always drive me up the wall. Poor FP functionality, the weird double-dipping on associative and non-associative arrays into the same data structure, and 1-based arrays all drive me batty.
But I'll always gladly suffer through it in exchange for an easy and clean and secure embedding API.
So yeah, I totally understand why LOVE is made like that, but I don't think I'll use it.
Yeah, those are decisions that needed to be made in order to make Lua simple enough for being embedded. And I find its syntax very smart: it is not object-oriented, but using the : syntax sugar you can pretend it is (Löve does that); if you want to write something in a FP way, you also can do it. Of course it's not like using an OOP or FP language, but it does the job. Other cool syntax sugar is that you can omit the parentheses when calling a function that only have a string or table as a parameter, it is useful for creating simple DSLs. Lua was never meant to be the main language of anyone, but given the problem that it wants to solve, I'm amazed on how much we can do with it!
On the other hand, JS was very similar to Lua. It wasn't object-oriented, but we could pretend it was, just like Lua. However, people started to use it for things that it wasn't meant to do when it was created, and it was extended with more features. Lua still have the same purpose, keeping its simple syntax.
Some years ago, the creator of Lua was invited to my university. He told us about some of the decisions that were made in Lua. For example:
- about it being indexed by 1: at the time, arrays indexed by 0 wasn't as popular as today. Lua was created in 1993, it is older than Java, JS and many other languages that we use today that are 0-based. A decision had to be made, and they chose to start at 1, as it was easier for non-programmers to write formulae
- about it using -- as comments: it was inspired by Haskell
- about it not having a ++ operator: that would increase the complexity of the syntax, and a -- operator wouldn't be possible due to that decision above
As I get older especially I find myself with less and less time to learn things that aren't somehow useful to my life, like game programming. It's sad.
Take a stab at it with love. If you already code professionally you can have a simple platformer or asteriods type game up in running in an hour or two
Do you have kids? If so, learn to write a game with your code by your side! That's what I'm doing, and I generally feel the same as you (NO GODAMN TIME!) :)
I have used love2d for a lot of small projects and highly regard it (and absolutely LOVE its community. Personally love2d & Rust have been the most helpful communities I have ever interacted with). But it is NOT a unity replacement. Not even for 2d.
Its a framework and not an engine. which means that you have a core engine and there are some community libraries in various states of completion/support that you can use. Else you end up doing everything by yourself.
Let's say, you want to do UI, then there are 4-5 options ahead of you and you will no know how well these libraries are maintained till you use them. Very likely you wil find yourself mucking about the code of these libraries to fix weird bugs or adding a feature your game needs.
So, great for prototyping and learning about game dev. But not something I recommend for actual projects with dates.
Overall IMO, the closest to Unity alternative I can recommend are;
1. Godot
2. Defold
3. Gdevelop (HTML based. No-code development, which can make people love or hate it)
4. CTjs
If you are ok with paying for the gamedev - Gamemaker is another solid choice.
Each of these have their pros and cans, but are full fledged engines with huge communities and helpful resources to go with them.
And if an editor free engine is what you are looking for , Raylib would be highly recommended.
My personal requirements would be;
* 2d focused
* huge community with tutorials & documentation for everything
* libraries & extensions for all the usual gamedev stuff like camera, lighting etc.
* asset protection baked in
* console & mobile export targets.
* Steam integration
Personally, I am personally leaning heavily towards Raylib using zig bindings - with Gdevelop/CTjs for quick prototyping of ideas.
I have tried Rust engines like Bevy, but the Rust tax was too heavy for me and I personally could not proceed beyond simple projects. your mileage may vary. Fyrox is good too, but there are pretty much no tutorials out there.
Another dark horse you can consider is the Flame engine on Flutter. Its very feature complete and you get all the mobile niceties for free. it has a nice community but examples, documentation tutorials etc are non existent.
Finally, if wishes come true, i'd really like a native version of the Phaser engine which will allow me to code in typescript, have all the existing Phaser features/apis, let me leverage its huge tutorials/resources, generate native binaries, enable baking in assets etc- but we don't have anything like that yet -_-
From my point of view, all the engines that don't have C# as the main programming language are already out from the "Unity like" pool, followed by not having console support, VR/AR headsets, and being supported in all major industry SDKs.
"Unity like" refers to a Editor driven approach, not to a language
Unity became popular with its moonscript language (javascript like), they then ditched it to focus on C#, but what propelled unity to what it is today is the Editor driven approach, not c#, not DOTS (most AAA companies still fall back to lua in unity https://github.com/Tencent/xLua)
They are forced to transpile C# to C++ via IL2CPP as a result to target consoles/mobiles
C# is a disease when it comes to console/mobile support
It's a substantial dependency, quite heavy
And you are not free of unity like fuck ups, it's a microsoft language after all:
And let's not forget when they changed the license of their debugger overnight to prevent people from using it in their products (jetbrains for example)
And them deprecating open source tooling to a proprietary/closed one for vscode (c# devkit)
Let's be careful, and let's not recommend evil as an alternative to evil ;)
You are alway free to use C and C++, and take advantage of the money that all big corporations pump into ISO, GCC, clang, MSVC and proprietary console compilers.
Then again, you're certainly not Unity's target market.
Yeah, and engine's name should be Unity, just to be safe. Why not just stick to Unity instead of playing no true Scotsman? Not even Unreal satisfies these.
Definitly, that is the biggest selling point for Unity, it is a C# based game engine, with a C++ core like most engines, however what everyone writes is C#, with Burst (a C# subset for C++ like programming) they were even in the process of rewriting parts of the C++ core in C#.
So any engine whose game code isn't C# is a deal break for existing Unity users, as the only thing remaining are the assets.
I used and loved this framework years ago so happy to see it’s still thriving.
I’d love to start making games with my son now he’s getting older, but I always used to hit a roadblock with the artwork. In this age of AI, can anyone recommend free/cheap ways of acquiring good animated sprites for hobby projects?
When I was playing around with Godot and 2D game development, I went to itch.io for free asset packs. It's hard to get a consistent art-style, but good enough for a beginner.
I liked working with it (the library) but learned I hate working with Lua just slightly less than I hate working with JS. At least in JS we now have TS and things like Elm.
I'm not the OP, but for me it's the absolutely braindead design decisions around arrays, respectively the lack thereof. Arrays (or lists, vectors, sequences, whatever) are such a fundamental concept that not supporting them directly is inexcusable in my opinion, and very annoying in practice. You can abuse tables (i.e., hashmaps) as arrays, but they exhibit very strange behavior and footguns. For example (keep in mind that #a is supposed to return the length of a table-abused-as-an-array):
> a = {}
> a[1] = "x"
> a[2] = "y"
> a[3] = "z"
> #a
3 -- okay
> a[2] = nil
> #a
1 -- wat
> a[4] = "w"
> #a
4 -- wat
> a[2] = nil
> #a
4 -- okay (I guess)
> a[4] = nil
> #a
1 -- wat
You can't just print a table, it will only display its memory address – you'll have to write that function yourself. Considering that tables are the fundamental non-scalar datastructure in Lua, and Lua is supposed to be a scripting language with a REPL, this is mind-boggling.
Oh, and a table doesn't keep track of the number of its elements, you have to manually iterate over all elements and count them because of ... reasons?
Exactly – unintuitive, inconsistent behavior like this is why I wrote "braindead design decisions around arrays". I know of no other language that managed to get something as simple as arrays quite as wrong as Lua did.
it's a bit of a disingenuous example because it ignores the existence of table.remove, which removes an index and reshuffles the indices to maintain the array.
you can also swap and pop using the magic of multi assignment to preserve index order if you don't care about maintaining value order:
a[1], a[#a] = a[#a], nil
If you do care about value order there's table.sort
Just because you don't like the raw behavior doesn't mean it's incorrect. You can make the same argument about other languages in a practical use case
I'm a PHP dev and I would never rely on setting an array index to null or calling unset() on a collection if I'm deleting an element. Both lead to bugs. In the former case, null is treated as a set value so the count is inaccurate. In the latter case, the count is correct but the indices aren't continuous any more. JS has the same behavior with null and delete. Both PHP and JS have functions for manipulating arrays just as lua does.
One way to think about "tables" is that they have an array part and a hashmap part. The # operator works on the array part simply starts counting from the first index and stops counting when it reaches nil.
Your complaints sound a little bit like you wish Lua was a little bit more, but it kind of has a design goal of being simple language you can embed. You are meant to bring your own batteries.
> One way to think about "tables" is that they have an array part and a hashmap part.
But why conflate the two? There's no benefit to this, only drawbacks.
> The # operator works on the array part simply starts counting from the first index and stops counting when it reaches nil.
That's obviously not the case, as can be seen from #a returning 4 after setting a[4] = "w", even though a[2] == nil. There's no simple logic behind the # operator's behavior, it's an unintuitive mess.
> Your complaints sound a little bit like you wish Lua was a little bit more, but it kind of has a design goal of being simple language you can embed.
No, a simple language doesn't have to be inconsistent.
> No, a simple language doesn't have to be inconsistent.
Sorry I meant to say minimal and I was referring to the lack of certain features , not necessarily simple which is something else.
> That's obviously not the case, as can be seen from #a returning 4 after setting a[4] = "w", even though a[2] == nil. There's no simple logic behind the # operator's behavior, it's an unintuitive mess.
Oh, so perhaps it's a combination of being an "unintuitive mess" and/or it's been changed and/or I don't even remember.
Running the code you provided in the Lua online demo (which is lua 5.4.6) yields 3,3,4,4,3 so I guess you were running an older version.
I don't think this is a big problem in practice if you are just aware of this. It's a bit like 1 vs 0 based indexing. It may have been a problem in the beginning but it's been too long since I first started using Lua. And here you'd have a point.
> But why conflate the two? There's no benefit to this, only drawbacks.
I honestly don't know. I'm actually more on your side when it comes to distinguishing arrays and tables. I just don't think it's as big of a deal as you make it out to be.
-
As I alluded to earlier, you can just change Lua to fit your needs. It's meant as a language you embed in your own framework and was never really meant as a fully standalone language as far as I understand. Its position of being standalone is kinda weak in my opinion.
You even mentioned previously that "Lua is supposed to be a scripting language with a REPL" but the REPL included is the bare minimum.
By far my own biggest "complaint" about Lua is that it's dynamic. However Lua with types would be a different language entirely.
The main thing that makes me a little sad about LÖVE is that LuaJIT is not really RISC-V friendly yet (yes I know about the fork.) I am interested in focusing on RISC-V for some personal projects so my requirements are a little unusual, but LuaJIT has a pretty high barrier to adding new backends. Usually it needs to be industrially sponsored, too.
LuaJIT can also have unpredictable performance characteristics, if it matters.
I'm a huge fan of Love and have many side projects on the go.
I quite like Lua although it took some getting used to.
You would have to be fairly disciplined to work on a big game with multiple programmers. The c# of Unity means you can be fairly lazy rely on the IDE to help you work out what is going on. I imagine you could make a real mess with Lua.
It's much better than Godot and Love is a really solid foundation to build your game on.
For games which do not require a level editor i'd agree love is better. but this is only a small subset of games perhaps. other cases, an editor is definitely useful. making an editor yourself is really, really tedious.
I spent a few months working on Godot and it was clear that the developers don't actually make games, and don't have the same priorities as me. I want a real solid foundation to build on.
Nobody likes to put down such a great looking open source project, but I decided it was not for me.
I am curious what issues you ran into. Also, there are about 50 games per year released with Godot on steam, so there are definitely people pulling it off
Thanks for the details. Well it sucks when there's a bug that deep for sure. Maybe it got solved in the 4.0 ? And with more and more people adopting it, I assume the regressions will be less frequent.
Yeah, I've noticed these issues with Windows, but didn't bother fixing as this is more a learning project to better understand games like Minecraft. Might test some different compare modes for "love.graphics.setDepthMode" later to see if it fixes it.
Thanks for this link! I've been wanting to try love but it's hard to find a real codebase that's small enough to just read through to learn it but also complex enough to be realistic. This seems like a great example.
It's a fun framework but doing anything advanced in it is a pain. Offloading to other threads etc doesn't work well, at least when we tried, and requires that the messages sent on channels are basic Lua objects, which can get messy quickly and hurt performance in our case.
Further, the source is entirely reversible and thus can be stolen. Conversely, we couldn't get LOVE to build on its own (from sources). Perhaps that's improved since ~4 years ago.
We ultimately had to ditch LOVE, but it was fun and cute while it lasted. For simpler or more straightforward projects, I'd consider picking it up again.
A question regarding the OpenAL dependency since this came up recently in a discussion (unrelated to LÖVE).
Is it okay to use OpenAL (unmodified) on a "closed" platform like iOS, or Nintendo Switch as long as it is dynamically linked? From what I've gathered so far, this is still okay with LGPLv2 since v2 does not have a tivoization clause. LGPL v3 does have the tivoization clause, which demands that the end-user has access to the necessary tooling to unpack, re-link, repack the binary for the used platform. Is this correct?
Oh Man I haven't heard of this framework in years!
There was this amazing fan game made to mimic an episode of this tv show called Community. The show is about a group of community college students getting into all sorts of hijinks and one episode had all of them go into this video 8 bit video game world....so LÖVE was used to recreate the game exactly as you see in the show.
Unfortunately it is running on a very old version at this point and I hear due to how the framework has changed upgrading is not straightforward. It interesting to see how software changes and grows over time. Fortunately the last version released still seems to work fine on modern machines. (at least it runs on my M1 Mac)
Speaking of Lua based Game Engines, I wish MOAI had managed to survive the onslaught of App-store policies designed to kill it. It was a really fun way to build apps.
I wonder if anyone has ported Hanappe, which is a GUI framework on top of MOAI, to LOVE yet ...
I did many semi-popular libraries for this engine, it was my first introduction to Lua, which eventually gave me a job (not on gamedev - openresty). The community was helpful and welcoming.
I have not done gamedev in a while, finding the time is difficult with a growing family. But it still makes me happy when someone pings me about one of my libraries.
This is the framework used for Gravity Circuit, the Mega Man X inspired game that came out last month. It’s one of the best games of the year, by the way. I’ve been interested in exploring this framework. Glad to see it’s gotten attention on HN
I'm trying to do something with DragonRuby Game Toolkit (Ruby is my main tool) but LÖVE always seemed nice, too.
I also like Moonscript as an alternative to Lua language ( https://moonscript.org/ )
I got my first job as a programmer because someone noticed that I’ve been making video games with LÖVE.
A similar library would be raylib, that I’ve been using lately.
These libraries are simple enough so you can keep everything in your head, and they are powerful enough so you can immediately put stuff on the screen with zero ceremony. This combination makes it extremely productive.
It’s the perfect abstraction layer for amateurs and people who are drawn to simplicity.
Löve is more of a library/framework than a full engine. It's a whole layer of the stack below what you'd get from Godot, Unreal, or Unity. You either have to build that layer yourself, or work with what is effectively assembly (as opposed to e.g. C).
The engine layer can be extremely thin, which is why Löve (or its peers, like SDL, Allegro, Pygame...) work great for small or "outside the box" games, but you use different tools for different jobs. If you're building a cookie-cutter game, writing your own engine is a waste of your most precious resource: time and effort. But it's an entirely reasonable choice if you're building something like Factorio (which runs on top of Allegro), where an existing engine would just get in your way.
First I had an unsuccessful journey with GameMaker, then a lot of time spent modding Minecraft in middle school without really understanding how to code. Finally, LÖVE ended up becoming my main time-sink for most of my free time through high school, about a decade ago.
Every evening I would start a new project. Some were random game ideas, some were to study certain aspects of math (like fractals), some were just meant to be nice to look at. This is where I learned a lot about game design, and also a lot of the harder aspects of programming (after that, my college CS degree ended up being a breeze).
I was working alongside an internet friend on these. Sometimes we would collaborate on something exciting, sometimes we would work alone on something and share lots of progress updates between each other. It was a really fun time. I think LÖVE having no GUI really helped our minds to run free while we learned how powerful computers could be.
Some of my LÖVE projects I remember the most fondly:
- A gravity simulation / art canvas where ships would fly around planets and paint a trail behind them [1].
- An online multiplayer platformer roguelike with full rollback netcode that handles 150ms+ ping (this was a real challenge!) - never completed.
- An online pseudo-rhythm game where you only have one button to use and you have to work with your friends to input in the correct order while a timer keeps ticking down [2].
The last one still lives rent free in my mind. This one still gets downloads today, it's the most popular project I've been a part of. But I suspect most players don't get past the step of needing to forward ports and find 3 friends to play a short 5 minute indie game. I'm proud of the idea behind it, but I don't have a good way to turn it into a full game without ruining the core idea.
LÖVE was my tool of choice for many gamejams, it was a breeze to put together a prototype once I had gotten comfortable. Today I think I have more perspective and wish I could go back in time to see more of my 100+ prototypes to completion, instead of always finding a reason something was imperfect and not worth pursuing. Now I just don't have the same amount of energy when I get home from my software day job, I often need the time just to unwind. Lately I'm trying to push through and make gamedev a habit even if it's hard, to get back some of the joy during the days I was in love with LÖVE.
> An online multiplayer platformer roguelike with full rollback netcode that handles 150ms+ ping (this was a real challenge!) - never completed.
I worked on something similar in high school(also never finished). Implementing good netcode on a novel multiplayer game can be very hard to get right. Made me a lot more forgiving of games that didn't do it well. You pretty much need to design your game with multiplayer in mind.
There was a time when this was really popular, but most of the löve community has abandoned this to be more accessible to kids and just to look less infantile. I think those names are mostly frowned upon now and many of the popular libs have been in fact renamed.
Children will be totally distracted by things like that. Instead of concentrating on the actual task/goal they will focus on funny/silly words and this is not helping in teaching them something.
Well, a lot of what people make with Unity could be done perfectly well with Löve. It's not intended to replace the Unity target public, but Unity is used well beyond its target public.
I'm a big fan of love2d, but for _almost everyone_ it's not a replacement for unity.
Looking at https://steamdb.info/tech/Engine/Love2D/, there's only two games on that list that (based on steamspy numbers) that would actually be affected by the recent pricing changes.
If you're objecting to Unity on moral grounds for it's new DRM philosophies, or it's CEO, well those were just as valid almost 10 years ago.
Yeah. I've had fun with Love2D but it's not even an engine, really. It mostly just wraps SDL functions (and a few other libraries). If that fits your use case exactly, go for it! But if you're looking for the FOSS equivalent of Unity, Godot is pretty much exactly that.
Doesn't the umlaut seem like a bad marketing decision?
Yes Unicode is cool, I'm glad we have it, I'm glad increasingly more things support it. I don't know the key combination for any character modifier off-hand, I usually copy these sorts of characters from google when I need them. It seems like it makes this framework unnecessarily harder to find.
Not only that, but it makes the pronunciation difficult. Should this be pronounced like the English word "love", or interpreted more like a German word (which actually has this letter in the alphabet, and guess what, it isn't the same as o) and more like "loeve"? The umlaut isn't just a graphical stylisation, it's a real thing.
We had a devblog, doesn't exist anymore unfortunately. The thing I enjoyed the most was the flexibility of Lua, and the whole framework seemed to adopt that mindset. It gave you all the core pieces you need it (audio, input, physics, rendering), and then got out of your way.
The drawback to the full flexibility is having to spend time thinking about what design & workflow your wanted (but, really, wasn't a drawback, that's what I wanted, just took more time). We ended up designing a really flexible engine that allowed us to pivot from a 2D puzzle platformer with a story (Concerned Joe) to the action packed fast multiplayer game that Move or Die became.