Hacker News new | comments | ask | show | jobs | submit login
LÖVE 0.10 released with iOS and Android support (love2d.org)
323 points by AlexeyBrin on Dec 22, 2015 | hide | past | web | favorite | 91 comments

Lack of native mobile support was one of the reasons I dropped LOVE for other frameworks.

This is fantastic, and LOVE/Lua is really fun to work with, I highly recommend this framework.

Does love work well with moonscript?

While we're at it: everyone, check out MoonScript [1]. It's a great, succinct and featureful compile-to-Lua language, although sadly not very widespread at the moment. It features significant whitespace, syntactic sugar to reduce keyword noise in programs, table and list comprehensions, line (statement) decorators, classes, export and import for working with modules, implicit return, JSON-like table literals and much, much more. I, for one, absolutely love working with it.

[1]: http://moonscript.org

Everyone check out Lapis [0] as well!

[0]: http://leafo.net/lapis/

I tried but the \ syntax for calling an instance method on an object is asinine and I hate it.

Heh yes, a very common complaint. I don't like it either, but the trade off still seems worth it.

There's also MoonLisp compiling to Lua, written in... MoonScript [0]. The output isn't pretty, but I'm looking for a lisp for NodeMCU, so I might give it a shot :), maybe combined with [1] due to way NodeMCU seems to work (interpreting / locally compiling files + little memory = you want to save on source length, including comments).

[0] - https://github.com/leafo/moonlisp

[1] - https://mothereff.in/lua-minifier

Awesome, thanks for this! I've always found love to be great, but I didn't enjoy using lua once the program grew to a non-trivial size.

Yeah. I have used it with love. Moonscript is compiled beforehand to Lua, so it works the same. Lua's syntax is very nice, but the conciseness of Moonscript is nice for a lot of things.

Yes, very well

What framework did you use instead?

Adobe AIR

Site is hugged to death. Google cache/mirror: http://webcache.googleusercontent.com/search?q=cache:https:/...

You mean Loved to death? ;)

This is wonderful. I'm quite fond of Lua and while I've tinkered with LÖVE here and there, the lack of mobile support turned me off from using it for serious projects. I'll be giving it another look soon.

As an aside, I'd like to plug a Lua library I have nothing to do with called middleclass [1]. I've used it with LÖVE and it's handy for game dev!

[1] https://github.com/kikito/middleclass

Middle-class is awesome, thanks for sharing that .. I'll put it on my lab bench for hacking over the next few days.

Continuing the list of 'handy little Lua libraries that others in this thread might be interested in', I'll add that I think that a lot of newcomers to Lua from languages like Ruby and Python might enjoy having lua-enumerable around as well, which provides a set of enumerable ops that fit in quite well with Lua's tables .. check it out:


Hanappes' got a few nice Lua classes in its lang folder too:


Useful for newcomers to Lua and pro's alike, imho ..

LOVE uses LuaJit, right? How does that work with mobile where you may be denied execute access to the data segment?

To answer my own question, here's a quote from the LuaJIT website:

> Note: the JIT compiler is disabled for iOS, because regular iOS Apps are not allowed to generate code at runtime. You'll only get the performance of the LuaJIT interpreter on iOS. This is still faster than plain Lua, but much slower than the JIT compiler. Please complain to Apple, not me. Or use Android. :-p

Anyone got any games written using LÖVE to show HN?

Why did you disable fullscreening the youtube video on the page of Collider?

I don't control the youtube video, but I will message the fellow that does!

When I had spare time I was working on a Terraria-inspired game. Here's a sample video of how far I got: https://www.youtube.com/watch?v=clxX8QZonL4 with the code here: https://bitbucket.org/sirpengi/lua_lovestory/src/tip?at=defa...

I ended up using luajit FFI to call into C to calculate lighting. I wonder what the FFI support is on the android/ios ports.

I love pet projects, specially little games (have made some with SDL in the past).

I don't know how Terraria does it (never played) but I suggest you that you only moved the camera when it's necessary (instead of keeping the character in the center literally always). The camera jumping along with the character might even let the player dizzy...

For entirely too many words about the various types of camera systems used in 2D games, see: https://docs.google.com/document/d/1iNSQIyNpVGHeak6isbP6AHdH...

