EDIT: the beginning of this comment originally referred to the gifs posted by medicinestorm but it turns out that they were truncated somehow when my browser first rendered the page, so what I wrote doesn't actually make sense, and I've deleted that bit.
EDIT: now the rest of the comment has become out of date too, so I've deleted that as well.
Thanks for the extra info food_please! And big kudos for offering to help Calyad out with Godot too (y)
If the developer were programming the engine themselves, they can easily begin/stop movement during a firing frame with this design as well. But I guess some existing engines might make it more difficult, that depends on the engine.
For example, you would change directly from displaying "stand + gun flash at aim 45 degree up" to "run 1 (with no gun flash) at aim 45 degree up". Because there's only 2 frames for "firing", all you need to do is keep the aim angle the same between the two "movement" animations and switch to the other "firing" frame. If the firing animations had more than 2 frames then it would be basically the same but you'd need to start the second "movement" animation on the "firing" frame following the one that you were up to in the previous animation.
In terms of drawing things, there is actually more freedom when laying out combined frames like this! For example, here I got carried away with gun flash highlights on the suit - and if you look closely, the gun flash reflection on the legs depend on both the position of the flash and the position of the legs. So if the animations were split into "upperbody" and "legs", either we'd have to lose the reflections on the legs, or the flash (and reflections) would have to be split out into separate overlay frames, with a layout at least as complicated as what we have here. There also tend to be other places where you can improve tiny details of the final result if you have both halves of the character combined.
I made sure that the flash and reflections use different colours to the main character so that it would be relatively easy for someone to separate out the flash from the character in gimp, if they wanted to do that.
thing is though, we kinda "humanize" these algorithms by calling them ai. they are not artificially "intelligent" so much as they are algorithms trained using real people's creative works. you can study rembrandt, whereas a dataset that "learns" what elements of art are reminscent of rembrandt doesn't "know" anything.
There are some pretty strong arguments that this is fundamentally no different to what actual humans are doing when they learn from the things that they see. AFAIK there are humans who have "exact" memories and can exactly recreate scenes that they have seen - Mozart could famously do the same thing with music, even after only hearing it played once. So the "AI" is not much different in this than a rare kind of human.
It's not really worth bothering to argue whether these things are "intelligent" or not - our idea of what "intelligence" really means is changing every day right now specifically because these things exist. We have to try and learn to live with the existence of this technology without creating a dystopia, and that's the only thing that matters.
Anyway, I came here to say that MedicineStorm started a more recent thread on the topic which had some really long and detailed replies in it, so there should probably be a link to it here! I'll add a link in this post if I can find that thread again.
Thanks Calyad, it's quite useful to know that about Godot. For sprite sheets like these I can use that information to make them a bit easier to use in Godot.
The upperbody/legs split would be another way to do this kind of sprite, but I always thought that it would be harder to use that, because the game developer would have to programmatically ensure that they line up correctly in every combination. Not so difficult for static poses, but probably a PitA for run cycles where the upper body usually bounces up and down during the cycle. Such a split might be what a developer on actual 16-bit hardware would wind up using, because on the hardware of that era, saving every possible byte of memory is much more important than the ease of making a game! But sprite sheets supplied in modern web graphics file formats would never be directly usable on such hardware, anyway; they would have to be put through a whole suite of customised tools to get them into the exact correct format for the hardware and the engine. For developing in modern game engines, I figure it would usually be easiest (where practical) to combine things that are meant to be displayed together into one sprite image.
In "super dead space merc" the character was actually built from separate upperbody and legs frames which were then combined to make the final sheet. In that case I submitted the original split source as well in case anyone found that useful. To some extent the upperbody and legs were done separately for the shooting frames in warpgal, but this time the way I did it wasn't as cleanly segregated, so I don't already have a useful source to submit with that split intact. Maybe I'll make one at some point...
I use MSPaint a lot, as it happens ;-) I find it far better than gimp for pixel-by-pixel detail stuff.
@Calyad By the "vertical" comment I'm guessing you must be looking at the shooting sheet. All of the animations on each sheet are laid out horizontally, but on the shooting sheet this is part of a bigger layout. On that sheet there is one column for each "pose" that the character can fire from (where the running animation takes 10 of those columns, arranged horizontally just like they are in the running-without-shooting animation on the other sheet). The rows are dedicated to the different aiming angles, with rows alternating between the "aim" and "fire" frames for each angle and each pose.
All of the poses that the player can fire from are static poses except for firing while running, where each frame of the running animation has an aiming pose and a firing pose for each available aiming angle, because the player could start shooting from any point in the run cycle. The idea is that when the player is running and begins firing, you would look at the frame of the run cycle which is currently being shown, and replace it with the corresponding frame from one of the two rows devoted to the player's current firing angle; this would be either the running-and-aiming frame or the running-and-firing frame (depending on whether or not a projectile is being created on the current game frame). For firing while standing (for example) it's a lot simpler because there's ony one frame, so you need to pick either the "aim" or "fire" frame for the appropriate aiming angle in the "stand" column.
It's a lot more compact to lay them out this way than to lay out all the possible aim-and-fire combinations as 2-frame horizontal animations. If "aim-and-fire" was treated as a separate animation by itself then one would be needed for each combination of starting run frame and shooting angle, and you'd have to make sure to pick the right one for the current position in the run cycle, and then make sure to switch back to the middle of the run cycle at the right place afterwards as well. That's bound to be a pain in the ass.
I don't know how Godot works, but I think that what you probably want to do is to consider firing while running as being 3 different 10-frame animations that are all playing at the same time: the normal running animation from the non-shooting sheet, the "aiming at current shooting angle while running" animation (which is located on one of the rows of the shooting sheet, starting from the "run 1" column), and the "firing at current shooting angle while running" animation (which is located immediately beneath it). You have all 3 animations playing, and just switch which one is actually being shown on the character in every game frame depending on whether or not the player is holding the "fire" button and and whether or not a new projectile is being created.
The demo GIFs show how the firing sheet is meant to be used - if you want to look at those frame-by-frame, you can right click on them and "save image as", then open the file in gimp, and you will see each 12.5fps frame of the demo animation in a separate layer, with the first frame at the bottom of the layer stack and the last frame at the top. I'll give a warning as well, in the demo GIFs you will see a few frames that appear to be in an odd place - you can ignore those if you want. Those are just places where I decided to make extra improvised transitions by sticking one or two of the aiming frames in between two other animations.
Um, what do you mean? They should all be 48x48, and laid out in a grid with no gaps between frames (except where frames don't exist, such as firing straight downwards while running).
Epic! Leans towards "sad" and "peaceful", but has enough "spooky" notes for a graveyard.
Here's the beginnings of a Sara edition...
EDIT: the beginning of this comment originally referred to the gifs posted by medicinestorm but it turns out that they were truncated somehow when my browser first rendered the page, so what I wrote doesn't actually make sense, and I've deleted that bit.
EDIT: now the rest of the comment has become out of date too, so I've deleted that as well.
Thanks for the extra info food_please! And big kudos for offering to help Calyad out with Godot too (y)
If the developer were programming the engine themselves, they can easily begin/stop movement during a firing frame with this design as well. But I guess some existing engines might make it more difficult, that depends on the engine.
For example, you would change directly from displaying "stand + gun flash at aim 45 degree up" to "run 1 (with no gun flash) at aim 45 degree up". Because there's only 2 frames for "firing", all you need to do is keep the aim angle the same between the two "movement" animations and switch to the other "firing" frame. If the firing animations had more than 2 frames then it would be basically the same but you'd need to start the second "movement" animation on the "firing" frame following the one that you were up to in the previous animation.
In terms of drawing things, there is actually more freedom when laying out combined frames like this! For example, here I got carried away with gun flash highlights on the suit - and if you look closely, the gun flash reflection on the legs depend on both the position of the flash and the position of the legs. So if the animations were split into "upperbody" and "legs", either we'd have to lose the reflections on the legs, or the flash (and reflections) would have to be split out into separate overlay frames, with a layout at least as complicated as what we have here. There also tend to be other places where you can improve tiny details of the final result if you have both halves of the character combined.
I made sure that the flash and reflections use different colours to the main character so that it would be relatively easy for someone to separate out the flash from the character in gimp, if they wanted to do that.
@Calyad try the new ones I just uploaded.
thing is though, we kinda "humanize" these algorithms by calling them ai. they are not artificially "intelligent" so much as they are algorithms trained using real people's creative works. you can study rembrandt, whereas a dataset that "learns" what elements of art are reminscent of rembrandt doesn't "know" anything.
There are some pretty strong arguments that this is fundamentally no different to what actual humans are doing when they learn from the things that they see. AFAIK there are humans who have "exact" memories and can exactly recreate scenes that they have seen - Mozart could famously do the same thing with music, even after only hearing it played once. So the "AI" is not much different in this than a rare kind of human.
It's not really worth bothering to argue whether these things are "intelligent" or not - our idea of what "intelligence" really means is changing every day right now specifically because these things exist. We have to try and learn to live with the existence of this technology without creating a dystopia, and that's the only thing that matters.
Anyway, I came here to say that MedicineStorm started a more recent thread on the topic which had some really long and detailed replies in it, so there should probably be a link to it here! I'll add a link in this post if I can find that thread again.
Thanks Calyad, it's quite useful to know that about Godot. For sprite sheets like these I can use that information to make them a bit easier to use in Godot.
The upperbody/legs split would be another way to do this kind of sprite, but I always thought that it would be harder to use that, because the game developer would have to programmatically ensure that they line up correctly in every combination. Not so difficult for static poses, but probably a PitA for run cycles where the upper body usually bounces up and down during the cycle. Such a split might be what a developer on actual 16-bit hardware would wind up using, because on the hardware of that era, saving every possible byte of memory is much more important than the ease of making a game! But sprite sheets supplied in modern web graphics file formats would never be directly usable on such hardware, anyway; they would have to be put through a whole suite of customised tools to get them into the exact correct format for the hardware and the engine. For developing in modern game engines, I figure it would usually be easiest (where practical) to combine things that are meant to be displayed together into one sprite image.
In "super dead space merc" the character was actually built from separate upperbody and legs frames which were then combined to make the final sheet. In that case I submitted the original split source as well in case anyone found that useful. To some extent the upperbody and legs were done separately for the shooting frames in warpgal, but this time the way I did it wasn't as cleanly segregated, so I don't already have a useful source to submit with that split intact. Maybe I'll make one at some point...
I use MSPaint a lot, as it happens ;-) I find it far better than gimp for pixel-by-pixel detail stuff.
@Calyad By the "vertical" comment I'm guessing you must be looking at the shooting sheet. All of the animations on each sheet are laid out horizontally, but on the shooting sheet this is part of a bigger layout. On that sheet there is one column for each "pose" that the character can fire from (where the running animation takes 10 of those columns, arranged horizontally just like they are in the running-without-shooting animation on the other sheet). The rows are dedicated to the different aiming angles, with rows alternating between the "aim" and "fire" frames for each angle and each pose.
All of the poses that the player can fire from are static poses except for firing while running, where each frame of the running animation has an aiming pose and a firing pose for each available aiming angle, because the player could start shooting from any point in the run cycle. The idea is that when the player is running and begins firing, you would look at the frame of the run cycle which is currently being shown, and replace it with the corresponding frame from one of the two rows devoted to the player's current firing angle; this would be either the running-and-aiming frame or the running-and-firing frame (depending on whether or not a projectile is being created on the current game frame). For firing while standing (for example) it's a lot simpler because there's ony one frame, so you need to pick either the "aim" or "fire" frame for the appropriate aiming angle in the "stand" column.
It's a lot more compact to lay them out this way than to lay out all the possible aim-and-fire combinations as 2-frame horizontal animations. If "aim-and-fire" was treated as a separate animation by itself then one would be needed for each combination of starting run frame and shooting angle, and you'd have to make sure to pick the right one for the current position in the run cycle, and then make sure to switch back to the middle of the run cycle at the right place afterwards as well. That's bound to be a pain in the ass.
I don't know how Godot works, but I think that what you probably want to do is to consider firing while running as being 3 different 10-frame animations that are all playing at the same time: the normal running animation from the non-shooting sheet, the "aiming at current shooting angle while running" animation (which is located on one of the rows of the shooting sheet, starting from the "run 1" column), and the "firing at current shooting angle while running" animation (which is located immediately beneath it). You have all 3 animations playing, and just switch which one is actually being shown on the character in every game frame depending on whether or not the player is holding the "fire" button and and whether or not a new projectile is being created.
The demo GIFs show how the firing sheet is meant to be used - if you want to look at those frame-by-frame, you can right click on them and "save image as", then open the file in gimp, and you will see each 12.5fps frame of the demo animation in a separate layer, with the first frame at the bottom of the layer stack and the last frame at the top. I'll give a warning as well, in the demo GIFs you will see a few frames that appear to be in an odd place - you can ignore those if you want. Those are just places where I decided to make extra improvised transitions by sticking one or two of the aiming frames in between two other animations.
Um, what do you mean? They should all be 48x48, and laid out in a grid with no gaps between frames (except where frames don't exist, such as firing straight downwards while running).
Did you mean every frame in a separate file?
Warpgal can shoot 360 ;-)
Pages