Metroid-Like Game in the works

[Ryan]

Speaking of which, progress update:

[spoiler]
Update 10
[/spoiler]

Map transitions are pretty much done, at least from the file setup stance, still need doors(fairly easy animation) and a room transition animation (hint that's pretty low priority), and of course more tiles for the tileset/transparency issues, always graphics problems, always, it turns out it's not nearly so straightforward to take a tileset and throw stuff together that looks nice, for me anyway

GUI underwent a massive upgrade, now we have energy tanks and icons for missiles/etc and even ammo supplies, also started working on inventory screen so that soonish we can equip/unequip specific power ups.

Goals for next update:
-Enemies for the big room, probably zoomers and other simple critters, that we can *kill* so that I can test out enemy drops, again shouldn't be too hard
-Power ups, mostly just need to get the graphics loaded up, and I should be able to put etanks/missile upgrades/powerups on the map editor pretty easily, as usual fancy animations like when you get your suit upgrades are unlikely to be attempted any time soon
-Optimization... :( apparently I've either hit the size limit for reasonable tile based 2d platformers in pygame (less likely) or I have some grossly inefficient code in there somewhere (more likely) that's causing the huge room to run at roughly 1/2 normal speed... which is pretty bad, so I either use smaller rooms (not a big deal, 100x100 is way too huge anyway right?) or try to figure out what's bottlenecking the fps (highly likely graphic related, i'm probably drawing too many images per frame that I don't need to be or something)

[personitis]

About nothing comparing to a 100x100 tiled room: The room you've got currently sits at 10,000 area (huurduur simple math). The biggest a room in SM can be is 50 screens total. Taking a room that is 5x10 screens in size, each screen containing 16x16 tiles, that makes any similar room 12,800 in area. Though not every screen is used, the large pink Brinstar room containing Charge Beam in the original is 5 wide and 10 tall. Also, as far as I've ever been able to tell, any lag in the original comes from an overuse of enemies or PLMs (special door caps, items, and other such objects) being active in the room and not a large amount of tiledata being present. Looks like you've got some optimizing to do!

I could be wrong, but I believe this is the farthest I've seen a Super Metroid remake(?) come along. So with all that said, keep up you hard work! :yay:

[Ryan]

Ah yeah I never really mathed out how big the rooms in Super Metroid got, strictly speaking my tiles are 32x32 which will take up a bit more memory, but it's good to know I should aim for rooms about this big then, just need to figure out what's slowing things down then. But I'd seriously hope a modern pc can handle considerably more then the old snes, it's almost certainly optimization stuff that I just don't know about yet.

And thanks :) I'm pretty sure I've gotten past enough major hurdles that I should be able to add a fair amount of gameplay without huge problems too

[Ryan]

Just had to reply one more time since I'm so pumped, turns out the slowdown was caused... by too small background images... all I ended up doing was doubling the size of the background image, the actual image file (they just get tiled to fill the screen anyway...) and suddenly everything's playing smooth again, very strange, I think the copying and tiling was really what messed it up, probably was happening every frame instead of 1 time on load... something I could probably fix, but simply having large background images is not a problem at all, since a lot of the "cool" looking backgrounds like the surface aren't tiled hardly at all

[Vismund Cygnus]

Sounds like something that you may wish to fix anyway, given that you know the problem exists now, as opposed to waiting until the issues start to stack up. :P
Anyway, I was wondering what had happened to this, I'm glad that you haven't dropped it and I look forward to seeing what you can do.

[Ryan]

Yeah I'm actually having a really good time programming this again, I'm sort of ignoring most animation stuff for a while and getting some good progress done at the moment which feels really nice.

And yeah, I made a note to try and figure out the background image loading issue, it's not top top priority but its fairly high up there, my big wish now would be to get to the point of making a playable demo so I'm trying to get gameplay related stuff at least into the game for starters, It'll be interesting tackling performance issues once I can test it out on more hardware then just my own

[Kitsune_Phoenix]

Yeah I was thinking just splitting the songs up might work, I do have the ability to jump to positions in the track with my current mixer, but it's a lot of work for not too much gain, for now I won't be spending much time on it, but its good to have some plans ready for the day I feel like tackling it.

Which would be very messy and inefficient... IT module support is not that hard to code for from what people have told me.

However, I think it will make things easier for you if I managed to obtain an opensource version of Unreal 227's OpenAL sound engine, that way you could look at the code and maybe get it working with PyGame (not sure how difficult that would be with code originally built on C++ though.)

[Ryan]

It's certainly possible to run a C++ module in Python, that part's not too difficult from what I've read, not that I've ever done it before, in fact from what I've gathered Python was designed to do that sort of thing pretty easily, I'm willing to give it a look, but it may be way over my head to implement a C++ sound engine into my game without some serious research/time/effort, as much as nicely looping music is a good idea, if that turns into a 10+ hour task I have oh so many other things to get to first, I'm pretty sure a demo with simple track looping would suffice for a fairly long time

[Ryan]

Big update time (at least as far as I'm concerned)

Made lots of little tweaks and fixes along the way, but big things:

-Doors 99% Finished (I think they're awesome), all that's left is tweaking the timings on the animation/sound effects
-Powerups 95% Finished, you can pick them up, the game adds them to your inventory, you can equip/unequip them at your leisure, sure I haven't implemented every powerup, but I have most of them done
-GUI 90% Finished, all that's missing is the minimap as far as I can tell, maybe a bit of tweaking to the layout positions, but I think it's pretty solid
-Inventory Menu ~50% Finished, it's functional, but missing a fair bit of graphics (the suit wireframe doesn't update for instance), and the inventory pointer is a bit messed up
-Tileset loader ~90% Finished, it's getting very easy to make new maps, only missing a few tricky things like water/lava and lighting effects for those dark rooms

The big "to-do" now is get some more monsters in the game, I've got about 5 basic enemies sprites ready to go, but I haven't totally nailed down the enemy -> tile collisions yet, which is related to the samus -> tile colliisions not being finisehd either, so I need to spruce up on my collision logic and get those hitboxes acting correctly before much longer

Also on the to-do is a save room, and loading, since now that we can gain powerups and unlock doors we should probably start saving progress too

And of course the final 2 inputs I mostly forgot about the probably easy weapon reset button, and the only a little tricky dash button, which means I also have to implement dashing mechanic to max horizontal speeds and jumps, which of couse leads to speed booster and shine sparking, "yay more animations"

Anyway things are going pretty well, I've got lots to work on of course but it feels like I'm making good progress lately, the update video is here if you're interested:
[spoiler]
Update 11
[/spoiler]

One thing I thought I'd ask the community here is if anyone has experience pixel editing in code (not just in photoshop or the like), my issue is that although I can directly swap 1 color to another color for all pixels in an image, some images have a ton of colors that I'd have to manually set up, for instance:
[spoiler]
        pixelArray.replace((11,0,0), (0,56,173))
        pixelArray.replace((74,12,1), (0,121,222))
        pixelArray.replace((130,77,30), (41,154,206))
        pixelArray.replace((213,128,67), (115,219,255))
        pixelArray.replace((165,100,43), (82,195,231))
        pixelArray.replace((87,54,20), (16,138,189))
        pixelArray.replace((136,71,10), (0,178,255))
        pixelArray.replace((1,94,25), (0,48,66))
        pixelArray.replace((2,255,100), (0,154,222))
[/spoiler]
That's the freezing palette swap for a lowly ripper, it would be vastly easier if I had some sort of mask I could apply to any image and have it look mostly blue but still identifiable as the original monster for instance, otherwise I have to manually figure out every color code in every enemy image and figure out its corresponding frozen color code.  I have access to a fairly wide array of array math that I can apply to an image, I just don't know enough about image editing to know how to work them.

[Quietus]

Regarding the Energy Tanks 'alt' colours: It's likely just the same item, but customised.  Most powerups in Super Metroid have a sprite that rapidly flickers between two slightly different colours / states, but it doesn't look like the one you have.  I suspect it's just the creator of those sprites creating some variants.  There are also different colour doors (the tunnel part), as well as purple doors, which don't exist in the normal game.

[Kitsune_Phoenix]

Samus' movement speed seems a lot slower than in SM. She runs/jogs slower, she jumps slower and she falls slower.

[Ryan]

I'm not 100% sure for the energy tanks honestly, its no big deal if I need the alternate version or not, part of the test was to have 2 different objects that add to the same pool of items, and yeah my sprite supply is neither 100% accurate nor complete so there's always room to improve...

Interestingly enough with the doors, I'm only using 1 set of sprites for blue (4 step opening animation), and just flipping/rotating them for position and color swapping for type, so I can color them whatever I want without needing more images


And yes,  at some point I'm going to have to go through and tweak some variables for acceleration/deceleration to make things "feel" closer to super metroid, the variables are all set up, it's just finding the right values. Keep in mind though that we're still only at "walking" speed samus, I don't even have the dash button set up for running speed yet (hopefully next update)

Edit:
I just quickly added in the item cancel button (easy) and dash button, as well as changing the max horizontal speed for dashing and speed boosting.... I realize that I don't know nearly enough of super metroid physics...  I've played the game dozens of times, but I don't know whether dashing changes acceleration on ground, or just top speed, and how those values change with speed booster for instance, or how exactly your running speed converts to jump height (like the huge jump to get the grapple for instance)  I've set things up in my code to be easily changed, but until I figure out some of the physics it's going to be really hard to know what values to set my variables

[Metaquarius]

Samus' running and jumping animations really need work. I can provide you an accurate sprite set with proper anchoring for some animations if you want.

[Ryan]

This is the tileset I've built for myself so far for Samus sprites:
[spoiler]

[/spoiler]

Each sprite is centered in a 64x64 square, and animations should be in order left -> right so in the code I load each animation sequence with a for loop i * 64 sort of thing, then I have an array of for example walking left images, and then as long as we stay in the same state it just switches to the next image in the array every few frames.

This is the file that took me by far the longest and its not finished yet, I've probably spent around 15-20 hours fighting with this beast, but if you have something more complete I'd be happy to have a look.

A lot of the times the incorrect look of the animation in my game is caused by a slower stepping, which I'm totally aware of and did on purpose so I can try and identify problems where the animations are out of order or "jump" for being unaligned correctly, if you're noticing those sorts of problems please let me know, as even identifying small frame misalignments is a tough job for me

[Metaquarius]

Here is the sprite sheet I made for ya : see attachement.

This one is extremely accurate and has all known poses without fancy coloring which means you can use color shifting safely (Varia suit, Gravity suit, etc.) Every single frame is centered in a 64x64 square but unlike your tileset, Samus' gravity center is also the square's center. On top of that, each square has a border and a 2D axis (using green, red and blue colours which can be easily removed) so you cannot have misalignements issues. Use this to enhance your own tileset, just don't forget to me credit.
Now I want to see some faithful animations in your game. :yay:
Keep up dude.