LÖVE Studio for LÖVE 0.9.0

[kclanc]

Hi,

I'm just posting this to let everyone know that LÖVE Studio, my windows IDE for LÖVE, now supports LÖVE 0.9.0. Its two strongest features are static type driven intellisense and an error trapping debugger.

Though I have not done an enormous amount of work on the IDE itself, there is one new features which has been added in addition to 0.9.0 support: the ability to spawn the LÖVE process inside LÖVE Studio, which allows the programmer to easily examine her code while watching/playing her game.

In addition to that, there have been some minor bug fixes. If this sounds interesting to you, please take a look at my bitbucket page. An installer is provided in the downloads section.

Happy Holidays,
Kevin

[lost_RD]

I tried it but errors in love.run() are an issue.

[kclanc]

Thanks for trying love studio. You are bumping into some aspects of the type system that I probably have not documented properly. Sorry about that. I have updated the documentation accordingly.

First, only expressions which have type boolean are allowed to appear in the conditions of if statements. If love.math had a nillable type, you would be able to use the expression love.math ~= nil rather than just love.math. However, I transcribed the API assuming that love.math would always be non-nil, which I now realize is not always the case.

A similar problem is happening with Love.Window. I did not transcribe any of love's built-in functions as nillable. love.window has a non-nil type, so you can't use the and operator with it. The and operator can either appear as a 1.) traditional "logical and" or 2.) a ternary operator. Either way, it expects a boolean as its left-hand operand.

If the type system is bugging you too much, you could disable it in project -> settings, but you won't get as good of an intellisense experience that way. I would recommend just enabling all of the love api's various modules and assuming that they are non-nil. Is there a particular reason that you would need to do otherwise?

I could be wrong, but I suspect that the reason you are checking that each of the love modules are non-nil is because you are being careful: you want your program to never crash, even if various variables in your program start getting randomly set to nil. The problem with this is that if such problems arise, simply guarding everything with conditionals is unlikely to solve the problem. It may prevent your program from crashing, but your program will likely break in other ways. For example, not being able to pump events may prevent you from responding to input in some (all?) situations. Crashing may be preferable to the aforementioned scenario because it may highlight the fact that there is a problem which needs to be fixed. Sorry if this seems a little pedantic, but I feel that it is a good opportunity to explain some of the motivation behind love studio's type system.

[slime]

I would recommend just enabling all of the love api's various modules and assuming that they are non-nil. Is there a particular reason that you would need to do otherwise?

Disabling love.joystick can reduce startup time significantly. Some of the modules also use a little bit of memory which you might want to save by disabling them.

[kclanc]

I just realized that you posted the default love.run function. I think all of those if statements make more sense in the default run function due to the fact that it is intended for arbitrary games. You really don't know which modules will be enabled in an arbitrary game. For a specific game, you're going to have a much better idea, though. That said, you still may want to have separate distributions of a game in which different sets of modules are enabled. I guess I could just make all love modules nillable, but I'm still on the fence about this.

Aside from that, I have noticed another sort of type error: a "variable not in context error". That means that the variable in question either a.) does not have a local binding or b.) was not assigned as a global in the globals module. Love Studio forces programmers to use globals in a disciplined way, assigning them all inside of a single module. Most lua projects do not conform to this discipline, so it won't necessarily be straightforward to modify them so that they pass the typechecker. If you want to use an existing project with love studio, your best bet is probably to disable the type checker.