i++ !== i--

(i +1 does not equal i-1)

Those of you who played Beta on the Beach know that the game lags when there's too many monsters on the screen.  As you defeat monsters however the game will speed back up again.  That's partially because the game is drawing less of course, but more because the code is actively clearing dead monsters from the hittest array.  I was honestly pretty proud of how it all worked. 

However, there was one hiccup that bugged me.  It pretty much is what made me decide to release Beta on the Beach.  The game builds a giant array for details about each monster on the screen, with each monster getting their own row.  As that monster dies, that row gets cleared, thus making the array smaller.  It's all controlled by a loop that looks like this:

for (i=0 ; i<_root.BGA.length ; i++)

If you don't read much code, all this does is start counting at zero, and continues counting rows upward until it's read the last row from the monster array (BGA = Bad Guy Array).  Now, the problem occurs when a bad guy actually dies.  I want the array to remove that line to make is smaller.  This naturally shifts all the rows below up one line.  BUT the loop counter doesn't know that the matrix has changed, so it continues on to the next row, which was 2 rows down when the loop started (the next row has moved up to where the deleted row used to be).

If you didn't catch all that, don't worry.  I didn't really put it all together at first either.  And there are ways to tell the loop to backup one level & retest the skipped row.  But if the counter (i) ever becomes a negative number, the loop just freaks & crashes.  The 'best' fix I could find was to tell it never to check row 0 (arrays start at 0 instead of 1), which meant any time the very first monster was killed, I briefly lost track of the second monster.  Not ideal, but I don't think anyone ever noticed.

Anyway, this weekend I finally figured out a more elegant solution, and it's painfully simple now that I see it. 

Run the loop backwards instead. 

for ( i=(_root.BGA.length -1) ; i >=0 ; i--)

Now when a row gets deleted, I don't care about the ones that get shifted, as I've already tested them.  This is probably the kind of stuff they teach in first year programming, so it's not like I can claim to be the next Einstein or nothing.  But I was still really happy to find such a simple solution, even if it is like 3 months later.  If this trend continues, I'll totally have my current Vcam problem solved by July.  ;P

-DirtyC101

Beating the bugs

So, although I don't plan to use any more of Playshapes' models, I keep the lizardfolk around for testing.  About a month ago, I noticed that they were flickering like crazy.  Imagine the four frames above cycling rapidly.  It was pretty annoying, but I didn't think much of it, as I knew I was going to be dumping these sprites later.  I did fiddle with them a bit though, & realized that every time I go edit these particular sprites, the problem goes away until my next work session.

Time goes on & I start building my own monsters.  And now, they too have the same flickering problem.  Now I'm a bit more worried.  So, I delete the lizards, update all my sprites, and the problem doesn't go away.  Fast forward past all the bug hunting, & it turns out that one of my sprites was corrupted, but not the lizards.  The problem sprite (movieclip) wasn't actually flickering at all, but it was causing the problem in other sprites.  I found it by dumb luck really.  I happened to have a backup from day 1, and I could make the flickering problem happen there too.  The only 'new' sprite in there was a door.  Sure enough, delete the door & update, & the problem goes away.  So, I guess the moral of the story here is keep your backups.  Oh, & don't ignore bugs & plan to fix them later.  The less code you have to search through, the better.

-DirtyC101

LEET

That's all.  Thanks for the hits.  =)

Yeah, I know, it's meme that's like 10 years out of style.  I still likey.

-DirtyC101

So much to learn about hats

So earlier this week I was busy drawing a wizard hat. Here's the picture below, I honestly thought it came out pretty well.

About an hour later, I was surfing around & saw the same hat by another author in a comic called Gothic Faeries (available here, warning: dickgirls). Same idea, same size, even the band is the same color.

But there's so much more to it than I had even considered. Look at all the details. There's extra bends & the outline is chipped & cut, the highlight follows the cloth. Even the yellow band has some additional texture lines to show how the cloth is bunched up. I also really like how the traceline changes color to red in places, makes it feel like it's made from cloth.

So guess the point I'm at here is there's so much for me to learn about drawing still, and likely will be for years to come. =)
-DirtyC101

Plan ahead to be naked

I thought I had a pretty neat system laid out, where each character's starting armor & weapon used the same value as the character itself. For example, these variables help me define K. Fox when I first start the game:

player = 1
weapon = 1
armor = 1

Similarly, for the bunnygirl I set all these to 11 (sadly not a Spinal Tap joke, it's to leave space in the frames). Anyway, all's dandy until I realize I need to leave a 'blank' option as well, for when you're unarmed or naked. That ends up being weapon = 1 and armor = 31. Doesn't sound like a problem at first... Hours into the inventory system, I realize that I need to large block of checks in about 6 different locations, just to test item slots to see if they're empty.

So, long story short, I spent most of today going back & re-setting all my sprites so that frame 1 is always the un-equiped option. This removes that entire block of code & replaces it a single line. Kinda frustrating, as I actually spent time to think the system out in advance, and yet it was still wrong & had to be redone. hahaha. Clearly I need to stick with coding on the fly. =)

-DirtyC101

Game Update

It's a new month, so thought I'd post a game update. Going to try to post a 'game status' update every month, so y'all will have some feel for how the games are coming along.

I'm back from vacation, and starting to work on my new game again. Tentatively, the title is "Furry Fury, The Tale of the Twin Orbs", although perhaps I should change that to 'twin balls', considering the subject matter. heh. K. Fox will be returning, and gameplay will be closer to K. Fox & the Magic Sword than Beta on the Beach (although I expect to have some 'horde' type gameplay as well).

But the important part is when will it be done. Last year I said spring on some forums, while on others I said February. Looking at everything I have planned, I'm going to go back to 'spring' as my expected due date - probably closer to April or May. Drawing is just really slow for me, and there's quite a bit I need to generate.

I expect the game to have 4 stages, and the first stage is about 1/3 done currently. Still tinkering with the game engine, as I plan to have a minimal inventory system as well - that's proving to be more difficult than it should be BTW. It works, but it's not intuitive or elegant. I'm trying not to re-invent drag & drop all over again, but it may come to that.

-DirtyC101