Objectification

Yesterday was a sick day, and right up until fever broke over me like the Persian Hordes broke over the 300 Spartans, I actually got some work done. Then I collapsed, grabbed a small stuffed toy I refer to as The Christmas Moose and made with the nap time.
Today, I'm still a vector of disease, like that monkey from Outbreak (no, I'm not terrified), but I can stand up for longer than a few minutes at a time.
The first thing is that I can now declare, The Necromancer Saga, is at an end. The final bits of code that didn't work, namely that great, big, and downright sexy bit of code that made animated objects work, works again. It saves, it loads, it makes with the candles.
Although, I really, really should learn to comment stuff, especially when it's complicated. It took me 30 minutes of mind bending, Divinci-esque decoding to figure out what in the nine hells was going on, followed by 15 minutes of making it work again.
I went all night-night before I could fix the array boundary bug. What's that? Basically, you can build an array, or as I refer to them, a Table. It has columns and rows (but could have n dimensions - it's just really uncommon, because it's next to impossible to visualize a 5 dimensional anything) and you put things into them. The trick is, you have to tell the computer how big the table's dimensions are. So for the objects, I use the rows to put data - namely the kind of animation it is, and how many frames it has, and the little pictures. There are up to 30 cells that I've made available for this system. (but I'll probably end up adding more by request). The bug occurs when the screen switches and new items appear. The loop doesn't want to reset properly, so it goes looking for animation frame, say 70. Since it doesn't exist, it falls down.
I can fix that by changing the orders of stuff, which I'm hesitant to do since it does work. But I may not have a choice, I'll find out soon enough.

-In level building, I'm into actually building The Tower level now. I've gotten a map that I'm happy with and in an odd way, the levels are builing really fast. The basic thing is that, the level is designed to be wicked hard, and be going for realism in some way. This leads to really minimal layouts on each screen. So in say, the Prison, the puzzle solutions required only 1 or 2 moves to solve. Now, I can create a chain of 4 moves and threaten death for failure.
In any event, I'm shooting to have that done in the next couple of days. there's still a lot of coding that needs doing. Plus installation of assets and gods know what else.

-Oh, the Walls are cut. Well, they're blued. I may get around to doing them in the future, but for IGF, I'd rather have the time devoted to the other levels.

A Cast of Thousands

The map of The Tower is almost done, well, the outside anyway. Considering that's the trickiest part of the thing, I'll count that as a minor achievement, a small win. The issue I found myself with, is the basic idea that The Tower, unlike the other things which are basically interiors, is mostly exterior. The form of it has to follow the function of it. Aborto, the first try, suffered because even though the platforming may have functioned, it looked like something built by crazys and drunks, using non-euclidean geometry to appease their great dead gods. For the first time, it has to not just function but be pleasing to stare at, and if the opportunity forces the issue, see momentarily as it rushes on by during an extended fall.
But just drawing out on a map isn't quite enough, it still has to play. So now while tweaking I have to consider things like, "Does this make it better?" "Does this make it ugly?" "What in the name of Odin's crab infested beard is that anyway?"
At least the inside is, well, not outside. I can make the interior sections twist and weave in ways that make no sense since the outside of them will be filled in by the player's imagination.
"Why there's no stairs here because this is a large open air spot. There's stairs in the back, but there're lots of guards and things, so we're avoiding that area."

