LÖVE

Hi everyone,

I recently started compiling a list of quality Lua projects and resources, to hopefully save people time when searching for Lua libraries. Of course, you should check it out, here: https://github.com/LewisJEllis/awesome-lua

Hopefully some people find it useful! What I'm really here for, though:

I've been following LÖVE for a while and am a big fan, so I have sections on the list for game development and have included LÖVE and a number of supporting libraries which seem to be popular around here. Unfortunately, I haven't been around the game-dev scene lately as much as I used to be, so in an effort to make the list better, I'm looking for feedback from folks around here (particularly on the game dev portions). Please take a look and suggest any changes or additions that come to mind - it's much appreciated!

Nice work on the list so far!

I assume you've already checked the long list of LÖVE libraries; if not it might be a good idea to see if anything on that list fills in any gaps.

As for additions, there are a few of my own lua libraries which might be of interest:

• Flux: A fast, lightweight tweening library; though you already have tween.lua, they differ in features and API.
• Coil: cooperative threading using coroutines.
• Classic: a small class library -- though I see you already have two on there!
• Lovebird: a browser-based debug console, it should work where LuaSockets is available

I also wrote Lurker which is dependant on LÖVE. It deals with automatically hotswapping changed lua files in a running LÖVE project. Example video is over here.

What are the feature differences of Tween vs. Flux? I currently use Flux and I love it.

rxi wrote:Nice work on the list so far!

I assume you've already checked the long list of LÖVE libraries; if not it might be a good idea to see if anything on that list fills in any gaps.

As for additions, there are a few of my own lua libraries which might be of interest:

• Flux: A fast, lightweight tweening library; though you already have tween.lua, they differ in features and API.
• Coil: cooperative threading using coroutines.
• Classic: a small class library -- though I see you already have two on there!
• Lovebird: a browser-based debug console, it should work where LuaSockets is available

I also wrote Lurker which is dependant on LÖVE. It deals with automatically hotswapping changed lua files in a running LÖVE project. Example video is over here.

Thanks! I did check out that list while compiling the first draft. I think now that I'll do a restructure to break the game dev stuff into more sections (LÖVE, Corona, etc), and I'll go ahead and add Flux, Lovebird, and Lurker (edit: done!). Thanks for the recommendations!

Could you elaborate a little bit on the differences between Flux and tween.lua? I think that right now my description does a poor job of differentiating them.

(Coil and Classic look awesome too, but existing similar list entries have more adoption and I want to keep the list fairly slim.)

Jasoco wrote:What are the feature differences of Tween vs. Flux? I currently use Flux and I love it.

LewisJEllis wrote:Could you elaborate a little bit on the differences between Flux and tween.lua?

This is what I wrote on the original flux post:

rxi wrote:Those who are familiar with tween.lua may be wondering what flux does differently. The most immediate difference is how a tween is created and how its optional settings are set. All optional settings for a tween are set using chained function calls rather than optional arguments. Flux also provides the chained functions after() for sequencing tweens, delay() for delaying the starting of a tween, and additional callback functions: onstart() and onupdate(). Flux provides groups which the uses for are listed in the README. In some small tests I've found flux's update call (where it updates the tweens each frame) runs at about 1.5x the speed of tween.lua, and is able to add 10,000 tweens at about 3x the speed.

Since then tween.lua has been updated to version 2 it looks like there are some additional differences -- for example, at the time of writing the above tween.lua managed the individual tweens for you, but didn't allow you to create individual tween groups. It looks like tween.lua dropped support for managing individual tweens at all, so as well as flux providing tween groups, they now both differ in that flux manages individual tweens for you, too.

The point about adding tweens being faster is also no longer applicable as tween.lua has nowhere to add tweens to -- the point about updating tweens being faster should still apply as far as I can tell.

tween.lua also offers functionality which flux doesn't: tween.lua provides the "bounce" easing function which I chose not to include in flux; it also provides the out-in variant of easing functions. Tween.lua supports running tweens in reverse which flux does not provide as I don't think it makes as much sense when working with the group based system. Tween.lua allows you to specify nested tables when creating a tween -- flux requires you to create separate tweens for each table.

I think that's everything!

Risking derailing the thread, here are some more differences between flux and tween:

• In addition to "rewinding tweens", tween.lua also has the hability to "reset a tween to a particular timeframe" (you can reset a 4-seconds tween to the first second, or to the third, at any moment)
• Flux has a list of global variables (flux.tweens) to store the invidual tweens & groups. tween.lua did something similar for a while, but I came to the conclusion that this is a bad thing, because it makes multi-threaded code go awry.
• Flux provides 28 easing functions. tween.lua provides 45. But in addition, in tween.lua you can also provide your own, or adapt tween.lua's ones (see parameters a,p & s on some easing families).
• You don't need to use 'remove' methods in tween.lua. You attach your tweens to your game entities (your player, your enemies, etc). When the entities are eliminated, their tweens are also gone - you don't have to "clear them from the global list on the entity destructor".
• Flux does very little checks on the inputs it receives (it only checks that the vars table is made of numbers), while tween.lua checks all inputs extensively (incl. multi-dimensional tables). That's where most of the "creation time" goes in tween vs flux.
• In tween.lua, you can change the target "mid-flight" and the tween will adapt to that. In flux, the target is "fixed".
• tween.lua has a battery of automated tests. These tests are run automatically by Travis CI every time a change is pushed to the repo, and they are also automatically run for every pull request that the project receives. This decreases the possibility of having bugs creep in the code when a change is made.

