Sprites and views -- how should they work?

[Ashen]

Isn't that how the 'Import GIF/FLC Frames' option works anyway?

Since I'm posting anyway: I'd second Alynn's autonumbering suggestion. Or possibly batch re-numbering, so you select a group of sprites, set a starting number and it automatically numbers them in sequence.

[Rui 'Trovatore' Pires]

What do you mean? There's already an "import GIF" feature. It imports all frames in the sprite, and I love it.

[Pumaman]

Thanks for the feedback so far, guys.

Yes, there already is a "Quick import multiple sprites" option that allows you to import lots of image files in one go.
There is also a "Import animated GIF frames" option that allows you to import animated GIF files.

These options are on the right-click menu when you click in the background of the sprite manager (ie. not on a sprite) -- it's interesting that some people don't realise that these options exist.

So, another question from me to you -- does anyone actually use the feature to select a portion of the image file to import, or do you always just press "Grab entire image". And in that case, would it be ok to get rid of that sprite import window and just assume the whole sprite is being imported?

[DoorKnobHandle]

I use the partial sprite grabber for importing sprites from sprite-sheets. I think it remains useful for some.

[Gilbert]

I always grab part of the whole image, so that really should be kept.

[Janik]

I think it would be handy if each sprite had its associated file path saved somewhere, so that if you modify the file you could select a bunch of images and click something like 'Reimport from file' to get the updated version.

[Rui 'Trovatore' Pires]

I always use part of the whole image, and almost always do a "tiled sprite import" - it's the best thing since sliced bread and agsedit.exe.

[joelphilippage]

i think you should be able to back click and have the option import section of sprite and import whole sprite so you have the option. I do use it but not very often.

[strazer]

I think it would be handy if each sprite had its associated file path saved somewhere, so that if you modify the file you could select a bunch of images and click something like 'Reimport from file' to get the updated version.

That reminds me of this tracker entry that I quite like: Sprite manager using files from disk

[Joseph DiPerla]

I have One requests. I may as well even demonstrate how or why this would be used...

1) Allow the ability to resize the sprites in the sprites folder.

A reason is in case you imported sprites and want to resize them without exporting them out. In this case, this would be most helpful for me with my Simpsons game where the characters are huge and I dont have the original files anymore. So rather than export each sprite and resize them, then import them and redo the views, Maybe we could just resize them in the sprite manager. Maybe an additional option could be to do a mass resize. Meaning you could resize more than one at a time.

[monkey0506]

If the sprites were linked to external files you could do that by updating the external file. So IMO the external linking would be the more reasonable request as it would also take care of that.

[RickJ]

There are a number of ideas presented in this thread that have the same or a similar to some of the suggestions I would like to make.   

Views

• Objectized Views - Rui, this is a great suggestion and I would like to second it and perhaps elaborate a bit more.   I have always thought a view should be owned by the character or object to which it applies.   I don't think the ability to reuse views acorss multiple characters/objects is of much benefit or even a sound practice.  I think we would derrive much more benefit from the OO-tization of views as well as eliminating the need for some of the other suggestions. 
  
  
• Enumerated View Names - If view OO-tization is not implemented then I would like to see enumerated names generated for each view instead of the view number.  This would make views portable and eliminated hardcoded numbers from the script.  So I guess we would endup with something like eView_CharacterViewname or eViewCharacterViewname (e.g. eViewRogerWalk).   
  
  
• View Numbering - If view OO-tization is implemented then I would like to see views uniquely numbered within each character or object starting at 0 (or 1 ) rather than each view having a globally unique number as is done now.  This would work somethin like the character's inventory does now. 
  
  
• View Storage - If view OO-tization is implemented then I would like to see object views stored in the room file where the object is defined.  This way each person in a group project could work on a different room and then the only thing they would need to do to merge all their work would be to collect the room files in to the master game.  Also see below for sprite storage.
  
  
• Export - I would like to be able to export anything that uses a view the same as we do characters now.  I guess what I am asking is that the character export mechanism be made more general sao that anything that can be animated could be exported/imported the same as characters are now.    As a side note it would also be nice if the export mechanism could also pickup the script code associated with the character or whatever and dump that as well.
  
  Sprites   
  
