So, I've been working on the final boss for the first act. Let's just say that if you like tentacles, you're going to be happy. And if ya don't, no worries, I believe this is the last appearance for a while.
So now my mind's on tentacles. (Not a terrible place to be, really ;) In the beta, the few tentacles we do see are pretty chill. They just kinda sit there & rock back & forth a bit. That doesn't seem right, in my mind they should be writhing & wiggling all over the place. When I try to do that however, it comes out looking like crap. I see spazing & just jumping around rather than the wiggle movement I want.
Which bring me to the link below, which is illustrating the method I'm trying right now. The actual motion of the tentacle is very similar, but I'm redrawing the outline every other frame. This makes it seem like it's bouncing around a lot. It's pretty close to what I'm trying to achieve. The underlying motion is still rather chill, I may go through one more time & amp that up a bit. But otherwise I'm pretty happy with the improvement.
(I also posted this simply because I didn't know how to embed flash files into a browser. I seem to have figured it out. Hooray for copy/paste. ;)
DirtyC101
What if porn games were actually 'good' games too?
(Not that my games are good mind you, but it's a fancy goal.)
Wednesday, August 31, 2011
Thursday, August 18, 2011
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
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
Tuesday, August 16, 2011
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
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
Saturday, August 6, 2011
August Update
I'm sure everyone's wondering when the next update will be. I don't know. I'll probably put out another beta before the final release, but until I feel I've got something worth showing or testing, I'm going to keep the actual game under wraps. On the up side, I'm hoping to have the full game done before the end of the year (3 games in 2010 & nothing in 2011 would be pretty lame, imo).
Let's talk about noise. What do you call all the moaning, panting, & screaming that the chic does during sex? For the sake of keeping this short, let's just say 'voice' It's pretty much the only noise the characters have during the game, so I think calling it their voice fits. That's what I've been working on the last few days. I've never been happy with how I've done this in the past. The girl's voice has always been called by the animation timeline. So say whenever there was a thrust animation, the first frame would also play a moan sound. The problem with this is that some of the animation loops are less than half a second. In order to keep the sound from clipping itself, I had to cut the voice samples to be shorter than half a second. Which just sounds like shit, imo.
I had a new plan to fix all this. I was going to make longer sound clips, and loop them based on the sex position. The problem is now that I have it working, I don't like it. The sounds don't sync with the motions, and because the voice loops are still fairly short it gets repetitive very quickly. It may be even worse than the old method, as at least with the old method I could squeeze in some variety with some random calls.
So, I've decided to scrap this new system. Unfortunately, I haven't figured out what I want to try next. Voices are very important (imo), and I want to get this nailed down before I make too much more of the game. I'm sure I'll puzzle out something, but progress is slow when I don't have a target to aim at. On the up side, I've now got a much better handle on how the onSoundComplete command works (It triggers code when the sound stops, but you HAVE to call a function with it. That was a bit beyond me when I first started).
That's most of what I've been doing lately, so no new picture this month. Oh, I did add a run button though. Technically it works just fine. However now when you're running you can't go through doors. Yes, I'll get that fixed, but I thought it was funny. Crazy code, always doing exactly what I tell it to do. =D
DirtyC101
Let's talk about noise. What do you call all the moaning, panting, & screaming that the chic does during sex? For the sake of keeping this short, let's just say 'voice' It's pretty much the only noise the characters have during the game, so I think calling it their voice fits. That's what I've been working on the last few days. I've never been happy with how I've done this in the past. The girl's voice has always been called by the animation timeline. So say whenever there was a thrust animation, the first frame would also play a moan sound. The problem with this is that some of the animation loops are less than half a second. In order to keep the sound from clipping itself, I had to cut the voice samples to be shorter than half a second. Which just sounds like shit, imo.
I had a new plan to fix all this. I was going to make longer sound clips, and loop them based on the sex position. The problem is now that I have it working, I don't like it. The sounds don't sync with the motions, and because the voice loops are still fairly short it gets repetitive very quickly. It may be even worse than the old method, as at least with the old method I could squeeze in some variety with some random calls.
So, I've decided to scrap this new system. Unfortunately, I haven't figured out what I want to try next. Voices are very important (imo), and I want to get this nailed down before I make too much more of the game. I'm sure I'll puzzle out something, but progress is slow when I don't have a target to aim at. On the up side, I've now got a much better handle on how the onSoundComplete command works (It triggers code when the sound stops, but you HAVE to call a function with it. That was a bit beyond me when I first started).
That's most of what I've been doing lately, so no new picture this month. Oh, I did add a run button though. Technically it works just fine. However now when you're running you can't go through doors. Yes, I'll get that fixed, but I thought it was funny. Crazy code, always doing exactly what I tell it to do. =D
DirtyC101
Subscribe to:
Posts (Atom)