November 2012

I spent the last week trapped at work, which was extremely conducive to making progress on my game.  After spending the weekend chasing down some last minute bugs (had to redo the parallax scrolling and the entire concept behind activating/deactivating enemies based off of camera position) I’m finally ready to upload another build.  There’s still a random bug I can’t pin down:  every once in a while, the left and/or right images of a dialogue box won’t delete when the dialogue is over.  I can’t reproduce it with any regularity, and I can’t think of any reason that it’s happening.  Whenever I try to make it happen, it’ll work perfectly ten times in a row, and only once I’m playing to test some other feature does it ever crop up.  If anybody sees it, can you tell me what’s going on?  Were you pressing the arrow keys at the time?  Where did you click to end the dialogue?  Which dialogue did it stick at?
I’ll also be spending the next week or so stuck at work, so I foresee finishing up the final boss, and tweaking the level design until I’m satisfied.  Hopefully I’ll get around to starting the top-down engine, too.  Once I finish with that, it’s just a matter of designing each level and enemy behavior before I’ll have a playable prototype.
This is all finally coming together rather nicely.

I’ve made some pretty amazing progress this last week or so, though it’s not as visible as I’d like. I learned how to use particle effects in Torque, and added them to the using-health function. I threw in some burning houses and trees, and was briefly considering reworking the fire in the molotovs, and the psychic effects, but I feel like it’d be more efficient to wait until I get to the applicable levels.
I also discovered that the player’s ability to walk up a slope instead of fly up it like a superhero was completely due to accident. I’m still not entirely sure why that piece of code gave me the results I was looking for, because once I “fixed” it, it didn’t function at all, and I had to essentially redesign the player’s collision detection for the umpteenth time.
Also, I finished the save/checkpoint code, which also required a massive redesign. Instead of using the Torque engine as a level editor, I had to create functions that spawn objects, like health-drinks, enemies, and event-boxes. They each add the object to the level, and then a reference to the object to the applicable checkpoint list. When you load from a checkpoint, you delete everything from that checkpoint list, and then re-add the applicable objects. I ran into some weird issues where it wouldn’t delete some objects, and then I realized that in Torque, you can’t have two different classes of objects defined as custom classes. For example, if I make a class called “solid,” I can’t have both StaticSprites and AnimatedSprites of that class. It explained a lot of other issues I’ve been having, and after lots of renaming, I finally have everything working the way it’s supposed to.
So now, you can pick up Sake bottles by walking over them, and use them with ‘F’ to regain some health. The usual keys control movement (though I’ve added the spacebar as an alternative to ‘W’) and the mouse still aims and swivels the player. If you walk over one of the glowing Yggdrasil trees, it saves your checkpoint, and any time you die, it reloads you there. You can also cheat and use the ‘1’ or ‘2’ keys to load the first or second checkpoints, though I haven’t gotten around to the 3rd one yet. Soon, though.
I’m trying to decide on the ‘stun’ behavior for the pitchfork. The more I use it, the more I’m fine with it the way it is (though maybe dealing a little more damage). Also, I’ve noticed a little animation hiccup when the player jumps up onto something, like jumping up stairs. I can’t reproduce it with any regularity, so I can’t pinpoint what’s causing it. Also, occasionally, the samurai will walk backwards instead of hopping backwards away from the player. I have absolutely no idea why, but it looks intentional, and doesn’t affect gameplay at all.
Next up, I suppose, is to finish the third checkpoint, create the final boss’s actions, and then make the level design the way I want it to end up “for reals.”  I also want to come up with an official name for the game- “Yggdrasil Dream” is just a working title, and it’s too hard to spell and pronounce to work as a good title.  I’m thinking “The Morning After,” “Waking Dream,” “Hypnic Jerk,” or something like that.  Any suggestions?

I guess that last upload had a bunch of bugs in it. I remember shortly after uploading, I caught an error, so I compiled a new build and hurriedly uploaded that one.  I must have been in the middle of some other things, because there was stuff that wasn’t quite finished.  So here’s what I have so far:

Player can die now, though if you press “g” it will toggle god mode.  You won’t see anything, but trust me, it’s there.  If you die, it puts you back at the start of the level.  I’m working on checkpoints now.
The horse-kidnapping thing at the beginning is done, along with the acquisition of the katana as a new weapon.
The samurai’s health is fixed- I guess his health bar wasn’t showing up, and one hit from the katana would kill him before.  All better now.
I got rid of some misleading tiles that made it look like you couldn’t jump to certain spots.  The level will be overhauled after I’m done with the final boss and everything; for now, it’s just a rough idea of what it will look like.

Still to come:
Checkpoints of some sort.
A stun behavior for enemies hit by the pitchfork.
Health things.
Fixing the non-boss enemy attacks.  They only deal damage at the very end of the attack animation, so as long as you’re not standing right in front of them at that point, you’re safe.  Which includes just running right through them.

So, yeah.  I’m getting there.

I’ve got everything finished with the mini-boss.  I spent a while trying to find a sprite I could use since I wasn’t satisfied with the blockiness of a single image with scrolling text.  I think I’m going to end up just using whatever I can find on Google Images for sprites, and once I have a playable prototype of the whole game, I’ll go through and use stupid little hand-drawn animations (traced over the google images if I have to).
I ended up using the sprites from the Gameboy Advance Samurai Jack game for the mini boss, and it actually looks pretty good.

I was tempted to go back and color his robe to match what I had for the dialogue box image, but I feel that that’s more work than what’s really warranted at the moment.  On the agenda now is to work on making a Player Death routine, finishing up all the events and whatnot that go in the level prior to the mini-boss, and some sort of health-replenishment drink.  I haven’t decided if I want them to be something you carry around and use when you want, or just use when you pick them up.  I might play around with both ideas and see which I like better.
I also recently purchased a laptop that will make my stuck-at-work-just-sitting-around-on-my-ass-because-there’s-nothing-to-do time a little more productive.  I used my college-student status to purchase Photoshop CS6 at an ultra-nifty price, which will mean I’m no longer relying on *cough*pirated*cough* software to make my game.  The laptop itself has a solid-state hard drive, and I’m excited to see how that will work out.

Also, since I seem to have gotten into the habit of leaving behind relevant links on each post, I thought I’d point you towards the creator describing the design process behind Dust: An Elysian Tale.  It’s pretty neat, reading over it and drawing parallels between his game and mine.  It’s a little bit of validation, making me feel like I’m on the right track.

http://www.gamasutra.com/view/feature/180520/postmortem_humble_hearts_dust_.php