• Register

Super Hematoma is a beat-em-up inspired retro multiplayer fighting game which will have you pitted against your friends (or random jerks from the "internet") in brutal street fights. Whether you decide to go it solo or with a group of friends, your Bruiser will be able to bash, bludgeon, and break your opponents using a variety of weapons or even your bare fists. With a variety of arenas and game play modes to choose from, you'll be knocking knuckles with the best of them for hours on end. This project, which is in early development, hopes to bring classic retro pixels and music into a modern multiplayer brawler setting. We're a small team of two independent developers that are working hard to bring something fresh to the table.

Post news Report RSS Packages of Files and Pieces of String

Hey paisanos, Matt's back out of the depths of his nerd cave to give a long overdue update on some game dev stuffs!

Posted by on

Hey paisanos, Matt's back out of the depths of his nerd cave to give a long overdue update on some game dev stuffs!


So, jumping right in:

A rather modest goal that I had early on was building a default package file format for Super Hematoma to externally contain sprites, level information, game data and the like. I’d build a simple toolset to pre-construct these package files, as well as deserialize resource data back out of them in real time for the game to use. Implementing this “rather modest” goal stretched out across what seemed like an eternity of development time, which can be pinned on a number of reasons (the common “real life happened” cover, caffeine deficiency, the ever-present temptation of having hundreds of little plastic cartridges stuffed full of nostalgia surrounding me at my workstation at all times, the like). Mostly though, it was just bad planning and time underestimation.

Honestly, if making a game (maybe any software? maybe anything?) is something you really want to do, make sure you’ve got your priorities and goals straight from the start; if you’re a tinkerer / crazy nerd, building everything from scratch can be a great temptation, but expect things to proceed slowly. Only do it if you really like doing it (which I do) and have time (oh, uh, about that…). It’s always fun when the todo list grows faster than the completed list. Even when you’re as cool as I am, you can’t defeat common sense.

Anyway, this undertaking coincided with a rather large change in the animation engine to build character sprites out of separate parts, as has been previously explained, and as Steve has so graciously filled pages and pages of our blog with people pieces for. I’d also mentioned the real-time outlining of the characters previously, which has been integrated into the new engine. Data format for descriptions of stages, items, game parameters, etc. will be described in XML files which are currently built into the package files as well.

So, where are we?

Well…

What’s done?

  • Package file toolset that builds package files (“.dat” files), and handles in game asset building
  • All resource management and sprite loading code
  • Separate serialization and deserialization code for all the game assets
  • New sprite animation graphics engine entirely redone with character outlining and scaling working properly
  • All XML/data parsing code
  • XML files themselves
  • New collision geometry added
  • Lots of other small fixes and reorganization
  • Background sprites are now built out of generic static animations and stored with the other object types instead of pointlessly particular data types.

What’s coming up next?

  • Palette swaps are a breathe away and are being implemented in a straightforward DirectX pixel shader
  • Lots more moves! Finally something actually fun!
  • Add items and work out the gameplay mechanics for how they’ll work
  • Important game backbone stuff, like how fighting mechanics, life bars, character knockout and wakeup timers, all that fun stuff
  • New controls for the camera/render system including manual and automatic zooming and better culling for out-of-view sprites

Why did all this take so long?

  • See notes above about “real life” (yeah right)
  • A lot of stuff had to actually be “redone”. I’d basically designed the whole game one way to get things up and running faster, but transitioning it into the current component-sprite-with-outline system required a redesign of a surprisingly large amount of the game (again, see notes above about “bad planning”).
  • There were a lot of breaking changes to the animation engine interface, and I also broke all the transitions between different animation states since those are now handled differently.
  • Had to get a handle on some DirectX quirks that one needs to keep in mind when working with low-res 2D sprite art (eat me, power-of-two size requirements)
  • A lot of offset reading and character piece placement also needed a lot of tweaking and reworking. Essentially, this:
    Broken_character

    needed to become this:

    Working_character

  • Don’t bother making your own 2D graphics engine. It bogs down your timeline :)

Back to Gradius 2! Stay tuned!

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: