Feature Request: Import Spritepacks

General
1

It’s been really sweet being able to use our own images from our photo library and Dropbox. While the functionality is very welcome, there are still a couple of shortcomings, namely a) it’s difficult to organize the sprites for several projects, b) when sharing code, it can be difficult to share the related sprites in a manner that isn’t cumbersome, and c) it’s easy to forget which sprites belong to which project, unless some prefix is used for the image names. I was thinking that it would be great if there was a way to import full spritepacks into Codea using the app itself instead of having to use iExplorer to load them into the Spritepacks folder in the app bundle.

I was thinking a way this could be implemented would be to extend the current Dropbox functionality. For example, if there are any .spritepack suffixed folders in my Apps/Codea folder in my dropbox, they could be synced and treated as individual spritepacks when referenced in code or when bringing up the sprite picker. So, for example, if in my Dropbox I have “Apps/Codea/Playing Cards.spritepack”, I could reference them in code as “Playing Cards:ace_of_spades”, and they would appear to be “native” spritepacks when bringing up the spritepicker.

Another take on this would perhaps be to have Codea sync the .spritepack subfolders in Apps/Codea right into identically named folders in Documents, and then have Codea look for .spritepack folders in Documents the way it currently does the Spritepacks folder in the Codea app bundle.

Does this make sense, and if so, is this doable?

2

That sounds good, @toadkick. Perhaps only Dropbox is allowed custom sprite packs? To keep things simple.

One other mechanism we will be exposing soon are project sprite packs. So any images in your project bundle can be referenced by “Project:Sprite”. This will go some way to lessening cross-project pollution.

I’d like to hear some more discussion on this. Would a Project mechanism solve this, or do we need full custom sprite packs?

3

There’s a part of me that says that so long as we’re in a regime of “cut and paste” to import a project, any manual messing with spritepacks is an extra step (barrier to entry) and likely cause of failure.

I’d like to see fetchSpritepack(“http://some.url.or.other/blah”) grab a spritepack and save it to the current project, or perhaps add it? So the spritepack isn’t an extra step. If the spritepack was already there, this would simply NOP (or perhaps check to see if it’s been updated, and then update in the background if it has).

This is the functionality of my imageloader stuff, only nice. :slight_smile:

Having said that, I think the concept of special-casing Dropbox to act as a kind of external storage for spritepacks automatically is totally reasonable as well. I’m just not liking “to play the game, cut and paste, then go make a dropbox account, tie it to your codea, and put the spritepack in this magic directory”. (I am liking “if you save your sprites to your project spritepack, it can automagically be mirrored in dropbox”. I’d like that for code, too, but that’s a whole 'nother kettle of fish)

4

Yeah, If you guys were to go the Dropbox route, I think Dropbox-only custom sprite packs would do the trick without making things too complex, as opposed to copying the sprite packs into the Documents folder.

Funny you mention the project-specific sprite packs, because I’ve had something like that rolling around in my head also. Depending on how the project sprite packs are implemented, a Dropbox-based custom sprite pack solution may not be necessary. For example, I know you guys are working on a feature that will allow us to “import” projects into other projects. If I was able to reference an imported project’s sprites as well, then that should be sufficient. If I needed a sprite pack to be accessible to more than one project, I could just create a “sprite pack project” and import that into any projects that wanted to use those sprites.

Out of curiosity, when you say “Project:Sprite”, do you mean something like “[ProjectName]:[SpriteName]”, or is “Project” essentially a shortcut to the current project’s sprite pack? In other words, if my project is named “Solitaire”, would I reference the sprites within that project using “Solitaire:ace_of_spades” or “Project:ace_of_spades”? I ask because if an imported project’s sprites are able to be referenced, it could presumably impact how we would reference those sprites in code and in the sprite picker.

5

The idea was that “Project” references the current project. You make a good point about imported projects. Perhaps they could reference from their project name.

Perhaps any project can be a sprite pack?

6

I think that’s pretty much what I was thinking too. I’ll have to ponder the logistics of it for a bit, but that might just be pretty awesome.

7

I realize that the .codea files got nuked, but what if we had .spritepack files that would unzip and create spritepacks automatically?

8

For me the best idea would be, that you have sub folders in the Dropbox so that you can have more than one custom sprite pack… I personally don’t see, why it should be bound to projects if we are not allowed to share it as one file…

9

So then if you have Dropbox spritepacks, and allow Projects to be sprite packs, which order are they resolved if they have the same name?

10

I’d always go for local first. That way caching would work. Also, please cater for people who don’t have nor want a dropbox account (even if it is just that this feature does not get into out ways, but WebDAV access would also be nice :wink: ).

11

@gunnar_z: Yes, I don’t have nor want a dropbox account. I prefer direct sprite pack bundle import/export, be it as zipped files or specialized folder. Also a sprite pack should NOT be directly/tightly bound to a project because it’s a resource not code. The resource should be referrable by ANY projects, just like the Codea’s given sprite packs. I think .codea-like export/import is the best way. It’s very simple and straight forward.

12

Hmm. Personally I can’t see why having a dropbox account is such a bad thing, but to each their own.

At any rate, philosophically I agree with @Inviso and @bee, but I’m still trying to suss out whether a more pragmatic approach (like project sharing for sprite packs) would be better.

So I’m going back to square one for a sec, please bear with me for the long-winded post(s):

Custom sprite packs are desirable because they would ideally provide 3 things: 1) a way to share common resources among several projects, 2) a non-cumbersome method of organization for a large amount of sprites, and 3) a way to share sets of sprites with other Codea users.

Currently, Codea only really solves #1, in that we can access any loose sprites in the Documents folder, and we can access sprites synched to the Dropbox.spritepack folder. So what we are looking for here is a way to solve #2 and #3.

