Grappling

Realized I haven't posted in a few, so thought I'd talk a bit about the new grapple system. I liked the old one okay, but there wasn't much too it. Once a grab started, there's not much to do other than wait for it to end. Those of you playing one handed probably appreciated that, so whatever I chose to do needs to keep that in mind as well.

In the old system, there were basically two looping animations, one for if you started the grab, and one for if the monster started it. In the new system I've combined both of those, and depending on who is in 'control' of the grapple, the animation will change. At the moment, the grapple control is divided into four phases - player dominant, player advantage, monster advantage, and monster dominant. I just made those terms up, but I think that gets the jist. Anyway, there's a unique animation for each of the four phases, and damage dealt/received will change based on which of the four phases you are in.

So how do you change phases you ask? Well, the starting phase is determined by who starts the grapple & adjusted a bit by health (a character at low health has a penalty). After that, control will shift a bit on it's own, based on the relative strength scores (Body Stat) between them. Those of you playing one handed will probably stop there, it's 'enough' of a game as is. For those of you playing to play however, there's an additional arrow system, where you match the arrows to further shift the bar to your advantage.

I think that about covers it, so here's some pictures of the four phases vs. a zombie crewman. Oh, as long as you have armor on, the monster can't shift advantage to the 4th phase (Monster dominant). I call it Armor Save. He will of course try to take your armor off to solve that problem.

Oh, & there's still a buncha testing numbers on the screen for me.  No worries, I promise I'll clean all that up before the final game.  hahah

-DirtyC101

Around the interwebs

So, neat thing about the internet is what you find once you actually start looking. Found this site the other day:

kyrieru.blogspot.com

It's another amateur who's making a porn game. Yeah, I know wierd right? You'd think I'd be the only one. har har. Anyway, looks like this dude has some really big plans, and I like his art style. So, if you happen to be into porn games (AKA: if you're reading this), I'd suggest checking him out in a few months.

I guess I should note that there's actually quite a few amateurs or semi-pro's out there making porn games. At some point I'll either make a link dump or perhaps make a sidebar to point to... geez, not sure a sidebar would be big enough. hehe. Well, maybe just my favorites.

Anyway, short post. I was working on the character select screen today, so here's a picture for the curious. :)

-DirtyC101

February Update

So where's that game at anyway? ;P

It always boggles my mind how much progress I have made, and yet how much more there is to go. I'm really just tickled at some of the programming tricks I'm teaching myself as I go. I'm using functions & subroutines, moving to local variables instead of global ones, nesting statements to minimize lag... I even cut the main body of code down from over 1000 lines to just over 600. Really, all sorts of fun tricks that I 'should' be thinking about as a programmer.

And then I look at my to-do list for the game. It's down to 3 pages long, and I haven't even added in stuff for the 2nd, 3rd, or 4th stage yet. There's just so much to get done. I may release a beta at some point, not so much to drum up interest, but rather so I can have a 'break'. I'm having a blast making this, but I don't want to burn out either.

Anyway, some screen shots below to give y'all an idea of how it's coming together. There's a lot of extra garbage on the screen which I'm using to help me decode bugs & whatnot. The green circles, or pretty much anything in pink is just testing stuff, so don't pay it too much attention. And looking at these pictures reminds me that I still haven't settled on a... HUD? Not sure what you call all the interface / display stuff, but one menu is a plain white bar, while another is a poorly drawn paper scroll, & the grapple menu is just floating bars. Okay, I kinda like that one. Heheh. Ah well, one more thing for the to-do list. =)

-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

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