Nick Pawlowski

July 7th, 2011
Normal melee (katana), special melee (pitchfork), normal ranged (bottle), special ranged (whip) are all implemented and working properly. Instead off adding another item to the animation_list, I just added a few lines of code in the dude portion of the animation module to display an additional surface, centered over the dude’s position. This way, the katana bobs up and down and lines up with the dude’s hand as he runs around. The katana is currently the only one I’ve animated like this; it feels kind of pointless to be spending this much time in photoshop when I know that these graphics are nothing but placeholders anyways. I suppose after I have all the guts of the program finished I’ll go back and animate the rest of the weapons and enemies. The whip looks pretty retarded, but it’s the only way I can think to animate something like that. Maybe I can go back and change the graphic used so it doesn’t look as stupid when it’s rotated. We’ll have to see.
I also realized last night that I completely forgot about scripting. I need to create a basic script-language and interpreter to handle things like dialogues and cut-scenes. I’m really dreading it because I haven’t done any sort of planning for it; I’m not really sure where to start. I really wish I still had that source file I made back in high school for the artificial reasoning program I wrote to play turn-based strategy games. It had almost exactly the sort of script interpreter I need. I think I’ll put it off for a little bit and work on frill animations instead. I can work on planning out the scripting while I’m on watch later this evening.

July 4th, 2011
I finished implementing the pitchfork (before the final boss, since it’s required to move him from phase 1 to 2), which ended up a little less complicated than I originally planned. Instead of clicking and holding, then aiming and letting go to toss the enemy somewhere, now a click just throws them back a little bit, which doesn’t lose much of the original intention, and is way easier to program. Now that I have a decent framework for weapons, I now have a new problem to think about: animating attacks and weapon sprites. Should the dude’s sprite carry a weapon around all the time, or should it only appear when attacking? The first would look way better, but require some redesigns and a lot more sprites. Also, the attack animation I’m using right now makes the guy’s sprite about twice as long due to the sword, which throws off all the physics calculations that use the sprite’s width. I need to go back and replace every dudepos.width with a generic pixel size that I set as a global constant at the beginning of the program. Although, another way around that (and something that would fix the earlier problem) would be animating a separate weapons sprite that moves with an attack, and travels along with the dude’s coordinates. It wouldn’t look as natural, though I suppose I could program generic dude-attacks for melee weapons and for ranged weapons, and then just separately add in the weapon after the fact. That might not look bad at all, now that I think about it. It’s a pretty large deviation from the original plan, though, so it will take some working on.
Today is the 4th of July, though I don’t think it’ll mean anything different for us. I’ve heard that there’s going to be a “picnic” on the mess decks for most of the day, which I suppose means that it will be that much more difficult trying to get something to eat around meal hours. I also heard that our division will be letting us sleep through reveille and cleaning stations this morning due to the ridiculous drill/maintenance schedule that everyone’s been working around, so long as we make it to training on time at 10. If that’s true, that’s pretty good news seeing as it’s currently 2:30 in the morning, and I was only planning on getting about 4 hours of sleep. I think I’m going to set my alarm for 9:30 and just sleep until either it goes off, or someone wakes me up telling me that I’m late for something.
I can see the weapons module turning into a huge mess the deeper I get; I need to start working on making it more organized before I get too much further. I’ve decided on having a separate sprite for the weapon, and cycling an attack animation for the dude depending on what kind of weapon he’s carrying:
Overhand throw: WHIP, BOTTLE, MIND WHIP
Downhand motion: KATANA, SWORD, MIND FIELD, 6-SHOOTER (reversed order of sprites)
I can add an item to the animation_list, make sure it updates last so it always displays on top (the frills need to display afterwards, though. Might take some looking in to to make that work). I’ll get that, a melee weapon, a ranged weapon, and a whip-style weapon, and I’ll call it ready.

