Adventure Game Studio

Hey,

I'm looking into doing a bit of rework to the Sprite Manager and View Manager, and I know that people have expressed various ideas for how these could work better -- so I thought I'd just post this thread to see whether this is still the case.

If you think the current Sprite and View Managers are fine, then great. But if you have any different ideas on how they should be organised, I'd be interested to hear them.

Cheers
CJ

Great!  I'd really like to see the view list more or less mirror how the sprite manager works, ie the creation of topic views and then sub-views so you can efficiently localize views by character and such.  Also, making both the view list and sprite folder creation dynamic (ie, not based on a static limit) would be a definite plus since I've already run out of folders I can create in Drug Bust and only have about 3/4 of the content in.  The ability to copy and paste individual and group items would also be good and would save on repetition when creating similar blocks (like walk, talk, etc).

So to summarize,

View lists function like the sprite manager folders, in that you can create, delete, copy and open and close nested groups. 

HERO
       -Walk View
       -Talk View
       -Action Views
                   -Punch View
                   -Take View
                   -etc
VILLAIN
        -Walk View
        -Talk View
        -etc

And here is a screen to put this in visual terms and to give you an idea of how I organize things:

(http://members.cox.net/progzmax/screenz.gif)


Also, thanks!

I don't really have any complaints about the Sprite Manager, but it would be nice if the Views pane could be set up so that you could create the loops in any order. Basically my idea would be that instead of statically defining "Loop 0 (down), Loop 1 (left), Loop 2 (right), Loop 3 (up), Loop 4 (down-right), Loop 5 (up-right), Loop 6 (down-left), Loop 7 (up-left), Loop 8+ (no special purpose)" there could be a drop-down menu containing "down, down-left, down-right, left, right, up, up-left, up-right, other" and we could simply assign one of these values to the view. The editor would have to prevent duplicate loops for the same specific purpose (i.e., preventing dual "left" loops) of course but it would make it easier to assign the loops (IMO).

Prog's suggestions sound nice as well.

[EDIT:]

Regarding Bernie's idea, "other (intro), other (main), other (outro)" (for the drop-down menu)?

Do additional feature suggestions also count? If yes, I'd like to make a few:

-An animation loop could have a main loop and Ã, 2 optional subloops - an intro loop, a main loop (repeating until, say, the character finished talking), and an outro loop. This would be easy to use, would save quite a few loops per view and look pretty cool ingame. It's pefectly possible to do this through scripting, but it would use up 3 loops per animation. If I did this for an 8-dir character, I'd run out of loops and would need an additional view.

-A feature to change the speed of a whole loop

-Copying/Pasting/Flipping whole loops

Thanks!

This could sound a little stupid, but, what about an option to delete views??

I know you can delete everythig into a view but I'd really like an option to delete it completely
(http://www.subir-imagenes.com/subir_imagenes_fotos/540ce7d1b7.jpg)
Thanks

To keep this thread concise, before making suggestions for additional features, please review the bug & suggestion tracker (http://www.adventuregamestudio.co.uk/tracker.php) first. Two of these are already on there:

Quote from: Bernie on Sun 03/12/2006 21:11:17-An animation loop could have a main loop and  2 optional subloops - an intro loop, a main loop (repeating until, say, the character finished talking), and an outro loop. This would be easy to use, would save quite a few loops per view and look pretty cool ingame. It's pefectly possible to do this through scripting, but it would use up 3 loops per animation. If I did this for an 8-dir character, I'd run out of loops and would need an additional view.

http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=472

In fact, I think it was you who suggested it in the first place.

Quote from: Joe Carl on Sun 03/12/2006 21:27:48This could sound a little stupid, but, what about an option to delete views??

http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=160

Some things that would be nice...

In the sprite preview, a way to halt the animation and step one frame backward and forward.

Also in the sprite preview, a way to 'nudge' the current frame one pixel up/down/left/right, to make it easier to align animations properly. This could be done via SetFrameOffset, by scrolling/wrapping the graphic around (like it does in FontEdit) or by widening the sprite a bit.

In the sprite editor, it would be nice to be able to insert an empty spot in the middle (right click on any frame, select "insert before this one").

Also, it would be nice to be able to overwrite a loop or an entire frame with the content of another loop or frame - sort of like copy/paste.

$.2

To generalise Bernie's suggestion, it would be nice if a Loop could include another Loop:

Loop: Do 4 pushups
Frame 1: Include Loop "Get down on ground"
Frame 2: Include Loop "do 1 pushup", repeat 4 times
Frame 3: Include Loop "Stand up again"

Also, while we're here, vertical flips might be handy for frames, too

And on DaveGilbert's behalf, making a game with lots of voices is a real pain. The whole speech file handling could do with some friendliness! Ideally looking for a filename that exactly matches the speech text...

This may be possible, but I've never noticed such a feature. I would like an easy way of identifying frame number in the View Manager, like a mouse tool-tip. I would also like to be able to drag and drop sprites from view-to-view and within views.

These are minor suggestions, but I'd find them useful.

Ok, Xmas is getting near, been good all year, so I thought I'd make a wish:

Dear Santa (Pumaman?)

I would like "New Sprite"/"Replace Sprite" dialog that allows you to load a series of files, (say pic1.bmp ... pic25.bmp). Of course all files would have identical options,
i.e. "Transparent=topleft pixel" and "Grab Entire Image".
Source images could be selected using a file browser.

In case of "New Sprite", the loaded pics would occupy consecutive slots in the sprite manager. In case of "Replace Sprites", a selection of sprites would be replaced by the selected pictures. If the number of selected sprites doesn't match the number of selected files an error dialog could be displayed, or a default strategy could be applied.

This would greatly improve the rather cumbersome process of creating animation sequences using (a lot of ) source images, especially if you don't get it right the first time.

Yes, I know about the "multiple sprites in a file" capability, but that completely does not work for me. As far as I'm concerned you can delete that feature.
Also, I quickly browsed the "bugs and suggestion tracker" but could not find anything like this being requested, so excuse me if it's already in that list

Regards, Jazz.

Quote from: Jazz on Tue 05/12/2006 14:22:51I would like "New Sprite"/"Replace Sprite" dialog that allows you to load a series of files, (say pic1.bmp ... pic25.bmp).

Already on the tracker: http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=328
Please add your comments there.

Er, Quick Import Multiple Sprites, Jazz. And as for my thing in the tracker, I think that was simply requesting that if you imported with Quick Import Multiple Sprites then AGS automatically extracted the numbers from the filenames and sorted them before import.

1) loading sprite from a file(or multiple files) rather than the sprite manager. have it imported then automatically into sprite manager.

2. vertical/horizontal flipping so that they can walk sideways and upside down flipping so they can walk on ceilings. saves us the trouble of getting more sprites imported.

Expanding on my previous post:  I don't know how workable this is, but a check box that would make the view list automatically create and fill views based on the layout you have in the sprite manager (even down to labelling them based on the sprite manager folder names.  Obviously not everyone keeps detailed folder selections and such so it would have to be optional, but for those of us who do it would really streamline the process.

Like a "New View Wizard" where we can name the top tier and then one could select any of the check boxes below that could have some corresponding text boxes filled in, and some blank. Obviously the ones already filled in could be walk, talk, pick up; and then the blank ones would be user generated. I suppose people would want to be able to rename the already filled in ones, if they would want to rearrange the second tiers.

I think it would be handy to have a edit sprite option so you would not have to export the sprite, edit it then import it again. sort of like game maker. also I dont know if this is a bug or not but i cant clicking on the preview view button does nothing.

If not a built-in editor, there must be some OLE way to link to external apps to edit sprites...

I don't suppose we can name views in the more friendly way we can now name oObjects, gGUIS and txtGuiTextboxes? It would be a fine thing, instead of having to deal with those capitalised letters all the time, not that pretty. Of course this is related to "objectising" Views, which might or might not be feasible and might or might not even be something you want at the time...

...anyway, if they *were* "objectised", wouldn't it open the door to more powerful possibilities like running an animation FROM a given frame instead of from the beginning (already in tracker, I believe)? And similarly TO a given frame instead of running the whole thing.

Auto numbering based on the highest number in the folder the sprite is being imported into.

For instance, all my gui sprites are numbered from 1000-1999 I have all my gui sprites in their own folder. Currently any sprites imported is given the lowest number available. With this change it will look at the current folder and auto number the sprite the next highest number available in the folder. So if the largest sprite imported is 1324, the next sprite to be imported into that folder is 1325, or allow for giving the sprite a number at import time. In other words, 2 radio buttons, one for auto numbering (the default, or how it works now) or another radio button and a text box so you can tell the editor what sprite number the imported sprite should be.

The most difficult part of this type of implimentation, as far as I can see, it how to make sure that sprite number isn't already in use, which could be checked using the already existing code that checks if the sprite already exists when you manually change sprite numbers.

A feature that I would absolutely adore is the ability to import animated GIFs as sprites. Right now, it will accept an animated GIF but only make the first frame into a sprite. With the new feature, an animated GIF would be imported as a series of sprites.

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.

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

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?

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

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

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.

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.

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.

Quote from: Janik on Sun 10/12/2006 20:02:33
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 (http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=573)

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.

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. ;)

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.
  
  

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.

Quote from: monkey_05_06 on Tue 12/12/2006 16:36:18
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

Or, just View folders like there are Sprite folders?

Quote
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.

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...:)

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  ;D
b                - CD backup :=

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.

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.

