July Update

Next Game Release: Summer-ish

So the only big things left to do are animate the human boss & final boss. So it would make sense that I'd be working hard on that. Naturally, that's not the case. Instead, I've been working on:

Yeah, I think one person commented that the game wasn't as hard as he was expecting. So clearly it made sense to work on that. lol. No really, I've actually been working on Horde mode a bunch. Rather than flood the screen with mobs, I wanted to try increasing their difficulty. Once I had that piece of code, it seemed like it wouldn't be too hard to incorporate it back into story mode as well. Turns out I was wrong on that part, so when the next release comes out, I'll be asking y'all to specifically look for spots where this is broken. heh.

And for those of you who wanted an invulnerability code... well, okay, this isn't it. But I also added the code "Softer", which will reduce the game difficulty. I think you'll find it's getting pretty close. Just don't go overboard with it, or the mobs will just flop over in seconds regardless of how you set the grapple duration.

In related news, I've been going through the tutorials over at http://www.codecademy.com/. My 'formal' programming training stops at loops & if/else statements. So much of "object oriented programming" is just lost on me. I'm slowly fixing that. They don't have Actionscript specifically, but Javascript has been close enough so far. It's also been inspiring me to write slightly better code, so I've been going back & revamping large chunks to use functions, rather than having the same code copy/pasted into 10 different spots. Yeah, I'm sure that will break something too. The great thing about programming - it punishes you for doing it 'right'. =D

DirtyC101

(Edit - For some reason like 1/3 of the text keeps getting hi-lighted in white.  I also think I'm seeing individual words in the wrong font.  Think I've fixed it, but damn, WTF?)

MoreWithTheBugHunting

(Another long-ish post about code.  FYI).


In the beta, there's a bug where if you die & restart while being double teamed, both monsters will become invisible.  I believe I have that fixed.  I thought I was pretty clever & used the state variable (in my case, _root.held) to track how you die as well.  That variable used to only tell if you were held or not, but it has since grown to pretty much capture any state - moving, attacking, grappled, etc.  So having it also track death & death type wasn't really a stretch.  So now when you hit continue, the game knows if there were any grapplers & what to do with them.  But this change brought along new 'interesting' bug.  Being killed by a grapple caused the 'game over' screen to play twice. 

Now, this is not a game breaking bug, so I put it on the back burner as a 'huh, wierd' issue to be resolved later.  I was the mood to do some puzzle solving last weekend, so I picked this one up as a challenge. 

Those of you who are thinking that having one variable track so much is a mistake are on the right track.  Turns out that late in the 'death' code this variable was getting reset as part of a pose change, which was causing the whole thing to reload.  So I reckon the lesson here is watch what your variables are doing.  I'da never found it if I hadn't been tracking the held variable & just watched the hero get killed over & over.  Which made for an interesting night BTW.  ;P

The other bug I found this week was even more subtle, but it's been in the game for a while & man has it irked me.  If you managed to completely shift the grapple in your favor, the whole bar is supposed to shift to your color & the arrow game is supposed to end.  However, half the time the arrow game would continue after the bar changed color.  Now, this was a frustrating bug to track, because honestly I don't peg the grapple meter all that often.  So I'd see the bug, look for it for a few minutes, get distracted, and then not notice it again for a week.

The problem all stems from how I named these variables.  In this case I was looking for a variable called grapplebararrowcheck, which gets set to false if the the bar gets maxed.  The problem ended up being I mistyped the variable in some places as grapplebarrowcheck.  See the difference?  Yeah, I didn't either.  What if I type it as GrappleBarArrowCheck and GrappleBArrowCheck?  More obvious now? 

Up til now I had been purposely using all lowercase letters in my variable names, to avoid any problems with case.  Now that I've made this mistake though, I think I'm going to move to capitalizing the first letter in each word.  Flash already does something very similar with it's commands - it capitalizes every word past the first.  I'm told this is known as camel case.  Yet another smart idea I wish I'da picked up on sooner.  Ah well, now I'm all learned & ready for the next bug.

And believe me, there's going to be more bugs in the next release.  So far I'm only talking about the ones I've actually fixed.  There's a bizarre one at the moment where trying to save the bunnygirl will occasionally spit everyone out into the engine room & lock the game.  I still haven't puzzled out exactly what triggers it, so I'll have 'fun' hunting that one.  Maybe I'll draw some more first.  hahaha

DirtyC101

Frustrations Per Second

(This is a long post, and mainly code & theory related.  Just FYI)

So I mentioned I wanted the game to run faster.  There were two more things I wanted to try.  The first is optimizing the backgrounds.  The default graphic type is vector art, and flipping it to a bitmap is supposed to make the game run faster.  It's a pretty simple change, you just add this code to the 1st frame of the clip:

this.cacheAsBitmap = true