• File Linkeage - I think it is a great idea to retain the filename of the sprite.  This would help identify what the sprite is and could also be used as the default file name whensprites are exported.   
  
  
• Sprite Update - If the filename was retained then it would be possible to have an update function.  In this way if someone made changes to one or more sprites then one would only need do an update.  I guess you would also need to retain some other info about how the import was made.  I think this would be very useful, especially for group projects. 
  
  
• Enumerated Names - I would like to be able to access sprites in the script via an enumerated name rather than a number.   If the import filename was retained these names could be generated automatically so you would have something like eSprite_Filename or eSpriteFilename
  
  
• Storage - I would like to have the ability to store sprites in the room files where they are used.  Most of the time object sprites are drawn for a specific room and do not match the perspective or scaling of any other room in the game.     Perhaps this could be done by having the ability to assign a sprite folder sub-tree to a room.  One way this could work,  for example, would be to have a right click on the folder bring up a property dialog.  There could be a drop down list that includes each room and the main game/sprite.  This would make it much easier for group projects and would allow the possibility of some really interesting contests or activities.   
  
  
• Ownership - There is an argument to made that sprites should be owned by the game elements that use them.   The counter argument is, I suppose, that in the interest of minimizing game size it is desired to reuse sprites as much as possible.  Well if we think this thru a little we can come to realize that one doesn't necessarily preclude the other.    Onership can imply many things so lets think about them individually. 
  
  Navigation & Organization - This has to do with what the designer sees when using AGS edit.  So if a character owned a collection of sprites presummably you would want to be able view that collection from that character's edit pane.  Likewise if you were using the sprite manager you would also want to see these sprites presumably in some kind of a grouping such as a folder. You would also want to identify which character that grouping belonged to.   
  
  Storage - Ownership would also imply that sprites would or should be stored in the same place/manner as the owning entity.  This perhaps doen't have much impact on the current version of AGS but if some future version were to address difficutiles realized by group projects this would perhaps become important.
  
  Import/Export - When you import or export something such as a character, object or whatever, you would want to grab everything that it owns.  The character import/export kind oif does this now, except it doesn't grab the sacript code.
  
  Scope/Naming - Using the enumerated naming scheme described above or the current numbering scheme would keep access to sprites global, allowing them to be shared throughout the game. 
  
  ===============================
  In reponse to CJ's second question:  These days I only import the whole file.  I quit using the other stuff a long time ago..  Just out of curiosity,  how do those of you who are using "tiled sprite import" prepare your sprit sheet?  You have to do that manually, don't you?   I have been using Gale and it let's you automatically export each frame to individual files.  Aren't most drawing programs able to automate output of individual files right out of the box or with a simple macro? 
  
  I would be interested in what CJ has in mind when he asked.   Perhaps we should ask him what we would we get in return for giving up the ability?  Maybe some kick-ass feature that we can't live without, althoiugh we apparently are.
  
  

[Rui 'Trovatore' Pires]

Re Rick's "Tiled Sprite Import" question: I did have to prepare it myself when I used it a lot, but now that I'm mostly a programmer for other people's games I find myself in the nice position of being given GIF files from which AGS extracts correctly-positioned frames. But back when I made LSL2, it was a lifesaver, especially when I realized how to properly output the graphics from SCIStudio to optimal use.

[Joseph DiPerla]

If the sprites were linked to external files you could do that by updating the external file. So IMO the external linking would be the more reasonable request as it would also take care of that.

I'm assuming this was for my suggestion right? If it isn't, just ignore this then. The external sprites are deleted. So now I am just running on the images in my templates so I would love to have a way to resize in-editor(or even at run-time rather than have to change the room walkable area scaling), rather than do it by exporting it and then resizing it and reloading it. Thats why this would be useful for me, and I am pretty sure others may eventually make the same mistake I made and will need some way to change things easily.

