Platform Shmup Hero: Warpgal
Author:
Monday, March 13, 2023 - 16:15
Art Type:
Tags:
License(s):
Collections:
Favorites:
14
Extension and glow-up of ansimuz's fantastic shooty space explorer character.
Lone agent Nara Sumas is on a mission from the Space Government to defeat the Mutron menace!
Some stuff isn't done yet: shooting backwards while running. There's a very early start (which probably won't be completed) on upscaling 4x by hand. Nara can't transform into a bowling ball, but that ability is actually quite rare among bipeds.
Copyright/Attribution Notice:
Original character by ansimuz (CC0): https://opengameart.org/content/warped-caves-pixel-art-pack
File(s):
warpgal-anim-sheet-alpha.png 15.3 Kb [484 download(s)]
warpgal-shooting-sheet-alpha.png 74.3 Kb [341 download(s)]
shooties-alpha.png 1 Kb [358 download(s)]
shooties-big.png 6 Kb [321 download(s)]
warpgal-stand-aim-big.png 2.6 Kb [334 download(s)]
warpgal-run-3-aim-big.png 2.6 Kb [332 download(s)]
Comments
I really like the work you did!
But *man* those sprite sheets are....difficult to use.
Is there any way you could make these more like a standard sprite sheet, with all the frames the same size?
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?
I'm guessing they mean a spritesheet with no blank padding frames nor annotation frames.
I gotta be honest, though. I find the annotations incredibly helpful, and rearranging my own sprite sheets is game dev 101.
@Calyad: let me know if I'm wrong. There are some pretty great free tools for easily getting spritesheets the way your game engine likes. What platform are you using?
It's the whole-sheet frame that is difficult to work with.
And it also seems as though the thing is going vertically, which is a bit confusing for me!
Blank and annotation frames are quite nice, I agree, but this appears to have not-whole-frame bits.
I'm using Godot 4.0.
Very cool! Nice work as usual.
@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.
@Calyad: I think I'm going to need a bit more explanation regarding "not-whole-frame bits". All the frames are complete for me.
I dumped two of the spritesheets into piskel and did no editing other than tell it to ignore annotation frames and this is the result:
Obviously there are some choppy parts because that is where the animation is transitioning between states that the game engine would ordinarily be handling based on player input. I'm not seeing any incomplete or not whole frames. This took me less than a minute to do, so I'm pretty confident it can be adapted to Godot's needs easily.
EDIT: oops! Emcee replied JUST before I did. I think his explanation is probably more useful.
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.
Well turns out I am *far* more nooby than I realized when it came to sprite sheets.. :D
Up to this point, my whole thought process was that this guy would have an "upperbody" sprite and a "legs" sprite, and they would function independently for aiming / firing and moving.
(Like, if you were moving, the legs are doing one thing, and wherever you're firing, the upper body would do something.)
I must say this is a *big* step up from the original sprite, with all the shooty angles and that little firing flash on the body!
I hope I didn't come across as impolite or uncomplimentary; I fully acknolwedge my lack of proficiency with spritesheets. (I bought Aseprite and...it's so difficult for me to use, I usually just use Piskel instead. I feel like this is someone who buys photoshop but then just uses MSPaint because they know how to use it.) :D You did good work; I didn't mean to imply that my lack of understanding / skill was a shortcoming for your work.
About the sheet and the partial frames....when you drop a spritesheet into Godot, you don't say "Here's how big the frames should be in pixels." Instead you just say "How many columns and how many rows." It always divides the sheet evenly. So like this sheet has a blue bar at the bottom:
https://opengameart.org/sites/default/files/warpgal-anim-sheet-alpha.png
edit : I removed my text-based explanation and just put what I see below! :D
It took a minute but it looks like this when I just drop it in and ignore the all-blue frames:
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.
I just want to clarify Re: Godot integration. I'm fairly confident in saying that Godot can make ANYTHING work here. Frames can be different sizes, different locations, etc. etc. In some cases (especially with shader shenanigans) they can even be on separate source images. You don't need to lay things out on a static grid though that DOES make everyone's life easier in defining which frames on an atlas go into an animation.
With regards to the second use case (separate upper/lower body) this becomes especially useful since it is simple to wire up an animation configuration for each body part. You can then run them independently, which would mean you could begin/stop movement during a firing frame, for example.
I thought it worth clarifying because what you draw is amazing and I would hope that freedom of configuration would make drawing things easier.
@Calyad If you wanted a hand setting up an animation feel free to send a private message over OGA or the OGA Discord and I could try to help out.
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.
Here's the beginnings of a Sara edition...
Yes, these work great! Thank you!!!
And MAN OH MAN! A Sara edition! Bringin' the blonde awesomeness. Well...
I must say your talent will be showcased, because *both* of these lovely sprites will be showing up in my very first game, which is now in beta. :D
oh heck yes to the sara edition! when she is done i will definately make a small game with her, using your space merc redux and super dead gunner redux assets. i've been wanting to use em anyways.
Whoa! I missed this! Sara version, LET'S GOOOOOO!!!!!!