-Anyway, on to the titles (cue music or something. Here, hum a tune I'll wait). The Artist has mastered the old, and wonderful maxim of Under Promise and Over Deliver. Original time estimate said 20-30 hours per model. Actually closer to 2 or 3. So now we have Guards and Fencers to add to the Knights and Skeletons. In effect, we have every kind of basic enemy modeled now. After looking at them for a while, I've decided that I'm quite fold of the Fencer's and see what The Artist was going for. He summed it up thus, "They're fast and vicious and a little bit dandy."
There's a little bit in the combat code that makes throws happen. There is also a little bit of space set aside for The Thief to do a finisher when he defeats an enemy. Fencers have, and will, get a quick boot to the junk using this system in a perfect world. With their little musketeer hats and their odd little smug look, I can have our hero kick them for days.
In any event, hypothetically, the enemy modeling could be done. The bosses, in something resembling wisdom, are all variants of the basic enemies and could be color swapped. Of course that seems to be an option that nobody really likes, but always a possibility nonetheless.
So in this, our second Seldon Crisis, I'm starting to get an odd feeling again, the feeling that, maybe, just maybe, we'll get through this.

EDIT : Just got an email from The Artist who read this. Apparently, I was wrong about something.
"Btw you lie! Each model is around a full days work. You dont appreciate my sleepless nights of toil. (Sniffle)"

Clocking Out

Hmm, 3 weeks left, not including a great big assed section I'll refer to as "Post Production" where I make it all work and I polish the game like a pair of jackboots. That really is cutting it close. As the designer, I need to actually be all done quicker still, since art takes time. The sooner I get something all done the sooner the Team can get cracking.
So, having had a look at the schedule, I need to have The Tower finished by the end of the week. That's not going to be easy, but it is needed, so I can get it tested thoroughly and then made all pretty.
What it means in less uncertain terms, is that the Clock portion of the Tower, has got to go. The scripting, design, building and re-building would simply take too much time. I estimate it would take at least a week. That's time I do not have to give away. I like the idea, and clearly was in love with it, but now I feel the time has come for us to part, and for me to start seeing other Levels in more than a cursory way. I could continue this analogy, but I feel it may turn vulgar with Game Dev Double Entendre. Possibly involving the terms "Joystick" and/or "Elbow Deep."

In any event, I've got a new and workable map of the Tower level wherein the player goes outside, inside, outside, inside, outside again. The only oddity about the design, which I may change, is that the outside is continuous. So if you miss a jump at the top, you will fall 9 screens worth before the ground says "Ola." Provided of course nothing else is hit en route to terra firma. Either way, as much as I like watching the character flail around and go kersplat, that seems like a bit of overkill (ha! pun!). Kind of a big, "Ha Ha, you have failed. Now enjoy your great big fail for a while longer. Just a little more, and...okay now try again please."
I may only build a couple of screens below the play areas and see how that goes. So one can get the sense of deja scru (that's the feeling that you've done something before, and it turned out badly) without going through the whole rigmarole of dropping for 10 seconds. It'll probably also help pacing. I'll see what I decide when I actually do it.

- Oh, and I don't think I've mentioned it, but I've gotten great new music from our Composer. We've gotten a new Prison Theme, which is whimsical and adorable - like what prison in Disneyland would sound like if it had a soundtrack. We also have a Main Title, and a basic theme for The Guard Captain. I'll put them up probably.

- Speaking of Guards, check it out. That's what the guards will look like more or less. The details are still in the process of, but I think those are cool. Really quite so. I could kick those off of platforms for hours.

Crumple and Toss

I got to doing the Tower level yesterday. When I build a level, I generally start with a big blank page and do a quick sketch of the shape of the level if it has outer bounds. The Castle had the idea of a large central area and smaller towers for example. Then I go in and figure out how to connect the levels together, so I add little lines that show how the whole thing will connect. Once that's done I draw out my grid into my notebook with graph paper in it and then go through the process of making my lines match on both maps.
Then, the real process starts with this basic layout finished. I've found that just going into ThiefEd all willy and/or nilly is a great way to end up with a long meandering level that kind of sucks. So with my layout finished I start drawing out each little screen. Knowing how the screens connect gives me a goal to work towards while providing focus to the puzzles themselves. Say if a room has the exit at the top and the player enters from the left, I have to design a puzzle that moves in that direction. So that's basically how that works for me.
So yesterday I got into building The Tower, and was about halfway up the structure when I took a metaphorical step back (since I was sitting on my couch at the time) and realized that the level I had spent an hour working on, sucked and looked like a monkey designed it using his bloated blue ass to hold the crayon. I did as the title would lead you to believe.

However, the exercise wasn't all worthless, for now I have a concept for the level itself. The first try was built around the idea that the character spends a lot of time on the outside of the Tower, and that doesn't work as well as you'd think it would. Towers, and masonry in general, tend to be pretty smooth, which leads to some really lame platforming. So the conceit of the previous try was to add turrets. Click the link and you'll see (assuming you've read this, which I assume nobody does) I'm talking (?) about the kind on castles and things, not the kind on tanks.
In any event the first abortion made too liberal a use of them and when looked at from a, "Could this big pile of shite exist in real life?" kind of way, the whole thing fell apart under a pile of its own overindulgent crapulence.
I think I found the problem though. It's not that the outside of the Tower can't be interesting, it just can't be all. From a design standpoint I need to force the player onto the outside from within. I mean, nobody really wants to be on the outside of a bloody building, regardless of their acrobatic proclivities. So I'm thinking that the player will go inside and then outside of The Tower several times, traveling within and avoiding traps and enemies, before being forced outside by blocked passages and having to find an alternate (and likely - very dangerous) route. Drawing this thing out will be tricky, but I think the concept is sound. I'll find out I guess.

- In not development news, I got my head into some Galactic Civilizations 2. I thought I would go ahead and load the demo and screw around a bit and see what I could see. So I picked a race and named my planet (Terra Prime by the way) and got exploring and sending out little colony ships. It was about then that I wandering into the "Build Awesome Ships" mode, and started making the slickest hot rod of a colony ship ever launched into digital space.
I'm enamored with it. It's everything Master of Orion 3 was supposed to be and failed doing. I don't understand the exclusion of multiplayer, even hotseat would be great. I'll wander interwebs and see if somebody put a patch together. I mean, It's a turn based 4X strategy game, how hard is multiplayer?
Once I had expanded my little empire to the far reaches of the admittedly small galaxy (really? 9 systems does not a galaxy make) with a collection of colony ships built the appeared to have been built by Aston Martin, I realized that 2 hours were gone and I felt guilty about it.
I don't know why. I mean, I still do. Those were 2 hours I could and probably should have devoted to the Greater Good, and I played GalCiv2 instead. It's okay, I can hold off buying or playing it until I'm done here. But November, post IGF, oh that's all booked now.

Changing Gears

The Castle, is finished. Well, at least for my part it's done, more or less. Testing is currently ongoing and I'm sure I'll receive an email in the next couple of days with either a giant list of broken things, parts that are confusing and parts that are stupid, requiring me to go back in at some point and make changes. The work is finished though. Minor changes to an already built thing are not the same as building an all new thing, and I like the level enough to not want to rip it down and start anew. Unlike the last level, I''ve gotten no part of that makes me think that I should crumple and toss it.
It plays nice. Parts are ruthlessly hard, but at the almost end of the game I can do that without regret. Leave off the proverbial kids gloves and throw on the ones with nickels in the knuckles. Enemies need sticking in, but it's otherwise just dandy. Oh, and orange now.
So nows I gets to move on to the next level, The Tower. Going back to a previous idea, each stage is basically designed to create a new kind of gameplay experience to test the player. The Castle has traps, the Cliffs are scripted events and The Tower is designed around flexible geometries.
Let me explain that one so I can wrap my head around it. Basically, I want parts of it to move around, so the idea of the screen, the solution to it and the dangers inherit to it are the same thing. The example that comes to mind is of a wall that moves back and forth, with the exit at the top. I want to force the player to wall jump up the wall before the wall is able to crush them. Then I want to link those kinds of puzzles together.
Now, the question quickly became, why in Odin's name would a renaissance era tower have anything even remotley resembling that kind of idiocy? So I put a clock into it, a big one. It's a common game conceipt - having a tower have a clock in it, and like common game conceipts I love to turn them over and violate them in the bestest ways ever. So, the solution to escaping the clock, will be to destroy it. I've played through clocks before, with their spinning gears and there little chains, but I've never had the opportunity to outright destroy one before.
Of course, that brings me to the central problem that I face, the central problem that has kept the notebook page clear save for the "Tower" label at the top - I have to build puzzles that work not just forwards and backwards, but while they are failing.
However, there's another issue altogether, the clock isn't the entire level, it's a part of a larger whole. As it stands, there's 3 parts to Tower broken into 2 chapters. The first is the exterior and interior portions, in effect, a place to put all of the trap puzzles and platforming puzzles that were too damn hard to put into the Cliff or Castle levels. The problem I'm having is, how do I do more of the same, without it seeming like I'm doing exactly that? Or does forcing a player to suddenly change tactics and methods on the fly make the experience different? I really wish I knew the answers to these questions before I went in and used the hours up. Hours I find myself with fewer of with every passing, well, hour.
Methinks I need to get to work with a pencil and see what I can see.

- While I was doing some level finishing, I had an idea based on a hack. Previously, I found that I could do some stuff with image buffers and things like that, mostly for saving. Yesterday I figured out if I draw everything except the GUI onto an image, I can screw with that image. So I went in and worked out how to do a shaking effect, by drawing that image and randomly adding or subtracting a small amount to the X and/or Y position of where the screen is drawn. So now cave in and wall collapses can have wiggle to them. Wiggle that looks cool but doesn't do a damn thing to the gameplay underneath. Wiggle I can live with happily. Oh, and I can toggle it, which is important. Although I have noticed that it makes some stuff a little harder, but I was testing it in the Castle Level, you know, with all those traps.
In any event, I think I could conceviably use this trick to do some creative shite with mask colors and overlay effects. Maybe transitions and stuff. Later anyway, I don't have the time for either R or D right now.

- If you'll direct your eyes over yonder => you'll see that more stuff is now oranged and now blue. The blue stuff is things that need doing eventually, but not today. These are things that I can do after 11-1 if I want. Hours that I can use today for other stuff.
The other things are in the Art section. We have another posting by The Background Artist / Modeler with some stuff from the Warehouse level. He says it's not quite done yet (to me and in the blog) but if he needed to the game could ship with that art in it, so that's a quasi-done. I don't want to mark it all orange and have it not be true, but it's done enough I suppose to have some kind of coloring, so I put Preliminary Art next to them. If all the art is marked at Preliminary Art and orange, I'll be a happy panda.

Turning the Page

I spent yesterday working away, answering email and generally trying to steer a great big project ship with neither oars, rudders or a combination thereof towards something that could be considered the end. For my part I've debugged the bejeezus out of the castle level and have like 4 traps left to install, none of them tricky. I mean, once you've synched up spikes to they trigger in a wave, it puts stupid things like wall bladed in perspective.
What managed to eat most of my time yesterday was a bug I discovered. Basically If the player is hurt and they fall down, they stay in the Hurt Behaviour until they hit the ground, regardless of whether or not they should be doing something else, like flailing about as the ground rushes up to bid you adieu.
In trying to fix that, I first made it worse. Since it was a trap that was doing it (a ceiling mounted circular saw in this case) I tried modifying the code so that once you fell a certain distance you would fall instead of act all hurt. Traps only work if the player isn't hurt though, so once being hurt is turned off, traps can, and will do damage again. The grisly outcome of that was that the blade would grab the character and push him upwards into itself, while dragging him across the ceiling. It was, graphic, in a cartoon kind of way. So that didn't work.
The solution I eventually figured out was adding something into the physics algorithm, so that once a certain distance has been had, the player is falling instead. Thankfully this amount is well outside the area when the trap probably was in the first place.


- Having had some quality time with the traps I've discovered a couple of things. First of all, Hard mode is, well, really fuggin's hard. A single misstep when traps are involved is enough to make for a really short trip. I get killed and they're my traps. Having a thought about it, Perfect Mode is going to be tough, really tough.
Hard is providing a great way to test the level though. If I can beat a level on Hard, then the regular folks should be able to do it on Easy or Normal, provided they don't fall of of things.
The other thing is that they need sound, or at least I need sound for them. In other types of games with traps from Crazy Eddie's Giant Video Game Trap and Crate Emporium I get by via aural (oh, don't be a perv) cues. I listen for the rhythm of the puzzle and go accordingly. Playing on mute makes them harder. Then again, if I can beat them on Hard, with instant death failures, and muted, it may mean the game is almost playable.


- Which brings me to the titles. I've been building some front end stuff so the menus and stuff look like they're in a book. To that end I've worked out how to do a dynamic page turn with art on it. Basically, the previous incarnation of the page turn (other than being on every screen - which killed pacing and was stupid) had blank pages and art would appear as if by magic at the end of the animation.
If I use an Image Buffer, it isn't a problem. An image buffer is basically a blank scrap of screen. The other kind is a screen buffer. Basically, a screen buffer draws things on the screen. An image buffer draws things on an image, that I can call something or do stuff with. The screen capture functions use this principal to take screen shots.
I can also make them different sizes, which is how the page turn is going to jive. In effect, I can make an image that is smaller than the screen and draw things on it. I can then overlay that particular image on top of the page turning animation. With a couple of tricks, I'm confident I can get them lined up and it'll look like the art is on the pages as they turn, and the art on the next page is there to. I think that will be, um, awesome. Provided I can get it working of course.

-Finally, if one were to go here:
http://13meatmonkeys.blogspot.com/2009/09/10901.html
they could see what The Prison is going to look like eventually. Now imagine that the fire is animated and the pink stuff (which is a mask by the way and would be ignored by the engine I think) is a window into other great looking stuff. I think it's great. Check it out and send love.

Chasing Portal

I was having a chat the other day, talking about the IGF winners of previous years. Talked about Braid and Alien Hominid, and eventually Narbacular Drop came up. When the question, "What's that?" came whizzing back my way I replied with, "It was put together by some students. They were all in turn hired by Valve and polished their game up. You'd know it as Portal."
The shock on their face almost said it all, their words said the rest, "You have to beat Portal?""Well, I guess." I replied. "Or at least, I would have 3 years ago."
But that's really not the point though. I'm not chasing Portal and I never was. I'm making a game that could have been on the SNES. I'm chasing the games I remember playing once, with all of the polish and gloss that nostalgia has added over the intervening years. The game that I'm out to make, the game that I'm on my way to finishing, is a game that invokes all of that. It's something that takes on the challenge of perception, the way games were in the never-were Before Times. The way they were in the good old days that are only remembered and were never lived, a relic of a time that should have been.If only instead I had the luxury of simply trying to beat Portal.

- For the actual game, I'm 50% of the way through installing all the traps. It's taking just about the right amount of time. The simplicity of the code itself is in harsh contrast to the highly technical and iterative nature of making the damn things work right. In effect, it takes 10 seconds to put a trap in the game and 5 minutes to make it interesting, fair, and if there is more than 1 in the screen, synch up. I'm getting quicker though, and now I get to copy and paste code to my heart's deepest content. I should have this cranked out later today and get myself on to The Tower.

By the way, before I forget, these are going to be the Chapter Titles present in the game itself. A perceptive reader (hmm, riiight...) will notice that I've repurposed some Development Diary entries for names, since they're specific and almost always slightly sarcastic. The parenthesised words are obviously there for reference, and the little a-holes show that I've built them already. Odds are that Chapter 6 may be cut, but here's what they could be.

Chapter 1 : The Great Escape (The Prison*)
Chapter 2 : Guards! Guards! (The Warehouse*)
Chapter 3 : Buried Alive (The Cavern*)
Chapter 4 : Crypt Raider (The Crypt*)
Chapter 5 : Unsteady Ground (The Cliffs*)
Chapter 6 : A Hole in The Wall (The Walls)
Chapter 7 : Castle Crasher (The Castle - duh*)
Chapter 8 : Chasing the Sun (The Tower)
Chapter 9 : A Rose By Another Name (The Royal Chambers)

Time Keeps on Slipping

Had a team meeting on Friday, and two things became quickly and readily apparent. The first is that the art in the game is going to be bloody brilliant. I had mentioned at one point it would be cool to have some of the art look as if it's in an old book, but gave the final say to The Background Artist (link to his blog hither => be sure to send love). In any event he took that basic idea and ran with it, the art as it is now is better than anything I'd hoped for and more importantly, it's fuggin' distinctive. The art looks like it's actually coming forth from the pages themselves, with 4th wall shattering concepts like page notations, margin drawings, and in the case of the Cliff levels, page destruction. I say you put the level art in TTT against any platformer and ours will be prettier. I seriously could not be happier.
Which brings me to the second thing that has become apparent, a month is not a lot of time at all to get it done. My previous good cheer about the prospects of the project were based soley on my own progress, my hill. I can see the top of my hill, but that accounts for less than dick if the collective team can't finish. The saying is correct, there is no "I" in team, but you can rearrange the letters and get meat, as in dead meat. Methinks that my own photoshop skills are going to be summoned again.
The issue is that everything will take forever to do. Modeling characters, even tiny ones like the game needs, is 20 hours. Game art, even with a streamlined pipeline, is 30-40 hours per stage. That big assed list over yonder => is going to take a lot of hours to do. Hours that we, as a team, are in short supply of once again. Part of me begins to think that we lack the required hours, that it can't be done. The other part of me laughs darkly. After 2 years, this is it. This is, as they say, for all the marbles. It's going to be tough, but then again, it was always going to be.

- In dev news The Castle is pretty much finished. I just need to install the traps that I've coded (and made animations for) and we're good to go. Next I have to get the Tower drawn up and into the Engine. I should have both by the end of the week.

- In programming I fixed a shit stain of a bug. My stairs, my wonderful stairs, had an issue wherein if you jumped on them it would trigger a climbing animation inside the stairs, which looked really stupid and amateur (yes I know we technically are amateurs, but that doesn't mean the game should look that way). The issue had to do with ground detection. The engine runs a loop and runs through it in order, starting with rectangle number 1. The issue is that depending on how the level is constructed the character may interact with a rectangle in the wrong order, which cuts out the rest (a previous solution to a bug that killed the player - a marked improvement by the way). Since I couldn't rewrite the loop to do the collision in a different order, I had to do something else. So, I built a different loop that only detects the floor and passes a variable to the rest of the collision loop. So now if the player grabs a ledge and they're touching the floor, it ignores the ledge grab and keeps the player firmly on Terra firma.

Castle Crasher

The Castle, is in the bag as it were. Over the weekend I got the whole thing finally laid out in ThiefEd. Yesterday I got all the doors working and made placeholder animations (which are decent enough to pass muster should time become more of a factor) for the traps. I also built an elevator, which actually serves a gameplay purpose.
Now I just need to go through and get all the traps installed. Thankfully I did most of the scripting as I built, so I don't have to go back in again like during The Cliff Saga. The traps will be interesting though, since they require timing, which implies a lot of playtesting as I go. Not to mention the fact that almost every screen has traps in it, sometimes several. I don't expect it to go quickly, but I may surprise myself.
In any event I'm already building The Tower in my head, using the leftover puzzles that I thought of as I built The Castle.

- Something that has surprised me further, even though it shouldn't, is ThiefEd. It's bloody bulletproof. For some basic reason, it just works, all the time, every time. I don't even think about it. I just boot it up, open a screen and get to work. There is no magic incantation, it requires no sacrifice, it demands neither love nor tribute. It just is. In the next post-mortem (the post-post mortem, like a zombie autopsy) I'm going have to put that squarely in the Good column.

- If you read this (although I think only I do) you'll notice that The Prison, is done and oranged. All done, at least from my perspective. Me and The Tester have decided that it runs great, works perfectly and we wouldn't change a thing about it. I call that polished and hence call it finished.

Blade Runner

Yesterday I didn't do much in the way of level building, but I've gotten 2 of the 3 kinds of traps installed and the code designed for the third. So now there are functions, that work even, for both the spike traps and spinning blades. The one oddity of them is that spikes. You see, they hurt like hell. I mean if you are in the middle of spikes and get slammed, you're boned like a chicken on Iron Chef, which is to say quickly and possibly deliciously. But I digress, basically unlike enemies which deal damage at a very specific time, the traps are an area of pain. So when a player is caught in said area, they experience, um, pain, to the tune of about 15 HP per second. Granted, that's just a little on the side of overkill, but when the alternative is quality reaper time, then 15 HP per second as the price of failure is a bargain.
So that works, and the spinning blades work too. They basically work just like the spikes, except with this bit:

If Ducking = 0

So this only triggers a pain reaction (a pun!) if the player is silly enough to stand up. It doesn't suffer from the same kind of cuteness as the Spikes, and only hits once per cycle though.
While I was fiddling I came across a trick that I programmed in at one point. Basically, if the player Dashes while they're ducking, they roll. It's just like a dash, but you know, low to the ground. I considered hacking it out, but it does give me a way to quickly navigate the neck blade areas of the map, so I say it stays. Thanks previous me.

In any event, the code is a lot easier to work with now. I can summon up entire rooms full of traps with single lines like this:

SpikeTrap (100,200,100,60,100,150)
Or, in something bordering on English:
SpikeTrap(X Position, Y Position, Width, Height, Trigger On Frame, Trigger Off Frame)

...and that's it. That is all that goes into the scripting file for the trap itself. I'm quite happy with it.

- I've gotten the basics of the difficulty setting in now. I built a function called Trap Damage that either deals damage (like it says) or makes with the dooms. It knows which to to based on the difficulty that is selected. So now, the settings can be Easy, Normal, Hard and Perfect. Those are further broken down by how much damage is dealt or received, how blocking works, how trap damage is dealt and whether or not you can continue. All of these are very minor tweaks, so I still want them. So, to break it down, it should go like this:

Easy : Double damage to enemies, Damage Received at 75%, Auto-High Block, Start with 5 Lives
Normal : Normal Damage, 3 Lives
Hard : Enemy Damage 75%, Double Damage Received, Lethal Traps, 3 Lives
Perfect : Enemy Damage 75%, Double Damage Received, Lethal Traps, 1 Life, No Continues.

Looking at that, I think I need to disable Perfect Mode when the player uses the Chapter Select that'll be installed eventually. Starting at the last chapter on Perfect kind of ruins the point, no?

-Finally I worked out the mechanics of the hardest kind of trap, the Saws. Like I think I said previously, they are spinning blades that run across the ground get to the end and turn around. For the life of me I bashed on them, trying to figure out a way to have them without adding more variables (like how moving platforms work). The issue I was having was having the bloody thing know which way it was going. That would require a variable of some kind. Now add that to the fact that I have designs for 3 of these running concurrently and the whole thing began to collapse under the heavy weight of it own crapulence.
Until I figured it out of course. The issue isn't turning a blade around, it's all about turning it off. So when I started to consider that the solution presented itself. Basically, a blade only goes in one direction and has a turn on and turn off time like the spike traps ^. Then, I just stagger them. So one goes in a direction for a certain amount of time, shuts off and a different one turns on and goes the other way. If they're lined up right it's seamless. If I tie the whole thing to the underlying Trap Controller (which counts up to 200 and resets - giving a standardized way to control trap timing) when the cycle comes around the traps are all reset again.
This system also gives me the ability to screw the timing really bad/good. So I can have a blade go slower in one direction and fast in the other, and other messed up things like that. So yay. Good day of work I think.

Castle Exterminator

Currently I'm about 60% of the way done in getting the Castle built and in the proverbial "Can" that movie people are always blathering on about. It seems to play pretty well, but at this point it's a little hard to tell since none of the doors work and the traps exist only as a figment of my caffeine addled brain meat. Which is taking a lot longer than I would have thought. Basically, I always have to plan around the traps that aren't there yet. Nothing that's too big a deal, and since I've whined about this already I won't again.

An example comes to mind regarding a new aspect though. There is a level where you hop down from a platform and there is (going to be) a buzzsaw running to the left and right. The player has to time the jump to hop down, run and the hop up to the relative safety of a handhold. I must've tweaked that bloody thing a dozen times. The Thief would hop down and get stunned by the drop, minor as it is (who's bright idea was that anyway?). Usually, the stun is a small inconvenience, something I make the attempt to avoid causing since I have plans to include a Speed Running mode later. In any event, in the case of the blade puzzle, the stun could be lethal. The player hops down and gets stunned and...dead. Now imagine you're playing on Perfect mode and you can't continue. Now further imagine going out to buy a new controller after that happens. So yeah, lots of tweaking to accommodate the as yet unseen.

- When I do the puzzles, I force myself to play as if the traps are all there. So I duck when I need to and I jump when I feel I should. Consequently, I'm finding that there are a lot of odd control combinations that I hadn't come across before, and odd things that happen as a result. One puzzle has some of those spinning blade traps that you have to duck under, then wall jump out when the time is right. The problem is that the system was somehow holding onto the Down arrow in some kind of hidden key queue (that's really fun to say! Everybody now! {Really? Everybody?}). So when you jumped onto the wall, you slipped off like, oh I don't know, add your own prophylactic joke here. So that had to go.
It turns out the solution was actually to insert a bug into it. You see, once upon a time I beat on the code so double jumps would work on a single key. The issue was that once a key was looked at, it was forgotten by the system. So what I did was add a quick bit of code to the jumping function. Code that does something by doing nothing:

If KeyHit(DownArrow)
EndIf

If you've seen other code snippets you'll know that stuff usually goes in between the If and the EndIf. Here, there is actually nothing. However, by the very act of asking about it, it clears just that key. So now the player can duck and immediately jump onto a wall with neither fuss nor muss.
The same thing worked on correcting a bug I called "The Ritalin Thief." Sometimes, for whatever reason, The Thief would dash off the wall as soon as he hit. Usually, this would end abruptly when physics happened and the ground rushed up to say "bonjour". It seemed that even though the Dash Bar was empty, the Alt Key press was still being summoned up and saved. So, once the wall was hit, the Dash was triggered and, as Freddy Mercury would say, another one bit the dust. So I went in and added this to the Jumping code:

If KeyHit(AltKey) and DashBar < 100

Same as above, but with the addition of the Dash Bar query. Now dashes still work while jumping and no stupid wall bug.

- I was looking at that great big list over there => and I'm feeling something incredibly dangerous for the first time on the project. I think I'm feeling hopeful. I can see the end, I know what's left to do and I know how to get there from here. I'm almost home.
At least, I think I am. The stuff that I need to do is certainly doable. Were I to bust ass I could get this knocked out in 2 weeks, probably less. But, it's not just me here, and it hasn't been for a long time. We all have our prospective mountains to climb here, but I still think we can all see the top.

I remain confident.