A thought struck me just yesterday, and I can't find it on the tracker.

I would find it immensely useful to hear sounds in the View Manager Preview. I'd be happy to have to wait a little while while the sounds 'render' or 'compile' but it would be worth it if it was quicker than having to run the game and cause a particular animation to play.

EDIT: Ahem... thanks for pointing that out Gilbot! That thread offers a work-around for OGG users, but I do think OGG-compatible previews would be a boon.

Quote from: Gilbot V7000a on Wed 15/11/2006 06:40:39
Well, since V2.72, the preview feature can play frame sounds if and only if they're in .WAV format. For more info. about previous discussions, see this thread (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=18067.0).

:=

Quote from: RickJ on Thu 14/12/2006 01:41:02
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.

Basically, due to the current state of the code, I'm looking at almost rewriting the sprite/view editors from scratch -- therefore it's not so much that I want to remove features, but just not to have to re-implement them if nobody is using them.

Thanks for your replies; now I know that people are using the import window and tiled sprites, so they'll be staying.

Final question: does anyone use "Quick import FLC frames" or is it just GIFs that people import?

Just GIFs here.

Out of curiosity, is there some format similar to GIF that allows use of hicoulour modes?

There was a thing called MNG that never really got widespread attention.  There is a new thing called APNG that may or may not get widespread attention.  Here is a brief discussion of the toipic by some of the mozilla folks.

