next »

[Allegro]

Ahoy there!

My buddy and I have been working for a while now on making a game to call our own. Actually, we were thinking of calling it Super Hematoma.

It will be a beat-em-up inspired multiplayer retro brawler, where people can pick up a controller and start busting up their buddies using weapons, bare fists, or even their downed opponents and comrades. We're hoping for a few different scoring systems including capture the flag, last man standing, and a timed/point system.

Since the goal is to have lots of people playing simultaneously, one of the things we're targeting with the game is to get a character (which we've dubbed our characters, "bruisers") generator in there so that people can have a somewhat personalized bruiser on screen that they will use over and over to beat each other up with. Hopefully this makes it a little easier for people to be able to tell which bruiser is theirs when things start getting chaotic

It also means that since I'm the sights and sounds of the game, I've had lots of fun animating faceless, bald bruisers:

I've currently got one level designed/painted, two chiptunes done in famitracker, some sound effects done using lsdj, a couple of effects animated, almost all of the initial chracter animation that we'll need to really start ironing out the game mechanics.

My partner, Matt's been making our game engine from scratch using C++. We had a prototype done a few months ago, and he's been revising it a lot since then as well as adding new features to how we handle our sprites. We're hoping that we'll have a newer demo ready to take with us and maybe ambush some play testers with at PAX.

Anyways, we've been working on the game for a while, but it's still in progress. I'm not sure how much information is too much to start a thread with so I guess I'll leave it at this for now.

We also made a short promo video about the game's development a couple of months ago. We got pretty ahead of ourselves and were trying to apply for the Indie Megabooth despite still being way too early in our dev to have truly justified it. I'll place that here too for the sake of being thorough

[Impmaster]

I like the bald faceless men. 

Also, the progression of the background in the last picture is astounding.

[FamousAspect]

Your gifs look great. This definitely hits my nostalgia button. I can't wait to see more.

[Allegro]

I like the bald faceless men. 

Also, the progression of the background in the last picture is astounding.

Thanks! Is it just me? Or does that .gif not loop for some reason? It loops at it's source...

It's the first pixel painting I'd tried doing, so it took me a while to feel like it was going where it needed to go. Hopefully it's a little easier on the next backgrounds  :D

It was actually a fun process figuring out how to get the liquid all animating the way I want too. 

Your gifs look great. This definitely hits my nostalgia button. I can't wait to see more.

Just the types of comments I like to get first thing in the morning
Thanks!

[Allegro]

So I'm not sure exactly whether I'll be able to make an update next Friday (my guess is no) since I'm going to be at PAX, but that said: I hope to make regular updates here each Friday.

I got a little more animation done this week, which I'm going to hold off on showing for now since we're close to having a new build of the game and that will be able to show it off better than the .gifs I have.

I've started to flesh out the next level a bit. It's going to be a rainy night-time city level from the west coast of Canada.
 
A good portion of the levels that we conceptualized are heavily inspired by our strong Canadian heritage. Level 1? The Alberta Oil Sands… a grimy out-door level with a flammable muck that could spell doom if you’re caught in it when someone sets it ablaze. Nothing says Canada like out-of-control eco-hazard!
 
The second level is a little bit more homey for Matt and I, a dirty street corner in a rainy city, circa 2011! You can tell it’s a city that loves it’s hockey by the flaming police car and occasional rioting crowd to pass through.

This level should only require one new animation cycle: climbing the ladders. It’s going to be effects heavy itself though as I’m going to want to have some rain, flaming cars, and a crowd that randomly spawns and tramples through the street level. Some spinning fans in the air conditioning units, city lights… this level will definitely keep me busy for a bit.

Next step will be to do the music for the level before I start the painting process, but I've still got some character animation left that I need to tackle before that comes.

[Allegro]

We missed doing any sort of an update last week as we were both at the Penny Arcade Expo in Seattle. This was our first time at PAX and it was a way for us to get a little bit of a handle on what exactly these conventions are like. We plan on having a booth of our own some day and figured that it would be worth it to check the scene out both for the analytical point of view as well as for pure enjoyment.
 
