SUGGESTIONS

[Shane 'ProgZmax' Stevens]

I think what he means by sprite pages is what some game companies do is, you give them a sprite sheet and through code the program grabs portions of it to make an animation. Usually they look like film strips

My reply was addressing that very issue, Eric, which is why I said it's easier to make the animation as a gif rather than store them side by side or vertically (what you call film strips).  I used to do all my work that way and, in fact, my game engine loads in images in this format and sections them to create an animation (using x or y offset and number of frames as a guide).  However, as I got into doing animations and saving them as gifs I realized this was a much more streamlined and convenient way of handling things since I don't have to redo the frame list over again if I do a small edit- which is tedious.  Eventually I'll probably add an animated gif loader to my engine but that's when I stop being lazy .

[MrColossal]

I didn't know you were talking about your own engine, since he's speaking of AGS which can't do what your engine can do.

[Pumaman]

However, I have to agree with Lemmy that being able to store your frames externally and have them compile in at the point you test would be amazing as it would free me up to make small changes to my animations without having to bother the person putting them in. I just update the files I want and wait for the next test.

This is an interesting idea ... the original idea for AGS was to make it as much of an "integrated IDE" type thing as possible, and so that once you import an image it no longer relies on the image file still being available.

However for quickly updating sprites I can see the benefit of having AGS automatically grab the image file from disk when you compile the game, to save you having to re-import it every time you change it. I'll have to look at how easy this would be to implement.

[Kweepa]

If you're going to do that, this is my suggestion:

Have a data repository with a path that is specified in the editor and a checkbox that says whether or not to use it. Then in the editor the sprites and backgrounds/walkable areas/regions etc have a relative path to the graphics, plus the clip rect, transparent colour/pick point, etc.
Sound and music could go in the repository too.
Finally a bake button that imports the new graphics (or a checkbox to autobake when you compile, otherwise the compile just uses the graphics on disk without importing them).

This way you can use the uncompiled game on multiple machines with different directory structures, and so on.

It might be interesting to have an option for the compiled game to use the repository (with the repository path relative to the executable or specified in the ini file) so that artists working on graphics could see them without having to know how to use AGS. One would have to be careful not to release this version to the general public though.

[lemmy101]

This is an interesting idea ... the original idea for AGS was to make it as much of an "integrated IDE" type thing as possible, and so that once you import an image it no longer relies on the image file still being available.

However for quickly updating sprites I can see the benefit of having AGS automatically grab the image file from disk when you compile the game, to save you having to re-import it every time you change it. I'll have to look at how easy this would be to implement.

This would be great to have. The best way I can see it working would be to seperate "Test Game" from "Distribute Game". Distribute game would go through all the motions of importing all images etc and storing them in the exe as you do now, where in development using Test Game would run it with dynamically loaded gfx. Best of both worlds.

Tho this all depends on how it's implemented in code and may not be as straightforward as that.

[Traveler]

This is an interesting idea ... the original idea for AGS was to make it as much of an "integrated IDE" type thing as possible, and so that once you import an image it no longer relies on the image file still being available.

However for quickly updating sprites I can see the benefit of having AGS automatically grab the image file from disk when you compile the game, to save you having to re-import it every time you change it. I'll have to look at how easy this would be to implement.

This would also be very useful for team development. If sprites don't have to be embedded in the binary game source files, one person can work on coding while other(s) can work on the graphics. When some graphics is changed, it'd be very easy to update. This would ease communication between team members.

To take the idea a step further, I wouldn't mind if room graphics (and areas, regions, etc.) would be stored on the disk as separate files, too. That way, room graphics could be easily updated without the need to reimport the graphics.

When specifying room graphics, a separate file could be used to specify the background, each hotspot, each walkable area, each region, etc. This is what happens now, anyway, just the graphics is stored in the binary source file, not as a separate graphics file. This would mean a lot of files, but it would also be very flexible. (And the current implementation could be kept; in the room editor, a checkbox could be used to switch between the current way and storing data in separate images for each room. So very simple rooms could use the current implementation, complex rooms could store everything as individual files.) I hope it's not too confusing as I explained it.

[RickJ]

I appologize for not getting into this discussion sooner but I have been away from home and internet challenged since Christmas. 

1.  Anyway I like the idea of being able to reimport sprites from their original locations.  However, using a single directory as the repository is a bit problematic and inconvenient, IMHO.  If the repository were a collection of sub-directories  instead of a single directory then I think it would work much better for a greater number of people.

2.  I also think it would also be useful to display the first N characters of the original filename next to the sprite number and/or the full name as a tooltip or property.     

3.  Perhaps the sprite number could be assigned to an enumerated value constructed from the filename and repository folder.

4.  I also like the idea of doing the same thing for room graphics.   In addition to the backgrounds I find that many sprites are drawn for specific rooms.  In this case, wouldn't it maKe sense to keep these spites in the same folder as the background for which they are drawn?

Hope something comes of this, it's something I have thinking about for a long time.

[CaptainBinky]

1.  Anyway I like the idea of being able to reimport sprites from their original locations.  However, using a single directory as the repository is a bit problematic and inconvenient, IMHO.

Yeah - what I had in mind was that your sprites (and rooms - any asset in fact - sound, art, anything at all) would effectively be pointers to disk locations so that you can organise your assets however you like, and then they'd all get sucked in at compile time. Obviously this means that there's nothing to prevent you being extremely disorganised, and some sort of error checking will be required should you delete a bunch of assets required by the game. However, this all just comes down to personal organisation.

Edit by strazer:

Use the quote tags:

Code: ags

[quote]
This will be quoted
[/quote]

[Pumaman]

Yes, I think some sort of system that automatically "sucked in" all the files at compile time would be much more feasible to implement than the engine being able to load the image files from disk -- since the game file formats would remain the same, and the engine wouldn't need to contain code for reading JPG, PNG, GIF and so forth which would really bloat its size.