http://weblogs.mozillazine.org/asa/archives/006301.html

Cheers
RickJ

Rick you fool you were logged as DemoQuest when you posted that!!!

As for me I use GIF for animated images. :)

[EDIT:]

Ahhh...prunage (pruning) prevention. It would still be better if you legitimately got away from getting pruned (a.k.a., finish Demo Quest :P).

Awhile back, Strazer told me that users with fewer than 20 posts are removed from the forum after awhile.   So, the previous post was intentionaly done the way it was done.   ;)   

Edit by strazer:

To be clear, AFAIK users only get automatically deleted if, in addition to having posted less than 20 times, they also weren't active (i.e. logged in) for a year or so.
I wrote a pm to the DemoQuest user in the hopes that someone would get an e-mail reminder, read the message and remember to log in once in a while.

But CJ would choose which members not to remove when cleaning, so the DemoQuest account would stay anyway.

Anyway, enough off-topic stuff!

I would only impprt GIF. Didnt really think people use flc.

Quote from: Pumaman on Sun 10/12/2006 15:35:25
There is also a "Import animated GIF frames" option that allows you to import animated GIF files.

Last time I tried that it didn't really work as expected... the aniGIF contained "diff frames" (frames that were mostly transparent except for the spots where they were different from the last frame) and AGS imported them as normal frames.