The dropbox method I proposed would solve both of those, however since there are people who are not keen on using dropbox it is not ideal (though honestly, a part of me is inclined to just say “Deal with it”, since there are a host of other iOS apps for which Dropbox is the only mechanism for doing things like this). Project sharing could solve #2, depending on implementation, but it is not ideal because it tightly couples resources with code, and presents priority issues when presented with images with the same name in theoretical custom sprite packs. Not sure if/how would handle #3, again because I don’t know the implementation details.

iOS pretty strictly limits the ways we can get bundles of images into Codea. As I see it there are only 4 approaches, 2 of which Codea already provides facilities for: import via photo library, import via dropbox, import via iTunes file sharing functionality, and import via a custom URL scheme.

So I think the issue is, what we really need is just a way to organize the sprites for which we already have the mechanisms to import (by organize I mean create/delete sprite packs, and add sprites to and remove sprites from a sprite pack), and we need a way to export entire sprite packs to share with others.

See my post below for a proposed solution.

13

Sorry about the two long posts back-to-back, I have been furiously editing and refining my thoughts. Here is a proposed solution for sprite pack importing/exporting: Use iTunes file sharing and/or a custom URL scheme to get entire sprite packs into/out of Codea.

Codea would create a subfolder in Documents called SpritePacks, analogous to the SpritePacks folder in the app bundle. Documents/SpritePacks is added to the sprite pack “search path”, and any subfolders in here with the .spritepack extension are treated in code and in the sprite picker as if they were in the app bundle SpritePack folder (i.e. an image file named ace_of_spades.png in “Documents/SpritePacks/Playing Cards.spritepack” would be referenced in code as “Playing Cards:ace_of_spades”).

For explanation purposes, let’s consider a .spz file to be a zipped up folder of sprites (e.g. “Playing Cards.spritepack” would be packaged into Playing Cards.spz).

In the root of the sprite picker UI, there is an “Import” option, that would allow you to select a .spz file in Documents, and would unzip them into a corresponding folder in Documents/Spritepacks. When drilling down into a sprite pack in the sprite picker, an “Export” button would be presented, which would zip up the .spritepack folder to a .spz file and place it in Documents. This seems like a pretty elegant way to package/unpackage sprite packs, and would make them easy to add/extract using iTunes file sharing.

Additionally, we would be able to add images using the sprite picker (or similar UI) from our photo library and dropbox directly into a .spritepack subfolder of Documents/SpritePack, and to delete images from a .spritepack subfolder. So, for example, if in the sprite picker I am currently viewing my “Playing Cards” sprite pack, I would have a button there to add a sprite from my photo library, and a button to add a sprite from my Dropbox.spritepack folder (the Dropbox synching mechanism would stay the way it is now, where all synched dropbox files would live in Dropbox.spritepack). The delete mechanism would work exactly the way it currently does now when I have navigated to the “Documents” folder in the sprite picker, except that it would also be exposed when navigating to the sprite packs that live in the “Documents/SpritePacks” folder. Also, in the root of the sprite picker UI, there would be a button to create a new .spritepack subfolder (so that it would be possible to assemble sprite packs entirely in Codea), and a way to delete a .spritepack subfolder.

Additionally, to facilitate sharing sprite packs with other Codea users, Codea would take any .spz files thrown at it via a custom URL scheme (a la iOS’ app-specific URL capabilities) and automatically unzip them into Documents/SpritePacks. This would actually make it possible to import/export sprite packs without even having to fiddle with iTunes file sharing, since .spz files could be emailed or shared via the web pretty easily. In fact, Codea could allow us to email .spz files to someone as an additional export facility.

I think this is the most elegant solution for hitting all 3 points mentioned in my post above. I’m interested in hearing everyone’s thoughts on this.

Also, fwiw, if we had something like this, there would be no need for project-specific sprite packs. I think having both of these options just adds confusion. For my part, I would definitely prefer this to project-specific sprite packs.

14

Like I said above:

“…what if we had .spritepack files that would unzip and create spritepacks automatically?”

so, yeah, /agree

15

@Vega: yeah, I understood that, I just wanted to flesh out more thoroughly the mechanisms to enable both importing and exporting, as well as being able to create and manage custom sprite packs within Codea itself. There are a lot of finer points that need to be taken into consideration beyond “what if we had .spritepack files that would unzip and create spritepacks automatically?” :wink:

16

@toadkick thank you for the detailed proposal. I agree with a lot it. However, Apple has rejected us in the past for enabling iTunes File Sharing. They claim it allows downloadable code — it doesn’t, really, since you can’t actually put projects into Codea using it — but we can’t really fight with them on this point.

The URL scheme is okay, though it leaves users with only one mechanism for import and export. The main issue is designing and implementing all the UI for managing, importing and exporting Sprite Packs.

17

Do you think apple would be okay with iTunes file sharing if you only copied images out of the zipped files, and if you could prove to them that you were doing so?

Honestly, even if they didn’t allow it, the URL scheme would be a good way to go anyway. After all, one mechanism for sharing is better than zero mechanisms for sharing.

I understand the UI would be some work, but I think it’s totally worth it. I would even be willing to pay via IAP if that would provide incentive to do the work :slight_smile:

18

We’ll probably start by allowing project-local images, and the ability to move images between sprite packs.

Once that’s done we’ll look at mechanisms that allow sprite pack sharing, importing and so on.

19

Sounds good @Simeon, thanks :slight_smile:

20

I know I’ve asked for this across several threads, but I’d love tosee read/write access to the photo library for the user. How great would Codea be as a tool for developing image manipulation?