That's some invaluable info. Thanks!

https://youtu.be/pdvCO97jOQk around 7:30 shows how camera in terraria works :)

There is this: https://projecthawkthorne.com/ which is based on an episode of the TV show Community.

It is open-source and based on community effort. https://www.reddit.com/r/hawkthorne https://github.com/hawkthorne/hawkthorne-journey

Came here to say this.

I made oh my giraffe [1] in LÖVE and released it for iOS and Android using these ports.

[1] http://www.ohmygiraffe.com

Very simple but beautiful! The LÖVE wiki on the Android port has an example of running from adb, but how did you create and apk for your Android port?

Thank you! This page has documentation for packaging an apk: https://bitbucket.org/MartinFelis/love-android-sdl2/wiki/Gam...

That is really cute. I think this is a really well done landing page.

A while back - I made an AI simulation with one of my friends for boid simulation using various path-finding algorithms on procedurally generated roads!

Photo: http://shakilthakur.com/content/images/2014/11/Screen-Shot-2...

Github: https://github.com/FourierTransformer/Boid_Racers

I started working on a snood clone. It's' still unfinished, but I've spent countless hours playing it mindlessly:



If anyone would like to knock a thing or two off the ToDo list, I'd appreciate it :)

Not mine, but one of my favorite games:


We're using LÖVE for Pocket Rumble

The game supports lag-free rollback netplay using GGPO, and Steam matchmaking with ELO leaderboards

And since LÖVE uses lua, mod support is no problem to implement, so we'll have steam workshop support too (It's not released on Steam yet but will be soon!)


I released a game called Aerannis a while back.


all my games were done in Love. My latest one: http://bitoutsidethebox.com/autumn/

A friend and I made a game for the most recent Ludum Dare using LÖVE. It's a top-down racer: https://github.com/zeta0134/ludum-dare-34

I would love to tinker with LÖVE, but I don't know the first thing about Lua. Anyone have pointers to good introductory resources they can share?

"Programming in Lua" is Lua's K&R. It is a very well written technical book.

The Lua reference manual is also very approachable.



Löve uses luajit by default, which is Lua 5.1 with some 5.2 sprinkled on top.

LÖVE has their own recommendations on resources to learn Lua from here: https://love2d.org/wiki/Main_Page#Lua

For a couple of quick intros, try Learn Lua in 15 Minutes[1] and Learning Lua from JS[2]. For a bit more depth, try the Lua-users Tutorial Directory[3]. For serious depth, the two recommended by Gracana, PIL[4] and the reference manual[5], are fantastic. For an overview of the ecosystem, including some useful gamedev libraries and LÖVE-specific resources, take a look at awesome-lua[6] (my own, shameless plug).







It is very minimalistic. There are only 8 datatypes: 4 immutable (nil, number, string, boolean), 3 mutable (table, coroutine, function) and userdata which is used for arbitrary opaque "exterior references". The standard library is fairly small. There is a small amount of "metaprogramming" possible that lets you overload operators and do some basic prototype-based OOP, but the whole thing is very approachable. Personally, I think it is one of the better options for a learning language because of how simple it is.

You can pretty much learn the language in 1 - 2 days if you are an experienced programmer. Try the LUA website, they have some links to good tutorials.

From http://www.lua.org/about.html:

> "Lua" (pronounced LOO-ah) means "Moon" in Portuguese. As such, it is neither an acronym nor an abbreviation, but a noun. More specifically, "Lua" is a name, the name of the Earth's moon and the name of the language. Like most names, it should be written in lower case with an initial capital, that is, "Lua". Please do not write it as "LUA", which is both ugly and confusing, because then it becomes an acronym with different meanings for different people. So, please, write "Lua" right!

If you have some experience with javascript, Lua's syntax, scoping and structure are fairly similar to that of ECMAScript 5. That's a very macro and broad comparison of it, but if you have scripting language experience, you'll be fine.

How's the performance compared to say Cocos2d-X in C++? For say something like large scale steering forces and Behavior agents?

LuaJIT is fast and Love is minimal. It has threads and can callout to C.

So performance is good.