I don't quite understand why this works BTW.  It has something to do with vector art requiring more resources when it needs to update (Vector art can also do more, like spin or zoom easily, so vector art is also the safer choice most times).  What I do understand is that the first time I tried it the results were just crazy good, possibly better than the quality button.  Unfortunately, subsequent applications were not so incredible, and often I couldn't see any improvement at all.

So I decided to try & be a bit more scientific about this.  I built a shitty little FPS counter by placing this code in the main loop:

newtime = getTimer()
_root.xxx = _Math.round(1000 / (newtime - oldtime))
oldtime = newtime

There's some variable declarations elsewhere of course, and _root.xxx is just the name of a global variable I use when I'm chasing errors.  With this 'tool', I then altered the background in small steps.  I also reset horde mode to spawn exactly 10 monsters just off from the hero.  And here's what I found:   (I should note that the FPS output was an integer, so the decimal point is my interpretation of how often it was flipping around.)

                                               FPS
Original Background:                    3.4
Bitmap, built from movie clips:       3.9
Bitmap, drawn from shapes:          4.0
No Background:                          5.1

Yeah, that's some shitty FPS there eh?  It's supposed to be 20.  But it does show an improvement with this bitmap idea, so at least it's a step in the right direction. 

The other thing I wanted to play with was optimizing the symbols that make up the bad guys.  I think I've mentioned this before, but there's a simplify tool that will substantially reduce the line count of your symbols (The command is in the main toolbar, under Modify, Shape, Optimize).  I played with this in the past & wasn't impressed, so this time around I cranked it to max settings.  Not as a permanent change, more to see if it would do anything at all.  In my mind, this should be very similar to what the quality toggle is doing, so I was hoping to perhaps find a good middle ground between graphics & performance.  And here's what I got:


                                          Normal Monsters            Optimized Monsters          
Original Background:                    3.4                                   4.0
Bitmap, built from movie clips:       3.9                                   4.2
Bitmap, drawn from shapes:          4.0                                   3.7
No Background:                          5.1                                   4.6

Now call me a pessimist, but the FPS numbers between the normal & optimized are virtually the same in my opinion.  There's no clear indicator that optimizing the shapes improved performance at all.  (This also tells me there's a lot of error in my data gathering ability, but that's nothing new. hahah).  In my mind, it does show a small improvement with the bitmap idea though, so I'm going to keep doing that for backgrounds.  And it looks like it doesn't matter how the backgrounds are built either, which is nice because it means I don't have to change a lot.  hehe. 

So, that's my conclusions from this.  What do y'all think?  If I toggle the quality button to low, the FPS jumps up to anywhere from 12 to 20.  So clearly the quality button is doing more than the optimize shape command.  In my opinion, that also means the bulk of the processing time is being spent on the graphics, not the code.  I reckon that's a good thing, but I'm not sure there's much I can do to fix it, short of 'draw less'. 

DirtyC101

K is for Kwality

So, some of you may have noticed that the game gets slow when there's too many enemies on the screen.  Ever since day 1, I've been convinced that the problem lies in the code.  In particular, I rely heavily on the hitTest() command, which known to be processor intensive.  In order to minimize this, I nest the hitTests under layers of if() statements.  The theory is that an if() statement is quick, while a hitTest() is not.  And if I can get an if() statement to flag false, then I can skip the hitTest() entirely.  Okay, maybe I'm not explaining it very well, but when it was explained to me it sounded solid enough.  haha.

So, did all that.  Actually been doing it since my first game, and I do think it helps.  But it's not enough.  While I was away, Renara (LoK forums) posted a bit about optimizing code.  And that really got me looking at my code again.  Although I knew it was bad form, I often had 2 or 3 onClipEvent() loops running simultaneously, as it was just easier for me to code.  So I went back & fixed that.  And once again, it helped, but it's not the miracle fix I was hoping for. 

What it did fix however is that now when I'm fighting several enemies, if I scroll the screen to hide most of them, the game suddenly speeds back up again.  This made me start thinking that maybe this isn't entirely a code problem after all.  Some of y'all had requested a 'quality' button, which was pretty common in older Flash games.  I really hadn't even considered it, but after digging some I found the commands & figured I'd give it a whirl.  And sure enough, with the video quality set to low, the game now runs great.  And WOW does it look like utter shit.  Enjoy the picture below, it reminds me of like an old 8 bit game gone horribly wrong. 

So for those of you who prefer speed, there's going to be a quality button.  I'm not real happy with that fix though, so I'm going to play with the sprites that make up the monsters, and see if further optimizing their shapes can speed the game up some more. 

DirtyC101

play();

My plan was to start slowly, and mainly just work on the drawing stuff to get my feet wet again.  Yeah, that plan lasted about 5 minutes.

One of the problems I mentioned back when the game was posted is that opening the inventory while a grab is ending will lock the game up.  (This is a different bug than the lockup during a scene change BTW, but I think I have that one fixed too).  This particular bug is caused by having two simultaneous gotoAndPlay() calls that point to the same frame.  So, Play + Play = Stop.  I guess that's like hitting the play button twice on your VCR (lol, I'm old), the game pauses instead of playing.