Quote
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".

I don't use it, but that's because I find it unwieldy. It turns out to be quite a bit faster to open MS Paint with the sprite file, select a frame, hit 'copy', alt-tab to AGS, and right-click to 'insert new frame from clipboard'.

It would help if there was an easier way to change the size of the 'import box' (e.g. ^ v buttons) and if it was easier to select the edge of the image (if you click beside the image, nothing happens, but the first pixel of the image is only one pixel wide)

It would also help if you could just click the 'box' to import that frame, rather than having to 'drag' a line of boxes (first, this gets annoying if the screen needs to scroll; second, some artists add lines around each sprite frame, which need to be skipped).



Oh by the way - it is not visually possible at the moment to distinguish between a sprite with a transparent background, and one with a Pure Pink background. Through copy/paste mistakes it's possible to end up with a sprite that looks like it's transparent, but really isn't.

Oh yeah, it would be nice if, for "assign sprites to view", the loops were named even if they were new. For instance, loop 3 is normally named "walking down" (which is useful) but if it happens to be empty it is instead named "empty"; naming it "emtpy / walking down" would be handy.

I always use the tiled import when importing animations. I do the animations in Gale, save it as a tiled tga, make the shadows transparent in Photoshop (a tiled pic lets me do this simultaneously for all frames instead of having to open several files and do one after another. This way I have saved many hours of work!) and then tile import it into AGS. So to put it clearly: I REALLY HAVE A NEED FOR TILED IMPORT. So please keep it, CJ!

Interesting, though, in how many ways people work!

I would like to suggest a really huge implement...

Everything started when I used a hack program to see the sprites files of the Lucas Arts games, made for SCUMM, and they have a nice way to work with different actions for a same character, using some kind of layer thing.

Let's say that I am making a character, who speaks while he is cooking, I wold make a sprite for his body, sprites for the animation of his hands that are cooking, sprites for the smoke that come from the food, and sprites for his head... All this sprites get together in one view, and are animatedÃ,  simultaneously by one character, but I can control separately each part of him. Like make him stop talking while he keep cooking. This is Very useful to make characters with lots of animation without needing lots of sprites and lots of characters and objects to emulate just one single thing.

I don't know if I made my self clear...
----

Making it possible to rotate the sprites 90°, 180° or 270° is not a bad idea .

I also wanted to see a background manager that worked just like the sprite manager... This would help in the case I want to re use a background image in multiple rooms, just changing their palette configuration, ore just reusing them with different objects and areas...

I know what your talking about. But I dont think its a good idea. It would help reduce space, yes, but there are drawbacks to that:

1)Anyone making their sprites in 3d, would really need to split their characters up well. It would be too hard.
2) Many of us are used to drawing the whole character.
3) Might take longer for Chris to implement.

I think for some this would be a good idea, but for most, it wouldn't. But who knows, maybe Chris will find a way to implement both and make us all happy.

Quote from: RickJ on Thu 14/12/2006 01:41:02
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.

What do other people think about this? My impression was that a view for something like an explosion might be reused by different objects in different rooms; or would people prefer to have views created within a character/object and not available for global use?

Quote from: buzinaocara on Fri 22/12/2006 16:07:57
Let's say that I am making a character, who speaks while he is cooking, I wold make a sprite for his body, sprites for the animation of his hands that are cooking, sprites for the smoke that come from the food, and sprites for his head... All this sprites get together in one view, and are animated  simultaneously by one character, but I can control separately each part of him. Like make him stop talking while he keep cooking. This is Very useful to make characters with lots of animation without needing lots of sprites and lots of characters and objects to emulate just one single thing.

This is basically what my walkcycle generator does, so its quite possible to do this in AGS already.

Quote from: Joseph DiPerla on Fri 22/12/2006 18:45:38
Many of us are used to drawing the whole character.