Turns out JIT is disabled on iOS and AppleTV. So might not get that boost.

If you're really interested in maximizing performance, http://lua-users.org/wiki/LuaToCee can help you turn your Lua code into C code instead. With some skillful manipulation of liblove, you can compile your game down to a 100% static executable.

But no one's really bothered because Love is best at prototyping than actually releasing games, and performance is "good nuff" at this point in time anyway.

Lua is really easy to pick up, even without a book. Start using it with LOVE and have fun.

I encountered LÖVE when I was searching for simple graphics engine that can do 60fps consistently without frame skipping. It worked very well.

How does LÖVE compare with Corona SDK, a commercial Lua-based mobile framework?

LÖVE is free, open source, runs on desktop and mobile, local builds and so on. Also, it is based on SDL2 so, if you know C, you can modify the code.

That being said, Corona SDK is probably more mature for mobile. Personally I prefer LÖVE because of the fast iteration cycle do to local builds (Corona SDK builds the game on their servers).

Only if you want to deploy it to a device. Otherwise you can reload instantly when developing on PC/Mac

I know you can use the simulator to test, but I prefer to test directly on the device and when you need to wait ~1 minute per build it is a bit annoying. I used Corona SDK for a small 2D game two years ago, maybe now the build times is better ...

Reposting what seany wrote 4 hours ago [dead]:

You can also use the "viewer" tool to sync your project with a application shell on the device via dropbox.

You can also use the "viewer" tool to sync your project with a application shell on the device via dropbox.

Love is a bit more 'low level' than Corona. In LÖVE you have direct control over what gets drawn each frame, wheras in Corona you are more working with a scene graph (nested display objects).

I've used both for hobby games. Corona is user-friendly and it's a great solution with lots of community plug-ins and support. It uses a freemium model, offering features like access to native API's and offline builds at a price, and you can't really use it on Linux. LÖVE is free and open-source and adding support for Android and iOS makes it even more attractive.

Love is used mostly to prototype games for the PC, and support has only begun today of the mobile frontend. (It was usable for a while, but only now is it supported.)

Love has minimal bindings, basically only enough to make use of most of SDL and OpenGL. It lacks all of the native and GUI support of Corona (except where you write your own C bindings... have fun with that, I suppose.)

Can you make networked multi player games in love that work on mobile?

Yes, LÖVE includes ENet and LuaSocket.

A bit OOT, LibGDX is another game engine, but for the JVM (can use Java, Scala, Clojure, Kotlin, etc), that runs natively on desktop, Android, Web (transpiled to JS), iOS (using RoboVM). It has Lua support as well through 3rd party.

Udacity has Nanodegree using it: https://www.udacity.com/course/mobile-2d-game-developer-nano...

Disclaimer: I'm writing a game using LibGDX.

I tried LibGDX but the thing that troubled me was that while other engines had a relatively straightforward approach to cross platform builds (click a button or build a particular target), LibGDX required you to write a bunch of boilerplate for each platform.

Is that still around?

The boiler plate is 10-20 lines per platform, which is auto-generated for you and let's you do platform specific things easily. Any production game needs this capability to include things like ads, notifications etc.

Give MOAI a try - we solved this problem recently with the addition of the pito tool (pito means "navel", "whistle" and "beer", in Rapa'nui) which generates complete host projects for every platform MOAI supports. The end result, you really can run the same code everywhere.


I tried Löve a few times as well as many others while searching for an engine to make simple graphical/physical simulations using a dynamic scripting language in for work (using other libraries). It was okay but my favorite was Gosu (ruby/C++), I wish it saw more love.

Perfect timing to make a game over the christmas break :)

This is pretty grand news, and I never used Lua for game development. Congratulations.

One of the most consistent frameworks in LÖVE I know is https://github.com/necrophcodr/fuccboiGDX/

How does LÖVE users handle source being open when distributing games?

I would guess not everyone will be okay with their artwork, sound files and other resources being available so easily.

HTML5 game development is much the same. Even with compiled applications someone can get your code and resources if they want them, so ...

I think if developers aren't okay with their resources being that available, they probably don't look at using frameworks like this.

as a non game developer, LÖVE was the only framework using which I was actually able to create a small game . So simple it hurts.

