#i'm too lazy to crop like i did on twitter so here's the full image | Explore Tumblr Posts and Blogs

misscaptainbear · 1 year

Text

A while back I wrote a blog on how I'd make a soulslike using retro hardware, I'm gonna repost it here :D

Yeah, so the twitter post where I first explained my idea was my most liked/shared post by like a factor of ten. Since there was so much interest, I figured I might as well make a mockup in Unity. Look what you made me do.

Here’s a link to the build, and the controls are detailed on that page too. For the full effect, I’d also recommend using JoyToKey or a similar program to convert controller inputs to key presses, because I was too lazy to implement key rebinding for a mockup. See the itch.io page for suggested bindings.

Also, if you (yes, you!) want to continue this work, the zip file for the build also contains inspiration art, models, game data, and source code. It’s low polish code and almost nothing is systemic, but maybe it’s a springboard for someone who wants to push this project farther. I’d love to see it. The work that I have the rights to (i.e. everything except the inspirational art) is hereby released in the public domain.

Findings

Animation

The first and most noteworthy thing I’ve discovered while implementing is that there were more animations than I anticipated. Like, I figured there’d be a lot, and there were more than that. As of right now, there are 532 player sprites, each at 100x100 pixels, giving us roughly 6.4 mb of sprite data. (assuming indexed image format and smartly cropping fully alpha 8x8 blocks)

Bruh

One of the things we could to further shrink these is to run-length compress them, and also reuse tiles. I considered writing a python script to go over all 8x8 tiles within all sprites, and saving them in a massive lookup table. Then, it would go through all sprites again, replacing the tiles in the sprite with any similar tiles. This would mean, say, the thigh tile from one animation might be the cloak in a different frame if the pixel colors and shapes were sufficiently similar. However, I decided not to because it doesn’t actually have any savings on modern hardware, only on tile based renderers.

I could have also hand deleted specific entire frames of animations and reused similar enough ones - just by eye - but I also wanted to include all of the animations in the data that I distributed, just for the sake of it all being there for anyone who might need it, for whatever reason. I think these techniques might get the total data down to 50-60%, but that still means a ton of data just for the main characters sprites.

I could also cut the animations in half by simply making the character designs so that the left-facing animations can be reused for the right-facing animations, but I felt that put a lot of constraints on enemy design and combat readability, so I didn’t pursue that either.

Turns out tons of animation variants work better on skinned 3D models (which is why I’m pitching my next souls game on the Nintendo 64. Hit me up Bandai Namco!) I chose to do one player model with no costume changes and just a boring sword. Any variants like clothing, weapons, or equipping a shield would have completely blown the animation data budget.

Framerate

You’ll also notice the game runs by default at a low framerate, 15 frames per second (The quality can be changed with the - and + keys during runtime if it causes discomfort). I did this for two reasons. One, it made the animations, which run at a consistent 10 frames per second, feel much more in line with the sprite movement and the camera rotation. Plus, it might accurately simulate the game running on actual hardware; making the game run a quarter at SNES framerate might be required for the “high-fidelity graphics” on show here. (Who knows if the hardware would actually allow that without awful artifacts though, ha). But throttling framerate is a tried and true tactic for better visuals.

Environment

Another thing that surprised me is the amount of reuse on environment assets I was able to get. I was ready to put together a bunch of textures for the walls and floors, but I finished up what I wanted to achieve and found I’d only used 20 64x64 textures. I think the real game would benefit by focusing on unique tilesets to give each zone or level a special feel, and I think that’d be within the budget of a real game.

Environment took about 20 textures total

I also quickly abandoned the differing-heights-of-walls idea I talked about in the first blogpost. The requirements of the way walls are rendered described in the post made certain arrangements of walls impossible, and those were kind of the only level designs I wanted to use. That’s confusing, here’s some drawings to explain what I mean. Basically, having shorter walls in front making a visually tiered level with hedges that obscure the walls behind them just isn’t possible using that technique.

The rendering technique causes gaps where there would be walls behind walls.

While we’re on the topic of environment, I guess I skipped over the way we’d have to z-sort sprites to allow walls to layer correctly over them, and for sprites to draw back to front. That’d be a performance issue too probably.

Palette and Rendering

One of the big wins I had was the palette I set up, I felt it was super moody and conveyed the tone I was going for. It felt muddy and sad and tired. It had pops of blues and greens, but even then they muted and melancholy. To achieve this look, there were three mechanisms here. First, all the sprites and environment textures were palletized to those colors. Then, in-game, I used a fog effect to fade the world to black. Finally, a post processing shader took any pixels outside the gamut and palletized the final game render, so every pixel displayed is within that palette.

The palletization is most noticeable in gradients, where it slightly changes the tone of colors. In a cool retro way, I think.

To create the sprites, I was kind of forced to do it by rendering 3d models (blender files included in the data!). This was due to time and money. As mentioned previously, I would have loved to dress up in costumes and downscale, pixelate, and rotoscope real pictures, but that costs stuff. Also, I’m sure hand-pixelled sprites would absolutely look more appealing, but like I said above, there were just so many animation sprites. The upside to hand authoring is you can have more control of implied movement during animation, and therefore probably fewer frames. All said, I don’t dislike the rendered results, it has a bit of a Diablo 2 look to it, but I wish I had been able to experiment with different techniques, mostly for fun.

I remember loving to see these render breakdowns in gaming magazines and websites back in the day

I think if I had lower-resolution-better-looking sprites, fewer animations using the techniques described above, and designing levels so as to not have to z-sort sprites, it just might be able to run on SNES. Just maybe. A commenter mentioned it might actually run on GBA, and I could see it being possible. Shoutout to the most impressive 3D gba game ever.

One final design note I liked: The ducking mechanic was inspired by Super Mario World. I felt that was a nice homage, and there wasn’t enough buttons for more soulslike interactions like parrying, so it felt like it was a good choice with some mechanical depth with the limited inputs I had available. And, this game being simpler is alright by me - we are theoretically in the realm of before King’s Field.

Summary

So there it is. I said I didn’t have time to implement it, and I did anyway. This is all your fault.

But for real, I really enjoyed tinkering with this, and I’d love to see anything that gets made out of this idea. Hoped you enjoyed reading this!

#soulslike #soulsborn #dark souls #retro games #retro inspired #snes #gamedev #indie dev #game design

3 notes · View notes