Unfortunately there’s not a whole lot of progress to speak of for this past week. First thing I came back, my priority was to get our infrastructure working. We’ve been using a wiki system to track all our development for the past year and a half, and at some point I guess we fell behind with software updates. The wiki very recently stopped working giving us errors and failing to generate thumbnails. That’s since been taken care of and now I’ve got only a small handful of the “basic” animation cycles left to go at the moment.  Our girl needs to do attacks while in a grapple position, and both the male and female need to have a wobble/off balance cycle when standing on the edge of a platform. The biggest challenge is still ahead of me though. I’ve got to animate our oil level (and characters) on fire. Hopefully soon Matt will be able to get enough spare time away from his 9-5 to be able to pull a local multiplayer demo together and I’ll have that stuff done around the same time so that I can jump straight into any animation revisions that become obviously required once I get to see it all in-game. We’ll then need to really iron out our GUI.
 
Here’s some of the cycles that I did just before going to PAX. We of course have the “single punch” which happens when someone taps the button a single time, and the continuous punch which it transitions into when the player taps the button multiple times:

 
And then we have a few others:

 
It’s a dangerous task making estimates on how long it will take to make a video game, but I sincerely hope that what I’ve described above is all done in the next couple of months. With any luck that will mean that we’ll be able to start doing some play testing at local events like Vancouver’s Full Indie or San Francisco’s IGDA. I’m personally hesitant to make any sort of demo available online until we get some sort of an A.I. / Networked system in place so that people can properly experience the game the way we want it to be.

[karlozalb]

I like the idea and the art .The name is great in my opinion, that "super" smells like retro.

It’s a dangerous task making estimates on how long it will take to make a video game

Thats absolutely true!

[Allegro]

I like the idea and the art .The name is great in my opinion, that "super" smells like retro.

Thanks! It's been a ride developing a look, so I'm glad that it's working for some people

It’s a dangerous task making estimates on how long it will take to make a video game

Thats absolutely true!

True story, we'd actually started making a game several months before this one, but decided after getting far enough along that the scope was just too enormous for two people. We'd projected that at 5 years to complete. This one we pegged at a year, and ... well... a year later and it's still not done

I'm scared at how things would have turned out if we'd continued that other project.



So what's new for this week?

We’ve had it in our heads for a long time now, that this Oil Sands level that we were creating was going to be a hazardous level to play in. While admittedly it’s looked pretty straight forward until now, that’s because it’s really only been half complete. It’s now like… 60% complete. Or something.
 
I’m still trying to refine this into something that I’m happy with. At the moment this is just a prototype. Expect the flame animation, colors, lighting, and the way it ignites to change… but I thought that it would still be worth showing off a snippet of what we’re expecting out of the level.
 

The idea is that we’ve got a multi-tiered level to play in… you can wade through the oil, jump up onto the rocks, or up onto the bridge in the middle. But if someone gets their mitts onto a weapon such as a molotov, or a flame thrower… well… the rocky areas are going to become your best friends quite quickly. The safe spots should be a little more clear in the end than this image would indicate. It was a pretty quick attempt at getting a proof of concept, and thus it’s not being masked particularly accurately at the moment.
 
And that’s why I say it’s only 60% done at the moment. I’ve got some ideas for how this is going to work, but there’s going to be a lot that will need to be done on Matt’s end to make this all work too.
 
Aside from the purely artistic and technical things of getting it to work, there’s also the question of how this should work in practice. For example… I expect that the fire will be able to be put out… but since I also expect characters to be able to catch on fire, I’m honestly not sure what the odds are that players will be able to keep the oil free of new sources of fire for any meaningful amount of time. Should characters be able to recover from fire -or should it set them ablaze and give them a timer that they can run around wreaking havoc until they die? Should they be able to move around freely in the fire – or should they bounce out of it immediately and take damage?
 
I’m looking forward to this coming together some more so that I can get these questions answered!

[Allegro]

Further development in the visual effects area of stuff...