kikito wrote:Risking derailing the thread, here are some more differences between flux and tween ...

I don't use tween.lua. Despite this, I did try to take the time to sift through it and point out the differences and I'm willing to accept I may have missed the odd thing. I think its a shame you don't seem to have bothered to make the same effort when writing your response.

kikito wrote:Flux has a list of global variables (flux.tweens) to store the invidual tweens & groups
[...]
You don't need to use 'remove' methods in tween.lua. You attach your tweens to your game entities (your player, your enemies, etc). When the entities are eliminated, their tweens are also gone - you don't have to "clear them from the global list on the entity destructor".

It looks like you misunderstood how groups work in flux. Groups work independently of the main tween group flux uses, when a group is made it isn't "global", all its tweens are stored in the group and managed by the group, the group is updated independently. You can attach a group to an entity so that when the entity is destroyed the group is destroyed -- in fact, this is one of the main reasons groups exist in flux.

kikito wrote:Flux does very little checks on the inputs it receives

Flux checks the values in the `vars` table are actually numbers, it also checks the values in the object it receives are numbers. All callbacks are immediately checked to assure they're callable, it checks the delay time is a number and that the easing type is valid.

kikito wrote:In tween.lua, you can change the target "mid-flight" and the tween will adapt to that. In flux, the target is "fixed".

I'm unsure what you even mean by this, adding a new tween in flux which tweens the same variables as an existing tween will override the tweening of those variables. This is standard default behaviour across all tweening libraries I've used.

kikito wrote:That's where most of the "creation time" goes in tween vs flux.

The time for "adding tweens" (I never mentioned "creation time") which I mentioned was relevant when I wrote the quoted part as tween.lua managed its tweens at the time, I mention straight after the quote that it's no longer relevant since tween.lua dropped support for managing tweens.

rxi wrote: I think its a shame you don't seem to have bothered to make the same effort when writing your response.

I did exactly the same thing that you did. I have missed some things too.

I want to stress that my previous post was not a personal attack of any kind. I was really hesitant to write that post exactly because I feared an emotional response. I just listed the differences that I saw, as requested by Lewis. I am sorry that I got some of them wrong.

rxi wrote:You must misunderstand how groups in flux work

I should have read the readme, but I didn't, and instead I read the source code. I did this because sometimes there is a mismatch between the docs and the code. I didn't get how the groups worked, sorry about that.

The critic about flux having a global list of tweens still stands: it is still a bad decision, for the reasons I mentioned before.

rxi wrote:it also checks the variables in the object it receives are numbers. All callbacks are immediately checked to assure they're callable

I missed that when reading the code. In my defense, it looked as if it was doing plain assignments without checking anything. Maybe a little less metatable magic is in order.

rxi wrote:it checks the delay time is a number and that the easing type is valid.

The "time" parameter, however, is not checked for number-ness. If someone enters a non-number there, the error message will be something like "tried to compare a number with a not number"

That's what made me think that no checks where being done. I recommend putting all the checks explicitly, and exactly where they are being applied. Also, I recommend checking the parameters themselves, not the object attributes. You will be able to provide better error messages that way.

rxi wrote:

kikito wrote:In tween.lua, you can change the target "mid-flight" and the tween will adapt to that. In flux, the target is "fixed".

I'm unsure what you even mean by this.

It means that the target is kept as a reference, not as a copy. This makes it possible to tween to dynamic positions.

Imagine that you want a camera so approaches a target. You can do that with both tween and flux. Now imagine that it is a moving target. You can do that with tween.lua, but with flux (and older versions of tween.lua) the camera will tween to the place where the target was when the tween was created.

kikito wrote:I want to stress that my previous post was not a personal attack of any kind.

Of course! It makes more sense now given you only read the source and not the readme, but when I read it it seemed as if you had decided to make a lot of incorrect claims about the library without doing much research before hand, and I was eager to correct the errors. For future reference, a lot of things I write are documented in much more detail outside of the source than in it, so that's a better place to start.

kikito wrote:The critic about flux having a global list of tweens still stands: it is still a bad decision, for the reasons I mentioned before.

I obviously disagree, but I won't try and convince you otherwise. The user can chose not to use flux's global group if they don't want to. Additionally they can use tween.lua instead; this was something I noticed when you released version 2 which I think put even more distance between the libraries in terms of feature overlap, it felt like it'd make it easier for people to pick between the two based on their preference, since the libs now have a clearer separation in how they go about things.

kikito wrote:It means that the target is kept as a reference, not as a copy. This makes it possible to tween to dynamic positions.

This sounds pretty cool. Was it mentioned in your README? If not I think you should definitely include it there.