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.
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).
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.
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!
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:
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
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...
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!
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!)
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.
> "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.
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.
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).
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 ...
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.)
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.
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.
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.
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..)
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).
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.
This is fantastic, and LOVE/Lua is really fun to work with, I highly recommend this framework.