I had another idea for organizing the Views in the editor as well.

I was thinking that maybe each view could have more loops within them. Dont automatically assign the first loop to walk up, the second to walk down, etc... Instead, just fill in the loops you need for each view. If they are to be attached to a character, then maybe in the character editor a person could assign a loop for the walking animations there.

Then add a property or function to be executed in the script during run time that if a character changes his clothing, you can just change the walkup, down, left, right, rightup, rightdown,leftup,leftdown view and loop of the character and even the speech view. For instance a script like this: ChangePlayerViewLoop(PlayerId, direction, View, Loop). This is especially usefull if we chose to run next loop with the first loop. Becouse then what happens to that next loop? Does this make sense?

This way, and with more loops per view, we could easily organize all of the views and animation a character will have with just one view. It would be easier to keep track of in my opinion.  Does this make sense?

View an example:
http://energon-plant.com/Images/Sample3a.JPG

[SSH]

Or, just View folders like there are Sprite folders?

[RickJ]

The external sprites are deleted.

Do you mean that you delete them?   If so, why in the world would you do such a thing?   Why not just keep your source files and then modify and re-import as needed.   Then you wouldn't need to export-edit-import.  If the suggested new featue were implemented this would be a simple operation.   Even now you would at least eliminate the export step.   You would also preserve layers and other objects in the source file that are lost in a pixel file (png, bmp, etc).  You really can't be that disk space challenged.

[monkey0506]

Rick...we must (for current world government policies require it) consider that perhaps Joseph has deleted his source files for any of several legitimate reasons: a) he's paranoid that someone may discover his source images lying idly all over his hard drive, steal them, and distribute them as their own work, b) he really is that disk space challenged, c) he's secretly paranoid that image files will one day take over the world unless deleted immediately, d) he really disliked the source images, e) he's a neat-freak to the extreme and doesn't want these images dirtying up his hard drive, f) he is actually an alien terrorist sent to Earth to destroy us by forcing us to consider why on Earth he would delete his source images...

[RickJ]

monkey,

Hehe, I enjoyed your post.   I didn't mean to ridicule Joseph but I really do wonder why he isn't keeping his sprite source.   I've suffered mightyily in recovering the sprites and background images used in DemoQuest an so have a strong opinion.  As for your take on this monkey I'll say this:

a, c, d, e, f - No comment 
b                - CD backup

[Joseph DiPerla]

LOL Monkey!! The correct choice is F though

No, I apologize. Perhaps I didn't explain myself well. All I have left of the game files is what is in the template that I have a download of. The reason for this is becouse when I went to redo my computer harddrive, I backed up the sources onto cd along with other important software and documents. Then I formatted my drives. When I went to put in the cd I made, it had a read error. It wasn't readable. I was pretty sure I had finalized the disc and that the disc was compatible with hundreds of cd/dvd rom drives.

I tried it on my brothers computer and on other CPU's and it didn't work. It was readable after I burned it. But once I redid the system, it was no longer readable. So, the template I made available is where I am going from.

I lost the where's maggie demo source as well. The good thing about that is that I could easily continue that game with the template, being that the demo was small anyway.

But at some point I want to redo those images. I thought this implementation to the sprites would help. If it wont be a feature, then I will spend the extra time to re-edit the sprites, no big deal. But since I wont do it soon, this would be a good feature.

Sorry for the mis-understanding of why I deleted my sprites... I didn't delete them "Intentionally" without a backup. But thats what happened.

[RickJ]

hehe, so Joseph you are also suffering mightily for the same affliction as I.      You of course know that you can now dump a whole folder of sprites in one go. 

Also, if in the future the sprite manager were to retain the file names then then it would be even so much easier to recover from your current situation.   I would also add that the export of room backgrounds could also be improved.  I don't think you can only export the first frame if there is a room animation; perhaps I have missed something.