I’ve been trying to work on the fire effects for Super Hematoma. As I discussed last time, we’ve got a level that catches on fire. Because this will be multiplayer and people will be at different points in the stage when it ignites, this means we’re going to have to have some sort of a flash/ignition effect, the flames will then spread across the level, cycle, and then die out. When dieing out, characters may be able to restart the intense burning cycle again and keep the flames going. I don’t think I’m going to be fancy and have any sort of extra flare-up happen if characters splash about in the liquid while it’s on fire. And of course, since there is a 3d environment, we’ve got to have the flames properly being masked out around rocks etc.
 
I’d kind of forgotten about this when I set out to start animating the fire that will happen from our molotov weapon itself:
 

You see, I started trying to get a nice flame going here that would spread out from the impact source, and then allow us to cycle the flames, and then have them die out. This is similar to how the flames will burn on the whole oil field. I was kind of pleased with the fire that I’d started, until I realized two other things. One: this fire really is kind of flat given that the games takes place in a three dimensional world… and Two: we’ve got platforms, and obstacles in this game that the fire will need to contend with. It can’t just be a one off crafted fire like what you see above, because in the event that the flames occur near the edge of something like a cliff…
 

…we run into a problem where I’m not really sure of a good way to deal with the flames. Afterall, we don’t really want flame burning in mid-air. Clipping the sprite looks atrocious though.
 
So what’s interesting/horrifying, is that (I see no other way around it) we’re going to have to build a particle system for our game the same way that we would be required to do if we were making a fully 3D game. Yet, if we’re going to maintain that pixel art look to everything, the flame really should still remain as a fairly straight forward sprite similar to what we’ve got below.
 

I’m sure the fire isn’t the only thing that will make use of particles. Maybe we should throw the clouds onto a particle system now. Instead of having one repeating tileable card that pans, we could just populate the clouds semi-randomly each time the level opens. We could have each individual cloud pan at an ever so slightly different speed. Exciting in a way, but it’s a bit of a set-back to have a new thing to engineer. It also means that I’m thinking about the fire differently now too. Whereas I was planning on having a bit more of a cartoony solid color to the flames (not just a single color like what you see above… but still opaque), I’m now looking at the fact that we’re going to have particles with sprites spread around a 3d scene. And transparency goes a long way to selling depth. For example if we look at this test below:
 

Ignoring the fact that we’ve got a single flame animation instanced around the character… and ignoring that the character is able to hold such a pose in the fire… you can see that having opaque fire tends to look a little clunky. Sure it looks like pixel art… but it’s hard to get a sense of depth out of that. If we’re going to make things take up three dimensional space, I’d like to make use of some of the shading methods I’m used to, and perhaps do a luminance look-up of the fire to have some transparency in the flames.
 

This gives us something that still has a pixely look to it… but I think is going to help make things come together a little more as an interactive environment. I doubt we can expect any change in the lighting from fire…. but giving some transparency does help give it a voluminous appearance. I don’t know that we’ll be able to get as charming of a “spreading ignition” effect out of these particles compared to the one-off effect that I had started with… but since particles will more easily be able to get depth, and not look like crap at the edge of platforms or when near collidable objects, I really think this is the approach to take.
 
I think we will be limiting the molotov’s behavior to ignition on impact with the ground (as opposed to ceilings or walls), but it will still have a bit of a fireball effect on impact…
 

…but it’s extremely difficult to get a sense of what this will all look like at the moment without a particle system in place for me to combine the different elements in-game.

[Allegro]