This is one of those bugs that I have really wanted to fix, and every time I came back to it, nothing.  Hours wasted here, lots of checks & BS added, and still nothing.   I just had one of those "fuck, THAT makes it work?" moments, and it's so dumb that I feel it needs to be shared.  heh.  Turns out putting a play() command on the target frame keep the game moving.  It's a dumb solution (Play + Play + Play = Play?), but at this point I'm really happy with a dumb solution.  =D

Why is all this even remotely important you might ask?  Because only some of the weapons grant invulnerability with their S attack.  If you're surrounded & trying to make some room as a grapple is ending, sometimes it's better to switch weapons first.  And now that's finally an option. 

DirtyC101

May Update

Feel kinda silly calling this an update, because I haven't touched the game since my last post. But, my list of 'busy' is getting shorter by the day. With luck, I'll be back in the saddle again by the middle of this month. On the upside, one of the fun results from all this work is I should have a new(er) computer to work with, so it's definitely not a total wash. haha

There were 2 big bugs y'all found, and wanted to talk about them a bit. (Yay for sorta - code theory!) The first is that the game will lock if you mash buttons during a scene change. That has to do with how commands are sent & executed. If you can imagine, once you press the A button to attack, I have to tell the program to stop accepting further inputs of the A button, or it will keep sending you the the first frame of the attack animation until you let go of the A button. Conversely, the final frame of the attack routine tells the program that the attack has ended, which resets the hero back to the default state. The problem here is that a scene change interrupts the attack routine. The last frame never plays, which means it can never reset the hero. So, the program thinks you're still in the middle of an attack & won't accept new inputs, but it will never get that reset signal because the animation was stopped. This one should actually be a pretty easy fix. Simply tell the end of the scene loader to reset any attacks. Or I could lock the keyboard from inputs during scene changes.

The second is that if you die & continue while double teamed, one of the monsters will become invisible/invulnerable. There were no double team animations until about two weeks before the release. This was the last feature I added, and no real surprise, I missed something. In this case, I simply forgot to tell the continue code to check for a second monster in a grapple. So when you continue, it never properly loads the second monster back. He's still there, but his sprite is 'lost'. Actually, it's off-screen, which is where I 'hide' sprites I know I need but don't want to show at that time. What I find interesting is that some of the hit attacks from this off-screen monster still seem to work normally. In my mind, they shouldn't. (And that is neat, imo.) Anyway, this should be a simple fix of telling the continue button to check for a 2nd grappler & reload them if necessary. Hell, I may not have to even run the check, I may simply tell it to reload two grapplers every time, and if the 2nd grappler isn't there it shouldn't do anything.

And since I like to end with at least one picture, here's one from the ULMF forums that made me lol. One of the guys there hacked the game's variables so that they can be set to anything - note the 859 continues. ;)

Til next time
-DirtyC101

April Update

April Update: Demo is on schedule for April 15th.





Hm... a bit short for a post. I know, let me blather on about something I learned just this week. Actually, let me back up first. When I released K. Fox & the Magic Sword, the file size was just over 4 MB. About a month later I released version 1.1, and the file size had shrunk to just over 1 MB. What changed you ask? I learned how to compress sound files. The background music was taking up 3 MB of a 4 MB game.

So, this week I've been adding in the double team animations, and the file size has grown quite a bit because of it. Simultaneously, I've been having this 'funny' problem where saving can take up to 10 minutes. I assume the two are related - it's like I've exceeded some file size limit. I've been thinking the machine is hoping into virtual memory, or the hard drive is full or something else along those lines, but nothing is showing up as being obvious. Anyway, about the same time I learned that you can also compress sprites. AWESOME! I thought, I'll cut my file size by 75% for sure, probably even more because graphics take up a lot more space than sound files. This should totally fix my saving issues.

The compression tool in Flash works by combining features together. So a drawing with several small lines converts to fewer, smoother lines. And there's even a slider bar so you can control just how much it smears your work. (For those of you playing along at home, it's under Modify, Shape, Optimize). I didn't really want to change my art that much, but even with the slider set to minimal I was seeing the number of curves get cut in half. So, yeah, I was super excited about this.

I'll skip to the end here. The FLA file (the one I work with) shrunk from 53 MB to 50 MB, and the SWF file (the one you play) shrunk from 2.6 MB to 2.4 MB. So... yeah, not the improvement I was hoping to see. I'm going to keep these changes, as I really didn't notice much of a visual change, and maybe it will make the game play a bit faster as well. But, have to say, not the game changer I was hoping for.

So that's the main thrust of what I've been working on this week. I've also been a bit paranoid that I have a more serious computer problem, so I've been a bit better about making backups & such. So far, the extra-long save times have been the only anomaly. Here's hoping I find the cause sooner rather than later.

-DirtyC101

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

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