Nick Pawlowski

With the help of some playtesters, I’ve identified, tracked down, and fixed a bunch of issues since the last build (despite my assertion that it was almost “bug-free”) and added in a title screen, a pop-up pause-menu, and the ability to save the game and reload from the last checkpoint upon a separate playthrough.  God, it’s getting so close, I can nearly smell it!
I’ve removed all the warp buttons (numerals 0-5), god mode, and tweaked a bunch of numbers as far as weapon range (for both the player and the enemies), speed, and force.  There are only a few more things I’ve got my eyes on before I call the level well and truly finished:
– Upon defeat, the final boss turns towards the player as if attacking for a brief fraction of a second before dying.  Once I have a dying animation this won’t be an issue, but it still bugs me.
– When you load up a game from a checkpoint (or die and reload from a checkpoint) everything from past checkpoints gets deleted and everything in the future checkpoint gets reloaded.  This saves all sorts of memory and processing power, but I’m wondering if it wouldn’t be better to reload the other checkpoint as well.  The other issue is that it runs the same script when you run into the tree that saves your checkpoint, so if there were any bad guys following you to it, they suddenly disappear when you save the checkpoint.  I’m still working on a way to make this look smoother, but I have a few ideas.
– The final fight seems a little too easy; I’m thinking about adding a second knife-throwing guard during phase 2 of the fight.
– The “view controls” screen that comes up from the pause menu doesn’t show the mouse.  Granted, the mouse only does one thing (well, two if you include the right mouse button, but not all computers have mice with two buttons), but I should still include it for the sake of completion.

And that’s it.  That’s all I can think of that needs to be addressed before I call the first level good and move on to the top-down engine for the “awake” portions of the game.

Again, I need you guys to play the crap out of this level; look for everything you can, and please give me as much feedback as possible.  If there are any issues aside from the ones I mentioned above (or if you have any recommendations regarding them) please tell me!

Edit:
Added a feature so that if the window loses focus, it automatically brings up the pause menu, and I changed it so the mouse-aiming thing doesn’t do anything if you’re holding melee weapons (which are all there are in this level).  Now you can use just the keyboard by moving with WASD and using L to attack.  That’ll have to change when ranged weapons come in to play, but hopefully this will help a little bit.

Huntin’ bugs!
So, I think I’ve finally gotten everything taken care of.  I fixed the ladder stuff, and one small alteration fixed a couple issues I’ve been having with the boss.  I managed to reproduce that bit with the non-deleting fadeout blocks enough times to get a good idea of what was going on, and I haven’t seen it happen again since.  As far as I can tell, there are no more bugs in the level.
My sister is planning on working on graphics for the game as part of an independent study for her schoolwork, and once that’s done I’ll have a lot more work to do, as far as implementing rotating weapons and a head that looks at the mouse cursor.  Plus, once I have all the sprites for the ronin (to include the various states of his armor) I’m sure I’ll have some tweaking to do.
Until then, though, I need to start working on a menu and a title screen, to make the first level into more of a single-level game than a stand-alone program.  I’ve been running ideas on how to do so through my head for a while now, but I haven’t actually tried anything.  I think the pop-up menu will have “Load from last checkpoint,” “Save and Quit,” “Quit without saving,” and “Title screen” for options.  The title screen will have the scrolling steps I’ve mentioned before as the background, and “New Game,” “Load Last Checkpoint,” “Quit to Desktop,” and maybe a “Credits” thing.  It shouldn’t really be that hard to accomplish.
One thing I’m worried about is loading time because of the graphics.  I need to see if there’s a way to only preload certain graphics, so I don’t have to load dozens of levels of stuff when I only need enough for one.
Anyways, download the executable and give it a few playthroughs.  Any recommendations as to difficulty, placement of objects, or mention of any bugs you find would be greatly appreciated.  I don’t feel like I should be pimping myself out on Reddit or Stumbleupon yet seeing as most of the graphics I’m using have come from all over the damn place online, so I’m relying on the four or five people that look at this site to give me feedback.
Let me know what you think!

Since that last upload, it’s come to my attention that there are actually LOADS of bugs, a couple of which make the end boss completely unplayable.  I also forgot how easy it is for me to play since I’ve been playing for so long, in comparison to someone who just downloaded it.  I know exactly when and where to jump, and I have all the timing down perfectly- for everyone else, not that easy.  I increased the damage of the weapons, and decreased some of the enemy’s damage, in addition to removing and repositioning a couple of them to make up for it.
Chasing down bugs gets really, really monotonous, and I need something to distract myself from it occasionally.  I’ve been playing Skyrim, but I’m starting to feel guilty- surely there’s something I can be doing that will still be making progress?  So today, in between bug-hunting, I made a new ship to replace that tiled monstrosity at the end of the level.