July 2nd, 2011
Finally, jesus. Whenever I read about any sort of TIGJam or anything where someone just “threw together” a game in a day or so, I always wonder how they did collision detection. Historically, that has always been my biggest problem. Every time I’ve had to give up, or something has taken me days to fix, it’s had something to do with physics and collision detection. Am I really making it so much harder than it needs to be? Or is it just the ridiculous combination of tile-based and pixel animation that I’m trying to use? Will I ever get a method working that’s simple enough to remember and reproduce in the future, should I ever need to do this again? Or will every time require two or three days of pulling my hair out and shouting at my code and making sacrifice unto the gods of programming before it will all work as it should?
Anyways, the player’s collisions are back to normal. It does seem a lot easier than what I had going on before, and I haven’t seen any odd bugs or other problems. I think I can go back to coding the behavior of the Japan mini-boss now. After I’m done with him and the final boss, I need to start working on weapons, which is the last big addition to the side-scrolling sequences. After that, everything will be just tweaks and coding the individual enemies, though I need to force myself to make a top-down engine first. Since there’s no gravity, acceleration, friction, etc. I should be able to make a ridiculously simple collision detection engine for that part. As long as the mini-boss is taking me, due to his unique behaviors, I’m starting to think that I’ll need the rest of the next 5 months to get everything down pat.
Also, Amanda Palmer = awesome. If I ever get around to ordering that care package for myself, I’m going to look and see if she has any other CDs out.

June 29th, 2011
Tragedy. I’m writing this from Windows Safe Mode. The other day, while reading through a pdf of Preacher and listening to some music, my computer froze (karma for procrastinating on that collision fix?), and I’ve not been able to get it to boot normally since. A CHKDISK freezes about a quarter of the way into it, defrag won’t make it past the initial analysis, and the bios memory checker says there’s no problem. A system restore didn’t fix anything, and the event logger had something about a faulty file structure at the time of the crash. I’m going to have to reformat and restore to factory conditions. Hopefully I can find someone with an external hard drive who will let me back up my documents, music, and programming stuff. I’ll just have to eat most of my games as losses; most of them were installed off of Steam back when I had an internet connection.
Also, I’ve decided on a rework of the physics engine, based more off of the enemy collisions. I think once it’s done that it will look more natural and be easier to work with. I just have to take care of the overall computer issue first.
Edit: No reformat necessary! I loaded up in safe mode, made a list of all the services that were “necessary,” disabled all but those, and then loaded windows normally. Using the windows console, I re-enabled the services one at a time until I found the offender, something called SuperFetch (used to improve access to memory locations). After disabling it (and a lot of other useless crap), all is back to normal. Now, time to get back to work.
To do:
1) Fix player collision detection
2) Finish coding in all the Japan enemy behaviors
3) Health and weapons
4) Code a top-down engine for the waking sequences
5) Work on modularizing the code so that japan-enemies have a file separate from other-world-enemies
6) Code all other enemy behaviors

June 26th, 2011
I’ve finished the first season of Farscape, and read through all of I Kill Giants, and now it’s time to get back to work. I’ve been putting it off, because what really needs to happen is a redesign of the physics engine. The way I’m handling player collisions needs to be more similar to the enemy collisions, but there’s lots of things that make it not-that-easy to translate over, and I’m really dreading it. We got a portable AC unit for the office, and while the overall temperature still sticks around 94, if you sit right in front of the AC, it’s almost comfortable.

June 22nd, 2011
The animation module is complete, and works perfectly. However, it ended up revealing some more issues with my collision detection, and three days later I’m still trying to figure out why the player sometimes can’t jump off of a ramp. I think I need to take a small break; I’ve been working on this thing for almost two weeks straight. Of course, the office I’m working out of is also about 94 degrees now (ranging from about 92 in the morning to 98 in the afternoon), and that makes it awfully hard to concentrate. The other day, my supervisor walked in after I’d fallen asleep in my chair and thought I’d passed out from heat stroke. “Pawlowski, I thought you’d just sweated yourself to death!” Unfortunately, I don’t see the physical conditions getting better until after we leave the middle east, which will be months down the road; I might have to try and find somewhere else to work. On the upside, I got my stitches out yesterday, and my head wound is healing up rather nicely.