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? 
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. 
[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.
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.
Switching to a localized infrastructure would also be nice. .seeall has been deprecated so it would be great for Lime to modernize there too.
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.
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)
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.
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.
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.
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.
Switching to a localized infrastructure would also be nice. .seeall has been deprecated so it would be great for Lime to modernize there too.
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.
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)
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.
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.
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.
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ā¦ [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.
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ā¦ [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.
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.
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.
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. 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]