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.
Last updated in 2016?
Lots of great stuff from before that.
A couple of sad little action mockups. 1990 vintage run'n'gun!
This version is good also - has a slightly more "Blade Runner" feel than the original.
Something seems to be wrong with the looping though, or maybe that's just the preview?
"Orbital Graveyard" as an evocative title reminds me of one of my favourite pieces of game music, the third stage theme from Thunder Cross by Konami.
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.
Pages