Basically, I found an image of a traditional japanese ship, worked for a few hours in Inkscape to make a vector-drawing that closely resembled it (the original had more sails, was slightly orthographic, and had extra rigging and whatnot) and then pulled a couple of the textures from the original and applied them to my drawing in Photoshop, before cutting out the area for the boss battle and the final dialogue with Emily.  Again, this is just for prototyping, and won’t be included in the final game, or even the official demo, for that matter.  It’s mainly so I can practice using shapes other than the simple squares that come from using tiles.

Meanwhile, my list of bugs continues to grow:
Knife Thug gets stuck in the attacking pose on death instead of disappearing sometimes
Fadeout black boxes don’t self-delete after death (only happened once, can’t reproduce)
Ronin doesn’t acknowledge being hit by the katana from behind during phase 2 of the battle (making it awfully hard to win, since that’s the only way to kill him)
When walking off of a solid block, if you turn around very quickly, you can trick it into thinking that you’re still standing on top of something, preventing the “falling” animation from playing
When jumping off of a slope or one-way platform onto a solid, the collision box isn’t changed from a circle back into a polygon until you *walk* onto a solid (doesn’t seem to affect gameplay anywhere, but I’m sure I’ll have issues with this in the future if I leave it alone)
Ladder movement is still all messed up

Unfortunately, most of these are complete mysteries to me, and will take a long time to work out.  Time is, however, one thing I have plenty of at the moment.

It’s been a while since I’ve uploaded a new build to show my progress; even now, I was hesitant to upload this one.  There are still a lot of things I want to fix, but every time I change something, it brings to light two other things that I want to do.  [insert nerdy Hydra reference here]  Nonetheless, it’s been more than two weeks since my last one, and it was a pretty half-assed version in itself, just to show off the collision detection methods.
So with this version, I’ve updated a few of the background graphics (you can see where I left off, I haven’t had the time to do the whole level yet) because I’m tired of staring at the built-in tiles that came with the Torque Engine.  I updated the enemy sprites- now they look a lot less japanese, but they move the way they’re supposed to (which showed me a lot of issues that I had to correct).  Fire hurts you now, and it hurts the enemies also.  I fiddled around with the level placement a little bit; it should be a little bit more fun, and a lot more challenging.
There’s still plenty of work to do, though.  Next on my list is ladders.  After the ladder reboot I implemented a few weeks ago, I’m still not satisfied with how everything works.  When you reach the top of a ladder, if you continue trying to climb up, you jump off the top of it, and then back down onto the ladder, and it looks very awkward.  This is something I actually fixed during the weird mental lapse I mentioned in my previous post, but I’ve been putting off revisiting it because I remember it being a huge pain in the ass.  Also, when climbing down a ladder, occasionally when you hit the floor, he won’t automatically dismount.  You’ll have to let up on the down arrow, and then press it again.  I haven’t figured out why it does this, since it only does it sometimes.  But it’s on the list, I swear.
Also, the executables are in a DropBox now, so you don’t have to dick around with Google Docs.  Just a minor change, but one that you’ll notice right away.

Also also, a few links to share.
The Perfect Game Follows These Eight Rules
A Kotaku article about what makes the perfect game.  It’s very broad, so it kind of has one of those self-fulfilling-prophecy kinds of feelings to it in that it’d be easy to interpret any game you like to fit (or not) those criteria.  But it’s still an interesting read, and gave me some food for thought.

How To Launch Your Game development Career in 2013
Another Kotaku article (written by Leigh Alexander of Sexy Videogameland) parodying all the ridiculous bullshit ideas that people have tried to implement as far as social gaming goes.  Very amusing.

Top 10 Events of Indie Games in 2012
An article from IndieGames.com detailing what they believe to be the biggest 10 things that helped the indie gaming community this last year.  If there’s anything in here you haven’t heard of, I recommend taking the time to read up on it.

