This is fantastic, and LOVE/Lua is really fun to work with, I highly recommend this framework.
 - https://github.com/leafo/moonlisp
 - https://mothereff.in/lua-minifier
As an aside, I'd like to plug a Lua library I have nothing to do with called middleclass . I've used it with LÖVE and it's handy for game dev!
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 ..
> 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 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 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...
It is open-source and based on community effort. https://www.reddit.com/r/hawkthorne https://github.com/hawkthorne/hawkthorne-journey
If anyone would like to knock a thing or two off the ToDo list, I'd appreciate it :)
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!)
The Lua reference manual is also very approachable.
> "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!
So performance is good.
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.
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).
You can also use the "viewer" tool to sync your project with a application shell on the device via dropbox.
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.)
Udacity has Nanodegree using it: https://www.udacity.com/course/mobile-2d-game-developer-nano...
Disclaimer: I'm writing a game using LibGDX.
Is that still around?
I would guess not everyone will be okay with their artwork, sound files and other resources being available so easily.
I think if developers aren't okay with their resources being that available, they probably don't look at using frameworks like this.
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? :(
(And we're about to do a new release of MOAI soon too..)
What is LÖVE?
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" :)
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.
"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.