Nick Pawlowski

Hiatus/Redesign

It’s time to start thinking about this a little more, I think.
I ran into a problem wherein the game engine I was using just isn’t designed for a really integral part of what I wanted my game to be like. I could either change the game, or find a new way to program it, and I decided to opt for the latter. Did some more looking around, got discouraged, and placed the project on hiatus.
I’ve been playing a lot of indie games recently (Sutef, K.O.L.M. for examples) and am starting to rethink my project. Maybe a tile-based platformer wouldn’t be so bad after all. In fact, I could make it tile-based, and maybe display a layer of art on top of the tiles so that it wouldn’t necessarily *look* tile-based. I’m still not sure, but I think I might use the veritable treasure-trove of free time I’ll have on deployment later this year to put some more effort into this. One of the guys at work is also an amateur game programmer, and one of my friends from my last command who is into software development in a big way is about to transfer. Not that I’m looking for a partnership with either of them, at least not at the moment, but I’ve got people I can use as sounding boards for ideas. So, for now, let’s just call this something I’ll be saving for the future.
Maybe in the meantime, I’ll work on the storyline and level design a little more. If I can get it cleaned-up enough, I’ll consider posting stuff on here, just for fun.

Time to wake up!

I’ve run through the program several times now, and aside from a couple little tweaks here and there, I can’t find anything really *wrong* with it. No more bugs (that Ronin-phase 1 thing never reappeared after I fixed the phase 2 problem, so I’m assuming it’s gone until someone else finds it) to chase down. So I think while I wait on graphics for the Japan dreamscape, I’ll start working on the coding for the first Awake sequence. All I really have right now is a visual layout of the level, and a couple bullets on a notepad for the storyline. The various Awake sequences aren’t nearly as well-fleshed as the dreams, so I have the feeling that this could take a little while.

Dialogue boxen

So I sent the EXE to a bunch of people yesterday asking for testers, since I thought I’d finally eliminated all the bugs. One turned up almost right away, that I could reproduce- sort of. The Ronin in the first stage (wearing armor) would get stuck at the door and disappear, leaving the Player trapped in the room with nobody to kill. I could make it happen, but only during the *second* stage of the Ronin fight. I’m still not entirely sure why it was happening, but after a few tweaks, I managed to get him to stop.
Of course, I still have no idea if he’s stopped during the first stage, since I couldn’t reproduce that part of it. Here’s hoping, right?
The rest of today was spent working on dialogue boxes. Instead of that annoying text that appears over an object when you do something, a little box shows up now, politely informing you and disappearing. Same boxes for conversations between Player and NPCs. I added a nifty little waking-up special effect to the end before transitioning to a blank white screen.
I’m starting to see a noticeable lag every once in a while- especially when the player is near the fires. I’m thinking that I’d be better off with animated-sprite fires instead of special plasma effects; it would eat up less VRAM. I don’t know if I can bring myself to get rid of the smoke, though; it looks really cool!
I think I’ll wait until the level is finished, graphically, and see how it plays. I have a feeling that the fires will have to be downsized, though.

EDIT:
Put the cursors in, fixed a problem where you couldn’t skip Emily’s text at the end by clicking. Got rid of the “Use a key here!” text; I think the green cursor should be sufficient. Noticed that the range of the sword is a lot longer than it should be, will get around to fixing that eventually. Right after compiling a new EXE, noticed that the Ronin-phase-1 tossed the player up through the ceiling on to the platform above the room. Extremely weird, could not reproduce. Still trying.
I think it’s weird that the cursors face to the right, pretty much every other mouse cursor in the history of the world points to the upper-left. These just look weird mirrored, though. I dunno, I’ll get used to it, I guess.

Why you should actually pay attention to math class in high school


I spent forever working all that mess out on pen and paper, and then trying to fix it after I coded it into the program. Of course, I forgot a sign change somewhere. And whoops, that parenthesis ended up on the wrong side of that one variable. Etc, etc. And then I got to spend the next while trying to remember everything I’d done when I learned that Autosave only actually saves if it’s in the mood and the program crashed.
But anyhow. Now the weapons are all shown at the appropriate angle, and you can no longer aim and attack behind you if you’re facing a different direction. Got the attack delay programmed into the player and the bad guys, and got some sprites for the Ronin at the end courtesy of Ayla. Fixed the attack range on all the enemies, and I haven’t been able to reproduce that weird bug where the player gets thrown into the fire and freezes. I suspect it might have had something to do with the collision masks, and was fixed when I got a new sprite for the Ronin.
Next on the list is that angle limiter- I gave it another stab, and it looks like it’s going to take some serious thinking. After that I want to try the cursor thing: a red hand when you’re over an enemy that is in range, a green hand when you’re over something that you can manipulate, and a grey hand every other time.
So, check out the new EXE, and let me know if you find any bugs or have any recommendations.

I had oatmeal with programming for breakfast

Found a band-aid for the player-bouncing thing. Still not sure why it happened, but made it stop. That bit with the updraft, too. It turned out to be not at all related to the bouncing; I suspect that I have a misconception about the use of particle effects in this engine, but I still made it not happen anymore. The charging behavior for the boss turned out to be way easier than I was expecting; not sure why I put it off so long. Implemented the sake-inventory thing, too.
Upon thinking that I had finally eliminated all bugs, I decided to play through with god-mode turned off to see if I needed to place more sake bottles around the level. I discovered several problems.

Bugs:
1) Thugs don’t get close enough to attack, since I implemented that “don’t stand on top of the player” behavior.
2) The samurai, for the most part, just jumps over the player instead of attacking him. I’ll need to figure out a different way to control the probability of his jump.
3) The player’s sword doesn’t have a time delay on it, so you could conceivably click on the samurai really quickly, before he even got the chance to attack you.
4) I’ve got a feeling that this bug has always been there, but only shows up every once in a while. Something happened when the boss charged at the player and threw him into the firepit; the player seemed frozen, and wouldn’t respond to any keystrokes. I’m not sure if he was stuck inside that little black block by the firepit, or if something happened and his “set ignoring input” never got turned off after the throw.

Features:
1) Sword angle placement
2) Angle limiter (I tried this briefly, it’s not going to be as easy as I first thought)
3) Change cursor to indicate enemies-in-range
4) Dead bodies when enemy killed
5) Invulnerability after being hit (this should go hand in hand with the sword delay, I think. In fact, instead of a sword delay, I should just give the enemies the same invulnerability after *they* get hit

So, the new EXE is based off of all this. It works splendidly so long as you play with god mode. I’ll get to the rest later. World cup game today, USA vs. England, I might take a break from coding to watch it.