This week I got audio working in the game, as planned. Creating music and sound effects takes me a very long time, so for now it’s re-used audio from the original Bleed. My goal is to create a functional demo first, and then spend whatever time I have left over making it polished and fresh.
I did add one new feature to my audio setup: sounds now fade the farther off-screen they originate. When a sound plays, I just measure the distance between it’s origin and the camera. Within a certain range (basically, enough to encompass any sound on-screen) they play at max volume, and after that they fade until they don’t play at all. It’s simple, but I like the effect.I also got to work making the menus for the demo! Just like the audio, they’re pretty rough, but I don’t need them to be complicated or ultra-detailed right now, I just need them to be there.
We got your main menu:
There won’t be any options in the demo, just straight into the game.
One of the things I worked on this week was particle effects! You probably know what they are, but in case you don’t — particles are tiny images, used purely for aesthetics. I have them all in their own sprite sheet, just like tilesets or animations or anything else.
Behold, particles.
Particles don’t need collision detection or AI or any other fancy code, so you can have a whole bunch of them on-screen without much of a performance cost! Mine have a few basic properties like weight, transparency, scale, rotation and animation speed… and that’s about it!
Anyways, they can add a lot of life and polish to any game. There’s already a bunch in Bleed 2, like bullet casings and air-dodge trails. Here are some more I put in this week:
Bam! Hitting enemies with the katana now plays a slicing animation along with some other effects, and dying Invaders lose their guns. These are all particles! Continue reading →
Soooo this week, I got the final level roughly half-way finished… but then something happened. I got accepted to show off Bleed 2 at an upcoming expo — something I’ve never done before! The prospect is equally exciting and terrifying.
The event is about a month away, which means I really have to alter my game plan here. Up until this point I’ve been piecing Bleed 2 together in rough, with the intention of having a very-unpolished-but-fully-playable alpha that I could playtest, improve and add to. While it might look okay in gifs, the fact is there are a LOT of basic things missing or rough around the edges, including music, sound effects, particle effects, menus, etc. There’s no way I can show it off like this.
And so, the assembly of the main campaign has been put on hold. Over the coming weeks I’ll be focusing on making the first level as complete and polished as possible. In many ways this will be good for the game, because it means a lot of refining and bug-fixing, which will positively affect the entire game as a whole. It’ll also be a test of how good I can make the first level, hopefully establishing the level of quality for the rest of the game and giving me an idea of how long it will take for me to accomplish that.
This all happened late in the week, but I got a little work started already:
I altered the sprites of enemy bullets to make their colour more clear. I’m also playing with an alternate colouring of the unreflectable yellow bullets, to further differentiate them. This is for the sake of visual clarity, and to help out people like me who are colour deficient.
Old bullets on the left, new bullets on the right.
I also fixed a bug with the Entity draw order. If several Entities were drawing on the same level, it would cause the sprites to flicker and fight since they didn’t know which should draw on top of the other. Now every Entity has a small random offset to their draw order, solving the issue.
It can be a lot worse than this, but you get the idea.
That’s it for now… there will be many more changes in the weeks to come. Hopefully I can get the level together in time to show it off well! Aiiieee!!
Super Ninja Warrior Extreme is a small, simple sidescroller I made for fun with a couple friends to take a break from working on Bleed. It was released on XBLIG almost exactly three years ago today, and is the only game I’ve worked on to have a page on the Speed Demos archive (go figure!) It’s been a free bonus in a few bundles before, but has never been officially released anywhere until now. I hope it gives you a laugh if you try it out!
Quick note: this week I got the second-last level of Bleed 2 to alpha!! Yeah, it happened really fast. I had a lot of work done on it beforehand. 😀
Now, on to the topic:
I’ve been to a couple PAXes and they each had multiple panels — with multiple panelists! — all about a “day in the life of an indie dev.” To me, this suggests that the average person has a rather romanticized idea of what indie development is like. I’m sure that it varies (and maybe I just need to go to more swanky indie dev parties) but I thought I’d take a moment and describe what the experience is like for me, just in case you had any fanciful notions about it.
The simple truth is there’s not that much to it. Every day I wake up, eat breakfast, sit down at my workstation here and get to it.
Fun fact: the Xbox 360 is from my days making XBLIGs. As of late it has sadly been demoted to merely a monitor stand.
I’d guess that I spent 50% of my time writing code, 25% making art, 15% playtesting, and the other 10% doing miscellaneous stuff like writing blog posts or checking emails (which I often forget to do anyways, oops!) Sometimes someone sends me a troubleshooting question, or occasionally wants to do an interview or whatever, but it’s mostly just sitting here, doing work.
Dual monitors make everything better.
You can see the hardware isn’t that much either — dual monitors make work a lot easier, but other than that it’s just a mouse and keyboard. I’ve also got a high-tech notebook (with state-of-the-art lined pages!) where I brainstorm ideas and plan things out, like difficult coding tasks or ideas for boss visuals. It’s been two years, so at this point it’s nearly filled with Bleed 2.
Only two levels left to make for Bleed 2, woohoo! Hopefully they don’t take as long as that last one.
As for composing Wryn — I don’t mean trying to calm her down (I think that’s what we call a “dad joke”.) I thought I’d go behind the scenes on Wryn one more time to show how she’s made, this time in the non-visual sense. There’s a little more going on than you might expect! As I’ve mentioned before, all objects in Bleed are something I call ‘Entities’, and all Entities have a hitbox. But if you count them up, you’ll see Wryn has five hitboxes. Whaa…?
Well, first off, Wryn needs to be able to collide with the world. So here we have her main hitbox, which tells her when she’s standing on a floor, pushing against a wall, etc. It shrinks a bit during air-dashes to let her get closer to floors and ceilings.
I’m so close to being done the third-last level of the game I can taste it! It tastes about a week or less away. So in the meantime, here’s some info about how I make Wryn do what she does in terms of visuals. Apologies to anyone who read my blog three years ago, this topic is a bit of a re-tread.
When you animate the player character in a 2D game, it’s common to store all the frames of animation inside a big sprite sheet. Quickly switching between the animation frames creates the illusion of movement — pretty simple!
It works great, but it can run into complications. For example, in the game Frequency, the player character could shoot forward, up and down — while running, jumping or standing still. For every action — like running or jumping — I needed three variations (one for shooting in each direction during each action) and it got out of hand pretty quickly.
About 1/4 of White’s sprite sheet in that game. Just looking at this makes my head hurt.
So now I’m making Wryn, who can shoot 360 degrees around her during any action. Obviously I’m not going to make 360 variations of every animation — a change in technique is required.
Back to business as usual this week! Still on the third-last level unfortunately, but I guess a longer development period is the cost of better production values. One of the many things eating up development time is all the little cinematic moments in the game, some of which I worked on this week and thought I’d get into.
Here’s Valentine’s warship that we all know and love. At several points in the game you’re going to be seeing it up-close, so this week I worked on the larger, more detailed version of the warship.
This is the big version! I created most of it, but didn’t bother with parts of the ship you’d never see. Anyways, this thing is huge! If I just saved it as a single image it’d need to be a 4096×4096 texture, which just seems insanely wasteful — so I worked a little sneaky game dev magic instead.
A little bonus info: if you run Bleed with “debug” as a launch option, it’ll start in debug mode (I’m not positive I left that in the port code, but I know it’s in the PC version for sure. My apologies in advance if that’s the only place you can find it.)
Debug mode lets you see some of the things I’ve talked about on this blog, like the hitboxes of Entities and the invisible damage volumes on the player’s weapon.
Aaaand we’re back — with our big ol’ sprite sheet, ready to be turned into a boss!
The boss separated into a sprite sheet.
But let’s rewind for a second first. Before I designed the boss’s visuals or made up the sprite sheet, I filled a page or two with brainstorming about all the ways the boss could attack. Here’s that:
You can click on it for the full image if you want to see all my dumb notes.
Knowing how the boss attacks helps me design the visuals, but it also helps me design the boss in code. Once I know what the boss’s attacks are, I can look for common elements between them and find the most simple, logical way to code them.
When it’s time to code game elements, I start with what I call an ‘Entity’ — the most basic form of object in Bleed 2. It’s got a few simple properties like a width, a height, a weight, and so on.
Some examples of Entities.
Every object in Bleed 2 — whether it’s a bullet or the player or a boss or WHATEVER — is built using an Entity as its base. In this case, the Segment Slider is actually composed of several types of Entities:
-Segment Slider: The actual boss in code. It manages all the other Entities, runs the boss’s AI, and draws the background of the Segment Slider. You can’t interact with it directly but you can hurt it by damaging the Weak Point.
-Segment: Represents a single segment belonging to the Slider. It can perform very basic commands, like sliding across the boss arena, or executing a reflectable attack.
-Gun Segment: A more specific kind of segment, used for the top and bottom segments on the Slider. It’s the same as a Segment but has a cannon that can be rotated and fired.
-Weak Point: The Slider’s weak point. It mostly exists to take damage for the Slider.