Post-0.10.0 feature wishlist

[zorg]

A good way to do is to just integrate any well used and made community module into the love code.

Then why not just release a wrapper lib for those external libraries, which would basically do this:

Code: Select all

love.whatever = require 'lib.whatever'

Then the job of maintaining the libs would remain separate from löve's own codebase... not to mention that libraries tend to fix bugs at a rate faster than löve's "release schedule"; Being timely with releasing bugfixes is always a plus.

Of course, people can always roll their own if they want.

I would say that this didn't really justify adding these libs to be inside the distribution if i can just as easily opt-out of them (especially the scene graph and the camera comes to mind, animations too; there are myriad ways to accomplish each, why force even one on the framework?), even if one could disable them through love.conf.

Question is, would the non-usage of these kinds of integrated libs mean that one couldn't use some other arbitrary function or whatever in another love module. (in other words, would there be extra dependencies?) I already see the hypothetical love.scene and love.camera modules depend on love.window at minimum.

Of all things listed, i'd only agree with profiling being integrated solely because that's easy to code wrong, in turn leading to inaccurate benchmarks and whatnot. (thinking of timings only, not mem usage, for example, though i'm sure it's just as easy creating a function that measures that inaccurately as well.)

[leiradel]

I know that you guys want to keep love as a basic framework, but i really feel that for love to be the best library for new users, it has to a "batteries included" distribution.

As such, I hope that love will have its own default modules for:

• Tilemap support
  Scenegraph support
  Basic UI support
  Sprite based Animation support
  Camera support
  Gamestate support
  Profiling Support

This will ensure that the most important modules that are used in almost all 2d games are there and will always be supported. Of course, people can always roll their own if they want.

A good way to do is to just integrate any well used and made community module into the love code.

Scene graph? Please no. That's what I hate about other frameworks, that they impose a certain structure on you.

[Davidobot]

I do not believe there should be default modules. I love LÖVE for its vanilla structure, if you wish you to have those features, you can make use of the user-created libraries. I, for one, prefer to have my own game state and tile management libraries.

In terms of features, I second a better audio API, window transparency, maybe multiple windows too. Mobile features such as ads would be nice too.

[Tjakka5]

As stated in the wiki, the function love.touch.getPressure() will usually return 1, as most devices do not support pressure.
However, you could somewhat simulate pressure by getting the surface of the object touching the screen.

That is, when the player is softly touching the screen not his whole fingertip will be on the screen, but as he applies more pressure more skin would be pressed against the screen.

I was hoping this could somehow be supported also, so we can atleast have some degree of "pressure" control.

[bobbyjones]

I think having an official battery included distribution would be cool. Basically it would be for new people. We could have it include zerobrane and major libraries that are useful. It could have it's own release schedule and be community maintained. I think having something like that would help get more people to use and respect love. That way someone who wants to test love or use it for a class could just download one package and get started. Maybe it can also include thing needed to export to the various platforms love officially and maybe unofficially support.

[Xgoff]

• Support for different Image and ImageData pixel formats, including floating-point formats (e.g. storing arbitrary number values in pixels). This can be useful for advanced rendering techniques and similar things, but said formats aren't always supported by all of the graphics hardware that LÖVE supports. Also, LÖVE's APIs are all designed for "byte" color components that are in the range of [0, 255], so it's a bit awkward to add things that require different value ranges now.

i'm still in the camp that thinks colors should have been [0.0, 1.0] from the start

but people just have to be attached to bytes

[slime]

i'm still in the camp that thinks colors should have been [0.0, 1.0] from the start

but people just have to be attached to bytes

I made a love-experiments branch to test that out, a little while ago. I'm mainly worried that it will be less intuitive to set colors in the general case.
e.g.: https://bitbucket.org/bartbes/love-expe ... nogame.lua

[undef]

I think it's more intuitive to use values between 0 and 1, and in many cases it's less code given that interpolation functions you often use usually return values in that range.

[bobbyjones]

I think most art programs or online color pickers use 0-255 so I can see how it is easier for noobs on that front.

[Jasoco]

• Improved development experience on iOS. It needs more documentation and tutorials, and I want to try to put LÖVE on the App Store eventually (although it might not happen due to the App Store rules.)

This is a feature I'd love to see. I'd pay good money for it just to be able to experiment. Though I'm not really interested in mobile gaming anymore unless Löve iOS can access the Made For iPhone API for external controllers.