But you can stay drawing the whole character if you want, you can use just one "layer" of the view for all the animated parts of the character. It is an alternative for those who want to make things smaller, in terms of space...
I agree that it's harder to make sprites with different parts of the animation disconnected, but in the other hand, once you have the sprites done, you have lots of possibilities when animating your characters with less sprites, I mean, less things to draw...

And...
Well, I know thats not an easy implamentation to AGS, but I would realy love it...

Quote from: Pumaman on Fri 22/12/2006 20:33:37

Quote from: RickJ on Thu 14/12/2006 01:41:02
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.

What do other people think about this? My impression was that a view for something like an explosion might be reused by different objects in different rooms; or would people prefer to have views created within a character/object and not available for global use?

I would leave it for Global Use. It shouldn't really effect anyone making a game if it stays. It might just make more work actually. Besides, you know someone is going to request it in the future. YOu may as well let that stay. Thats my two blue cups.

Ownership does not necessarily restrict accessability.  Perhaps I should have said that views should be properties of Characters, Objects, Cursors, or other entitoies that can be animated.  It seems to me that a lot of the Get/Set Loop/Frame stuff would be greatly simplified.   For those few situatuions where this is absolutely unacceptable could we not also allow "Game" to own a collection of views that would be just as globally accessable as they are now.   

If you were to do this it wouldn't be necessary to have folders to organize views.  They would already be organized.  However if you wanted to have something like a view manager then you would have one folder for each Character, Object, Cursor, or whatever that are auto-generated by ags.  I suppose there could also be user created folders as well.  Perhaps the auto-generated folder could have a different color or icon to differentiate them from the user created ones.   There could also be a Global or Game folder that could also contain views. 

From the character edit pane you would be able to edit the views that belong to that specific character.  You wouldn't be bothered by all the other irrelevant views.  You would still be able to assign whichever view to what ever purpose as is done now.  If you ewanted to use a global view for the character's walk animation then you would just  assign it like we do now.  It's just that most of the time you would only be interested in the ones owned by the character.   

Objects would work much the same way except that it would be desireable if the views were stored in the room file along with the rest of the object stuff.   This is important for group projects. 

For example, suppose Bob is working on a big group project and volunteers to work on room 42.   Bob jumps right in and before long he has a rich interactive environment with cooly animated gadgets.  He has drawn all of the sprites, imported them into sprite manager, created views, loops, etc and assigned them to objects, and wrote the supporting script code.   So Bob emails the Jim, project coordinator (i.e. the guy who maintains the main game file), and says that he is done with room 42 and attaches a zip of his version of the game.   So now Jim will have to unzip the game to a different folder, ropy the crm file to his game directory, re-import all the sprites, re-create and reassign all the views, and possibly modify Bobs source code to use the right sprite/view/loop/frame numbers.  Now suppose Bob gets 10, 15, 20 zip files at once.  Imagine all the duplicate work (and ensuing errors) in a 100 room game.   

Now ask yourself wouldn't it be much better if all Bob had to do was copy the crm file to the game directoy and compile?  The way it is now there is a negative impact on people who are working on group projects.  If something like I suggest were undertaken sprites and views would be better organized, it would much be easier to implement frame fiddling functions as oo properties and methods, and it would make group projects more productive and more likely to succeed.   

Perhaps in the past AGS's internal structure made implementing this kind of thing a hellish task, however, if the sprite and view stuff are going to be re-done from scratch then maybe what I suggest is worth considering.

Merry Christmass

RickJ

P.S.  I'll be on a plane in a few hours to vist my parents.  I'll be back on Feb 3rd, and will perhaps check in before that if I find internet access somewhere.

Quote from: Pumaman on Fri 22/12/2006 20:33:37

Quote from: RickJ on Thu 14/12/2006 01:41:02
I have always thought a view should be owned by the character or object to which it applies.

What do other people think about this?

I have various uses for several characters using the same view. The most obvious one is getting a group of "identical" NPCs and having them share their appearance. When adding a new character with no graphics available yet I recycle those from an existing character. And there's also some weirder uses I won't go into here :)