Tuesday, March 29, 2011
BFXR
If you recall, I used DrPetter's program sfxr to make the sound effects for Project Jumper. Well, the lovely thing about open source code is that people keep poking away at it, and now increpare has created a new, feature overloaded version that he's calling bfxr. I've been getting pretty good sounds out of the thing by just mashing buttons at random. Just imagine what someone that actually knows what all those sliders mean could do!
Saturday, March 19, 2011
Not all effort results in progress
I got it in my head today to make a useful variation of FlxSprite. Basically, I just want to add some simple masking, a function that will let you mask of portions of the sprite as transparent.
The actual pixels of a sprite are stored in a BitmapData object called _pixels. So my bright idea was to store all the masking info into another BitmapData object called _alphamask, and combine the mask with original image to get the masked out image. A little research, and it looks like BitmapData.copyChannel() should let me transfer the alpha channel data from _alphamask to _pixels without touching anything else on the image.
The actual pixels of a sprite are stored in a BitmapData object called _pixels. So my bright idea was to store all the masking info into another BitmapData object called _alphamask, and combine the mask with original image to get the masked out image. A little research, and it looks like BitmapData.copyChannel() should let me transfer the alpha channel data from _alphamask to _pixels without touching anything else on the image.
Tuesday, March 15, 2011
Organization
One of the things that doesn't leap out at you right away as a new game developer is just how many files start building up, and how important it is to keep them organized. The project I'm working on right now (yeah, the one that's keeping me from Project Jumper. Sorry!) started out in my head as a pretty simple Arkanoid style game. Surely that won't involve too many files, right? I'll just use the standard src/com/developer/name file structure, and that should be fine.
Hah. Maybe I'm just too addicted to making new classes for every little bit of functionality, and maybe I could cram all my graphics into spritesheets, but still, my folders are becoming a cluttered mess. The OCD part of me that makes me rename/reorganize all my music to a very strict scheme is going insane that I haven't sorted my files into categories and subcategories.
Well, while this project is too far along to make a reorganization worthwhile, I think it's actually a good lesson. The aggravation I'm starting to suffer at the end of this small game will teach me to avoid the same aggravation on a larger scale when I start working on more ambitious things. This is just another of those times when mistakes are actually more beneficial than success.
Hah. Maybe I'm just too addicted to making new classes for every little bit of functionality, and maybe I could cram all my graphics into spritesheets, but still, my folders are becoming a cluttered mess. The OCD part of me that makes me rename/reorganize all my music to a very strict scheme is going insane that I haven't sorted my files into categories and subcategories.
Well, while this project is too far along to make a reorganization worthwhile, I think it's actually a good lesson. The aggravation I'm starting to suffer at the end of this small game will teach me to avoid the same aggravation on a larger scale when I start working on more ambitious things. This is just another of those times when mistakes are actually more beneficial than success.
Thursday, March 10, 2011
When to start level design
As I'm getting closer to turning Project Jumper into an actual game, it's time to start putting some levels together. It got me thinking about the logistics of level design, and when you should get started on the process. For Jumper, I've put it off as long as I can, because I (intentionally) haven't really had any direction in mind as I make this game. If I include doors, teleporters, and spikes in the level, then I'm committing myself to those things. On the other hand, if I just throw together game elements as I think of them, I can slap them down willy-nilly onto the test map just to demonstrate them, but it doesn't really make for a good game level.
I suppose in a real project, the ideal solution would be to do all your planning first, so that it doesn't really matter what order you do things, you're always following the script. The thing is, that's not really practical for a solo project where you're not even entirely sure what you'll be able to execute successfully. It would suck to design 10 large levels that rely on a rope swinging gimmick, only to find out that you're not going to be able to make a satisfying rope. Or whatever.
On the other hand, if you DO make the levels ahead of time, it gives you direction in your coding. You already know what your game has to be able to do, it's just a matter of implementing it all. I think this is probably the best way to go once you've got some confidence in your ability.
There is a third option that occurs to me, though, and I just might end up implementing this for Jumper. Make small levels as you need them, each one implementing whatever new mechanics you've come up with since the last one. At least in Jumper's case, this could let me keep bolting things on indefinitely, or at least until the program just collapses under its own weight.
I suppose in a real project, the ideal solution would be to do all your planning first, so that it doesn't really matter what order you do things, you're always following the script. The thing is, that's not really practical for a solo project where you're not even entirely sure what you'll be able to execute successfully. It would suck to design 10 large levels that rely on a rope swinging gimmick, only to find out that you're not going to be able to make a satisfying rope. Or whatever.
On the other hand, if you DO make the levels ahead of time, it gives you direction in your coding. You already know what your game has to be able to do, it's just a matter of implementing it all. I think this is probably the best way to go once you've got some confidence in your ability.
There is a third option that occurs to me, though, and I just might end up implementing this for Jumper. Make small levels as you need them, each one implementing whatever new mechanics you've come up with since the last one. At least in Jumper's case, this could let me keep bolting things on indefinitely, or at least until the program just collapses under its own weight.
Tuesday, March 1, 2011
Memory management
Project Jumper isn't really having any memory issues yet, but sooner or later there's a good chance that it will come up, especially since I'm not doing a thing to conserve memory. Fortunately, someone who's paid more attention to this sort of thing than I have has put up a blog post on this topic. If you're worried about overloading your RAM, check it out.
Honestly, this is as much a memory aid for myself as anything else. Uh, no pun intended.
Honestly, this is as much a memory aid for myself as anything else. Uh, no pun intended.
Project Jumper Part 13: Push and Shove
Man, it's been a little while, hasn't it? I've been poking around with other projects lately, along with the oh-so-pleasant jobhunting process, so Jumper hasn't been getting my full attention. But I've reached a point in that other project where I've realized I have to tear out a whole big chunk and rewrite it. And I don't really want to right now. So here I am!
Actually, this is a weakness I've long recognized in my own creative process. Maybe you can sympathize. I start working on an idea, and then when I'm not 100% certain about which direction go, I stall because I'm afraid of taking a wrong path. For some reason, the fear of having to throw out any amount of work makes me more likely to do nothing at all. Obviously, this isn't very productive. Even partially unusable progress is still progress, and nothing educates like failure. Heck, I'm even using version control, I could always just rewind to before I went wrong, and no harm done.
Oh, well. The nice thing about Jumper is that I've got real motivation to press forward even if I don't know what I'm going to do. Even a trainwreck would make for a good blog post! So anyway, let's get back to work.
Actually, this is a weakness I've long recognized in my own creative process. Maybe you can sympathize. I start working on an idea, and then when I'm not 100% certain about which direction go, I stall because I'm afraid of taking a wrong path. For some reason, the fear of having to throw out any amount of work makes me more likely to do nothing at all. Obviously, this isn't very productive. Even partially unusable progress is still progress, and nothing educates like failure. Heck, I'm even using version control, I could always just rewind to before I went wrong, and no harm done.
Oh, well. The nice thing about Jumper is that I've got real motivation to press forward even if I don't know what I'm going to do. Even a trainwreck would make for a good blog post! So anyway, let's get back to work.
Subscribe to:
Posts (Atom)