What's Most Important for Lime version 4?

If an updated version of Lime were going to come out after the first of the year (insert innocent look here), what would you like to see in v4?

Think of this as kind of a wish-list, although maybe keep it reasonable? :slight_smile:

Jay
Outlaw Game Tools

PS - This isn’t any kind of official announcement, although when an official announcement comes it will probably be really low-key. :wink: [import]uid: 9440 topic_id: 33825 reply_id: 333825[/import]

Are you going to be on this Jay? That would be amazing. I make no promises about “reasonable”, though.

  1. Top priority has to be culling. Lime just isn’t feasible for non-tiny projects due to the memory requirements of keeping an entire tilemap in memory. Another user here seems to be rolling their own solution which seems much faster and capable of very large maps (>40k+ tiles) but doesn’t have it available for consumption yet.

Culling is also crucial for supporting multiple devices - the world map for Dragon Quest II is far beyond the performance profile of the iPad 1 or iPhone 4, for instance, even if the iPhone 5/iPad 4 might have a fighting chance (though not particularly likely; 256x256 tilemaps take a crapload of memory and substantial loading time.)

I can’t make it clear enough how important this is - I had an RPG project that was functioning pretty well and had to abandon it completely because Lime lacked this feature.

  1. Switching to a localized infrastructure would also be nice. .seeall has been deprecated so it would be great for Lime to modernize there too.

  2. A clean sweep of all of the mixed code. Lime has a lot of either forgotten or deprecated components that I only got any sort of clarity about by asking Graham. I think you’d find people like myself more than willing to help get the online documentation up to snuff if we knew what was real.

  3. Revamped commands. Better docs would help here but there are a lot of commands that expect table variables (particularly { row=x, column = y} when it could just as easily be function(xTile,yTile)

  4. Folder support. I hacked this in but there’s no particular reason not to offer Lime within a folder now, particularly if its going to keep so many code files.

  5. State support. Longer term but considering all of the effort Lime puts towards holding sprites in a layer it would be nice to have some sort of restore table or something to use in case we need to unload/reload it.

  6. Proper Tiled Layer Order. Maybe this got fixed but in my experience with Lime 3.5b I was having trouble getting the correct “sandwich” order of tile and sprite layers - it wasn’t reflecting the order in Tiled.

Probably more but that’s all that comes to mind right this minute… [import]uid: 41884 topic_id: 33825 reply_id: 134511[/import]

Are you going to be on this Jay? That would be amazing. I make no promises about “reasonable”, though.

  1. Top priority has to be culling. Lime just isn’t feasible for non-tiny projects due to the memory requirements of keeping an entire tilemap in memory. Another user here seems to be rolling their own solution which seems much faster and capable of very large maps (>40k+ tiles) but doesn’t have it available for consumption yet.

Culling is also crucial for supporting multiple devices - the world map for Dragon Quest II is far beyond the performance profile of the iPad 1 or iPhone 4, for instance, even if the iPhone 5/iPad 4 might have a fighting chance (though not particularly likely; 256x256 tilemaps take a crapload of memory and substantial loading time.)

I can’t make it clear enough how important this is - I had an RPG project that was functioning pretty well and had to abandon it completely because Lime lacked this feature.

  1. Switching to a localized infrastructure would also be nice. .seeall has been deprecated so it would be great for Lime to modernize there too.

  2. A clean sweep of all of the mixed code. Lime has a lot of either forgotten or deprecated components that I only got any sort of clarity about by asking Graham. I think you’d find people like myself more than willing to help get the online documentation up to snuff if we knew what was real.

  3. Revamped commands. Better docs would help here but there are a lot of commands that expect table variables (particularly { row=x, column = y} when it could just as easily be function(xTile,yTile)

  4. Folder support. I hacked this in but there’s no particular reason not to offer Lime within a folder now, particularly if its going to keep so many code files.

  5. State support. Longer term but considering all of the effort Lime puts towards holding sprites in a layer it would be nice to have some sort of restore table or something to use in case we need to unload/reload it.

  6. Proper Tiled Layer Order. Maybe this got fixed but in my experience with Lime 3.5b I was having trouble getting the correct “sandwich” order of tile and sprite layers - it wasn’t reflecting the order in Tiled.

Probably more but that’s all that comes to mind right this minute… [import]uid: 41884 topic_id: 33825 reply_id: 134511[/import]

Richard,

Sorry for the delay in replying, I’m finally on the tail-end of flu that lasted a full week – at day 3 when I thought it was letting up it kicked in with a vengeance. All I did for the next few days was snooze and watch Netflix. :slight_smile:

The new home of Lime is going to be here: http://lime.outlawgametools.com

That’s an awesome wish list! That’s the kind of stuff I’m looking for.

One of the things I’ve read multiple times is that Lime has tried to take on too much – and offering more “hand-holding” often means you give up power/performance. That’s not a dig at Lime – almost everything we do as developers has to take that balance into account. Heck, Corona SDK itself does, as well.

Right around January 1st I’ll be digging into Lime to see how best to proceed. Are there things that need to go by the wayside? Are there some things that could be “tweaked” and we keep all the features plus get better performance? Is the foundation right for lots of future updates?

Graham has done a *fantastic* job at creating a body of work that’s been used by a ton of people – I’m looking forward to seeing how I can help usher Lime into a new era.

Anyone else with thoughts/wishes/comments about Lime and where it should go?

Jay
[import]uid: 9440 topic_id: 33825 reply_id: 135084[/import]

I haven’t used Lime - but always kept aware of its development.

The biggest issue, as Richard outlined, always seemed to focus around performance - so I think that is perhaps the single biggest element to focus upon.

Glad to see somebody taking up the reigns. [import]uid: 33275 topic_id: 33825 reply_id: 135104[/import]

Jay:

It’s quite possible Lime had a lot of hand-holding features, but as of 3.5b most seem deprecated or undocumented. I think you have a great opportunity here because the framework has petrified so much that you can make changes at will; personally I don’t think Legacy is a big deal. Leave 3.5b access to anyone who needed it, and then make 4 the fresh new start.

The step too far I think Lime took was in trying to wrap too much of the Corona pipeline in itself. Spawning objects according to Tiled objects, for example, quickly fell out of favor because users have other methods (like imageSheets) to consider. Lime needs to be flexible; it needs to bridge the tile background/foreground world with the rest of the Corona engine, but ideally it shouldn’t attempt to replace it - if it replaces too much then every time Corona Labs makes a change Lime will be broken and lagging a step behind.

(I’d point out specific features but as the website is now gone, I really have no idea what to point at…)

Lime’s roots should be:
(1) A fast, working tile engine that supports very large environments. I think it’s reasonable to assume the iPhone 4 becomes the bottom platform next year, so that’s a reasonable target for performance/memory constraints. If you can’t run the Dragon Quest 2 world map (256x256) or a Super Mario Bros. level (187+x13) there’s a problem.

(2) A helper for common tasks related to the tile engine, like camera control, snap-to-sprite, layering, possibly parallax, etc.

(3) An interface between Tiled and Corona. Tiled was one of the best decisions of the software because it’s multiplatform, open-source, and it means you don’t have to get your hands dirty writing/maintaining tile placement software.

Other Wishlist Features
(1) World Wrap : Huge for RPGs; just need to connect the map edges.
(2) Trick Danny into supporting Nearest Neighbor OpenGL Rendering : For 8bit fans… :wink: [import]uid: 41884 topic_id: 33825 reply_id: 135120[/import]

Richard,

Sorry for the delay in replying, I’m finally on the tail-end of flu that lasted a full week – at day 3 when I thought it was letting up it kicked in with a vengeance. All I did for the next few days was snooze and watch Netflix. :slight_smile:

The new home of Lime is going to be here: http://lime.outlawgametools.com

That’s an awesome wish list! That’s the kind of stuff I’m looking for.

One of the things I’ve read multiple times is that Lime has tried to take on too much – and offering more “hand-holding” often means you give up power/performance. That’s not a dig at Lime – almost everything we do as developers has to take that balance into account. Heck, Corona SDK itself does, as well.

Right around January 1st I’ll be digging into Lime to see how best to proceed. Are there things that need to go by the wayside? Are there some things that could be “tweaked” and we keep all the features plus get better performance? Is the foundation right for lots of future updates?

Graham has done a *fantastic* job at creating a body of work that’s been used by a ton of people – I’m looking forward to seeing how I can help usher Lime into a new era.

Anyone else with thoughts/wishes/comments about Lime and where it should go?

Jay
[import]uid: 9440 topic_id: 33825 reply_id: 135084[/import]

I haven’t used Lime - but always kept aware of its development.

The biggest issue, as Richard outlined, always seemed to focus around performance - so I think that is perhaps the single biggest element to focus upon.

Glad to see somebody taking up the reigns. [import]uid: 33275 topic_id: 33825 reply_id: 135104[/import]

Jay:

It’s quite possible Lime had a lot of hand-holding features, but as of 3.5b most seem deprecated or undocumented. I think you have a great opportunity here because the framework has petrified so much that you can make changes at will; personally I don’t think Legacy is a big deal. Leave 3.5b access to anyone who needed it, and then make 4 the fresh new start.

The step too far I think Lime took was in trying to wrap too much of the Corona pipeline in itself. Spawning objects according to Tiled objects, for example, quickly fell out of favor because users have other methods (like imageSheets) to consider. Lime needs to be flexible; it needs to bridge the tile background/foreground world with the rest of the Corona engine, but ideally it shouldn’t attempt to replace it - if it replaces too much then every time Corona Labs makes a change Lime will be broken and lagging a step behind.

(I’d point out specific features but as the website is now gone, I really have no idea what to point at…)

Lime’s roots should be:
(1) A fast, working tile engine that supports very large environments. I think it’s reasonable to assume the iPhone 4 becomes the bottom platform next year, so that’s a reasonable target for performance/memory constraints. If you can’t run the Dragon Quest 2 world map (256x256) or a Super Mario Bros. level (187+x13) there’s a problem.

(2) A helper for common tasks related to the tile engine, like camera control, snap-to-sprite, layering, possibly parallax, etc.

(3) An interface between Tiled and Corona. Tiled was one of the best decisions of the software because it’s multiplatform, open-source, and it means you don’t have to get your hands dirty writing/maintaining tile placement software.

Other Wishlist Features
(1) World Wrap : Huge for RPGs; just need to connect the map edges.
(2) Trick Danny into supporting Nearest Neighbor OpenGL Rendering : For 8bit fans… :wink: [import]uid: 41884 topic_id: 33825 reply_id: 135120[/import]

Thanks for the comments. I won’t really be diving into Lime until January – at that time I’ll probably be posting more and more questions. :slight_smile:

Jay [import]uid: 9440 topic_id: 33825 reply_id: 135869[/import]

Thanks for the comments. I won’t really be diving into Lime until January – at that time I’ll probably be posting more and more questions. :slight_smile:

Jay [import]uid: 9440 topic_id: 33825 reply_id: 135869[/import]

Excited to hear that Lime development will continue. What happens to the existing (paid) users of Lime? Will there be a free/reduced upgrade? [import]uid: 49447 topic_id: 33825 reply_id: 136263[/import]

Once you get the performance nailed then you can count on my support. It’s the only thing that has prevented me pulling the trigger. [import]uid: 119832 topic_id: 33825 reply_id: 136268[/import]

Did Graham provide you with the existing customers’ e-mail addresses or do we need to “re-enlist” in order to get notifications of Lime 4 availability.

[import]uid: 9035 topic_id: 33825 reply_id: 136321[/import]

Excited to hear that Lime development will continue. What happens to the existing (paid) users of Lime? Will there be a free/reduced upgrade? [import]uid: 49447 topic_id: 33825 reply_id: 136263[/import]

Once you get the performance nailed then you can count on my support. It’s the only thing that has prevented me pulling the trigger. [import]uid: 119832 topic_id: 33825 reply_id: 136268[/import]

Did Graham provide you with the existing customers’ e-mail addresses or do we need to “re-enlist” in order to get notifications of Lime 4 availability.

[import]uid: 9035 topic_id: 33825 reply_id: 136321[/import]

I was in talks with Graham to create a second platform tutorial to be focused around Lime. Would you still be accepting third-party documentation around Lime’s use and functionality? [import]uid: 135394 topic_id: 33825 reply_id: 136761[/import]

Sorry for the delay in replying – Christmas and stuff, you know. :slight_smile:

Existing customers will be able to upgrade free or at a greatly-reduced price – not sure yet.

Graham did give me the existing customer database so as soon as there’s something to tell you, I’ll be doing that, for sure. :slight_smile: If you sign up on the Outlaw Game Tools site you’ll get info on Lime as well as the other tools we put out.

I will be accepting 3rd-party tutorials but I’d say you should probably wait a bit until I figure out how this will all shake out. I’m trying to get a couple other projects out the door and then will be turning my attention to Lime.

Thanks.

Jay
[import]uid: 9440 topic_id: 33825 reply_id: 136779[/import]

Now that you are taking over lime what do you expect the pricing range to be about. [import]uid: 76607 topic_id: 33825 reply_id: 136843[/import]