I can find no evidence that the last three days of programming haven’t all occurred inside my head.  I have extremely distinct memories of adding in code to make it so that the enemies would take damage and bounce off of fire objects, and I remember planning on adding an “on fire” animation to the list of things to do.  I can distinctly remember the issues I had troubleshooting it when it didn’t work, and calling it all good when I finally got it, because it was getting close to night time and I’d work on the rest the next day.  And the next day, when I decided it was time to start working on a parallax scrolling background to go in front of the sky, and spending forever making one and the after hours programming it in so it looked good, realizing that I’d forgotten to shade it like I did the sky-background to show nighttime, and then just dragging it out of the field of view until I could fix it.
When I brought my files to work yesterday to work on them, I thought I’d just forgotten to drag the folder onto the thumb drive, since I was operating off of my “last version.”  But when I got home, I couldn’t find anything to show that I’d ever done any work at all.
At first I thought maybe I’d deleted the other files and overwritten them with the ones from the thumb drive (essentially reverting to my last version), which is still a possibility, except that whenever I do that, I actually delete them, not just overwrite them.  And there was nothing in the recycle bin from my game that was dated since December 16th.
The power also went out a few days ago, and I thought that maybe I’d left everything up without saving and just lost my progress.  But Torque won’t actually compile and run anything without saving, so there was no way I could have tested everything without saving my progress.  I can’t imagine that windows would have done any restore-point nonsense without informing me of it when I turned my computer back on.

The only other option is that I made the whole thing up.  I’ve been pretty sick the last week or so; especially over the last three days.  I’ve been going through dayquil like it was soda, and I’ve been so cold lately, I’m pretty sure I have at least a minor fever.  When I got home from work today, my last memory before waking up curled in a ball on the bed was getting ready to go and take out the recycling- when I woke up, the recycling was still here, but I was dressed and ready to go, and it was two hours later.
But I wouldn’t have just lost time, I’d’ve completely fabricated ridiculously intricate memories of conceptualizing, programming, testing, troubleshooting, and finishing two major pieces of code.

I think I’m going crazy.

So I’ve spent the past week or so working tirelessly on trying to fix the collision detection as far as slopes and one-way platforms go; I feel like I’ve finally done it.

Step 1: The original algorithm had an invisible “sensor line” that rode underneath the player, sensing what sort of terrain he was on.  Unfortunately, any time he jumped up into a one-way, his collision would turn on and he’d teleport to the top of it.
Step 2:  I added two more sensor points right around the player’s knees.  Now, only when one of them was in the air, but the foot sensor was on land would it turn collision on.  This time, though, he would sometimes be falling so fast that his sensors wouldn’t register the surface of something, and he’d end up stuck in the block.
Step 3:  I added another sensor line underneath the first one, which solved the falling problem, but now I noticed he wouldn’t pick up on slopes that weren’t very steep.
Step 4:  I changed the placement of the extra sensor line and the sensor points so that the faster he was falling, the further away from the player they’d be looking for information.  But I started seeing some really weird inconsistencies that had something to do with the test for downward motion.
Step 5:  I got rid of the sensor points (which had become sensor boobs in my code) and changed the extra sensor line to be vertical instead of horizontal, so that it started around his knees, and stretched down to a length that was proportional to his speed.  I created a whole new set of subroutines that would calculate an intersection between this line and the surface of the one-way platform.  But now if you’re standing at the edge of something it wouldn’t notice.
Step 6:  I changed the vertical-line-sensor into a vertical rectangle that stretches downward based off of speed, and rearranged some if-statements.  After a couple of minor tweaks to make sure that he wouldn’t flash to a standing animation as he passed upwards through a one-way platform, I think I’ve finally got everything working the way it’s supposed to.
Step 7:  Right before posting this and uploading a new build, I decided to do one more run-through, and noticed that still, about one out of every twenty times, he’d fall right through platforms.  I spent about three more days adding all sorts of visual tests before I decided to just scrap the code I’d been using to detect intersections (that I’d gotten off of a messageboard) and write my own routine.  It worked perfect on the first try.  Lesson Learned: Just suck it up and do it yourself; don’t try and cut corner’s by reusing other people’s code.

So, back to the level redesign.  In the meantime, I’m going to upload a build with all the collision detection debugging still on; I want you guys to play through it and try to break it.  See if you can find any inconsistencies, or anything that would look better differently.  You can’t get across that little water mill (yeah, that’s what that brown box by the white box at the water is supposed to be) because the rest of the level is dreadfully not done yet.

Debug Legend:
Green lines are collision boundaries
Pink lines are intersection calculations to the platform surface
Any failed intersection attempt is shown by a blue line and a cyan rectangle to show where the sensor rectangle was.
Red line at his feet is the original sensor line.
Red lines to the left and right are wall sensors.
Translucent red box is the stretching sensor rectangle.
The player will turn pink when he stands on top of a one-way platform.
The current one-way object being tested turns translucent blue
All slopes are also one-way

It looks messy, but this was the only way I could see exactly what the engine was doing behind the scenes.   Now that I’ve got it all working, I’ll comment it out (because deleting it feels like a surefire way to jinx myself) and continue work on the level redesign, which shouldn’t take me too much longer.