You can see the original concept for the Rain City level just a couple of posts up...basically, it’s our version of beloved Vancouver: complete with rain, neon lights, and burning cop cars. It’ll be a while yet before you see any finished background art for that part of the game, but I do have a special treat for you this time around.

  I’ve decided that I’m not 100% sold on confining our sound track to the standard capabilities of the NES. In past tracks, I tried limiting myself to the basic module in Famitracker: two square channels, one triangle channel, and one noise channel. I’ve been pretty lazy with incorporating DMC samples (low quality sound recordings that aren’t computer driven). This time around though, having played with it a bit in the past, I decided to try pushing the envelope a bit and went with the Nintendo MMC5 module. This means I get access to a couple of extra square channels.
 
  When not just singing into a microphone, I like to jam out melodies and rhythms on the guitar when coming up with tunes. This time around instead of using the triangle channel for the bass, I decided to use one of the squares. Conveniently, the lowest note that can be achieved with the square channels happens to be the same low B that my seven string guitar is tuned to. I guess that gives me a little bit of confidence when jamming as I know the range of notes is replicable.
 
  Since I ended up using a square as a bass, that freed the triangle up for me to try getting a little more complexity into the drums. I turned it into a kick drum for this track. while using the noise channel for more of a snare sound. That left me the other three squares for melody and harmony which, made it a little more pleasant to work with. There’s a good chance I’ll revisit the Title theme and the Oil Sands theme with a MMC5 treatment to get a little more depth in the tunes.

  I also haven’t had to use triplets in Famitracker until this track, so it was interesting figuring out how to make that happen. Since you don’t get the luxury of writing sheet music into the program, it meant that I had to play with note delays instead so that notes were not triggered at the precise time that they would normally. Fun!
 
Anyways, here’s the track. Enjoy!
 

[Raku]

Wow, this is looking pretty amazing. I'm really loving these graphics so far, especially the colors used on that rocky area's background and such.

[Allegro]

Thanks for the support!

[Allegro]

  Having opened up the sound of Super Hematoma last week by incorporating the MMC5 sound module for the Rain City theme, I decided to revisit the other two themes to see if they could use some extra depth as well.

  I actually spent a while attempting to re-work the Title Theme, but in the end decided that I was happy with the way it sounds. It has a simplicity to it that I like, and I had intentionally kept it somewhat subdued from the start. It has more of a brushing type soft rhythm to it as opposed to something more prominent like a stick on a snare. I didn’t feel that adding any extra kick or altering to a snare was improving anything, nor did I think that any extra harmonies or melodies were having me a feeling that was more satisfactory than what we already have. I suspect that the Super Hematoma Title track will remain as-is.
 
  The Oil Sands theme on the other hand did go through some revision. There was the occasional bass melody which I changed, and I think one or two of the original trebble notes may have been altered as well, though subtly. What I did do however, was make a change similar to how the Rain City theme works. I wanted to use a square channel for bass, and free up the triangle for kick drums. The MMC5 module wasn’t giving me a bass sound that I liked. In this case, I was happy with the timbre of the triangle channel and wanted to try and retain that sound. After some experimenting with the Konami VRC6 module, I found a sound that I liked and was successfully able to move the bass over. I also was able to get a little more response out of varying the sound and I think I’ve improved the rhythmic pulse of the bass by emphasizing certain notes.
 
  The kick drum sound is pretty much the same as what I’d used for Rain City, and I think contributes a lot to the sound of the Oil Sands. I think it’s got a much more interesting mood to it now rather than the constant chug that it used to have. I was originally trying for that sound, and I think it’s still there, but I like the extra emphasis of the new triangle channel.
 
  Finally, I added in a new additional melody. Honestly, my vocabulary isn’t good enough to describe what I was going for with this, but I think it works. Especially in the middle section, which I always had felt was a little stagnant, I think it helps add a bit of a building up quality. It retains much of the same feel of the original with just a little bit of extra depth.
 





 
  In other news, as I mentioned earlier, I’ve got some Steam Keys gathering virtual dust. I ran a random draw via Twitter today, and @SeeminglyJaded was the lucky chap that got a free copy of Fez. I’ve still got a copy of Bastion, FTL, Limbo, and Mark of The Ninja to give away. Keep your eyes peeled for a chance to win something fun!

[DanDecarlo]

This looks interesting, nice art and animations.

[Allegro]

This looks interesting, nice art and animations.

Thanks! I somehow missed that response previously, but it's appreciated!



Today's blog post brought to you by the power of Matt.


Packages of Files and Pieces of String

Hey paisanos, I’m back out of the depths of my nerd cave to give a long overdue update on some game 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 Stucker 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:
  
  
  needed to become this:
  
• Don’t bother making your own 2Dgraphics engine. It bogs down your timeline

Back to Gradius 2! Stay tuned!