What is really staggeringly missing is a web port!

It should be a click-away to run a LÖVE game in your browser. Its not. A few good prototypes have been made, but they are all abandoned? :(

We have this in MOAI (a competing framework) already, by way of the emscripten tool .. which is awesome .. so it means that with MOAI you can write apps that run on iOS/OSX/Windows/Linux/Android .. and HTML5 hosts. Pretty amazing times ..

(And we're about to do a new release of MOAI soon too..)

Site's loading too slowly for me to get to the main page, so at the risk of starting a Haddaway thread…

What is LÖVE?

It is a 2D game development framework for the Lua language.

Awesome, thanks.

he meant, baby don't hurt me.


I just don't understand comments like these. Providing a blanket statement that doesn't provide any reasons whatsoever. It doesn't really help contribute to the post, and it just angers people. I hate the term troll, but that's what this feels like. If you actually feel this way then I feel bad that you restrict yourself to only one type of tool. Also I find it confusing when functional evangelicals talk bad about OO and mutable languages when a lot of the languages compilers are built on languages like C. They wouldn't even have functional languages without C.

While Haskell's (well, GHC's) runtime does have parts that are written in C, GHC itself is written in Haskell (and was originally written in a ML dialect I think). The lineage of FP languages seems to be very different than whats typical.

But yea, random blanket statements like that aren't helpful.

There is an older Lua backend for PureScript (at https://github.com/osa1/psc-lua) that may be worth checking out... if it gets a revival. AFAIK that version is a superset of (current) Elm, so it may be possible to combine it with love to get some sort of "Elm for love2d" :)

> They wouldn't even have functional languages without C.

The functional paradigm is, as are some language families in which the use of the paradigm is idiomatic (esp. the Lisp family), older than (or roughly contemporary with and independent of, as in the case of ML) C. So, no, this is clearly not the case.

You don't understand comments like this because you probably don't speak from years (20+) of programming experience in OO languages, like I do, and because it is hard to show people certain better ways of doing things that unfortunately requires years of experience beating your head against the wall in other ways to really see it. But don't take my word for it, here is John Carmack (hardcore C++ developer) on the topic, from this link: http://gamasutra.com/view/news/169296/Indepth_Functional_pro...

"My pragmatic summary: A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. (Emphasis mine. That alone explains most of the bugs I've seen.) In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible...

"No matter what language you work in, programming in a functional style provides benefits. You should do it whenever it is convenient, and you should think hard about the decision when it isn't convenient."

This is a man who has coded slightly longer than I have, and IMHO he is correct on all these points.

I merely believe he didn't go far enough (for example, immutable "variables", which are not available in OO languages without hairy workarounds, ENSURE that the state your code "sees" is not tampered with "from the outside," further reducing bugs), but statements like this are why I take the viewpoint I do.

Take the amount of time you debug as a percentage of your total programming time (and hell, we all enjoy debugging to a degree, don't we? But what's debugging, really? All it is, is trying to discover a state that wasn't conceived of when the code was designed, no? That's the whole point of your stack trace, right?). Now, chop that time in half. Would you want this? Who wouldn't?

Yes, FP is not appropriate for all realms where code lives. But it should most certainly fill all the spaces it currently does not, where its appropriateness is not out of the question.

I would also strongly recommend the "Are We There Yet?" talk by Rich Hickey http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic... which pretty much destroys mutability as a language-level trait, pretty much rendering it the mother of all bugs (literally).

Again, don't take my word for it- here is MIT's core CS curriculum on mutability's dangers: http://web.mit.edu/6.005/www/fa15/classes/09-immutability/

Have I made a strong argument yet, now?

This is why I get upset whenever a new language comes out that does not feature FP/immutable paradigms. If you're new, you SHOULD be using these, otherwise you're just perpetuating more man-years of debugging hell for people. I am tired of watching new programmers make the same mistakes over and over and over again.

The very length of this comment alone indicates how hard it is to communicate this AND why it sounds like preaching/proselytizing/trolling.

You got to be subtler than that for effective trolling.

Yeah, yeah. Read this, I responded: https://news.ycombinator.com/item?id=10783873

Applications are open for YC Summer 2019

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