Update: Long Overdue

Shortly after the last entry, my laptop went up in metaphorical flames. It wouldn’t boot at all, and wouldn’t recognize the windows boot disc. Something was wrong with the hard drive, and the only thing I could do was boot to Ubuntu and reformat the entire thing. I did manage to save the most recent backup of everything, but the event forced me to really think about how I’d programmed everything, and I came away from it wanting a redesign. I mean, my level was a text file full of 1s and 0s! There’s nothing efficient about that.
So I took some time off from it; numerous underways, spending time getting ready for college, moving in to a new apartment, relaxing after deployment. Last week I found myself describing the game to someone, and it got me all excited again. I wanted to keep working at it, so I took another look through my options.
When I first started, I attempted everything using Adobe Flash and ActionScript. Very quickly the entire thing bogged down; ActionScript just was not meant for something of that magnitude.
Next I tried Construct by Scirra. I made a pretty decent amount of progress off of that, and a lot of the earlier posts on here all refer to that version. However, it was a little too simplistic, and the actions weren’t customizable enough for my needs.
I spent deployment learning Python and using the Pygame library. In the end, this probably would have worked fine, but it would have required a redesign simply because of the way I initially created the framework.
So now I’m working with Torque 2D, which is the engine And Yet It Moves was created with. It combines a level editor with a physics/collision engine, and scripting based off of C# for everything else. I was really hoping that the physics engine would do most of the collision detection for me, but I’ve been running into issues, and I’m getting super frustrated. Why is it that collision detection is always the hardest part of everything I program? There are a few things in Torque that are specially designed for it:
PickLine/PickPoint are supposed to return a list of all objects that intersect the given line (or contain the given point) but I’m having issues with using that with image maps, and testing to make sure that the object returned isn’t something that the player should be able to walk over (i.e. a background image).
CastCollision sounded perfect; you pass it a time, and it looks into the future and tells you if the parent object will experience any collisions within that time. As you can imagine, this is pretty processing-intensive, and it wasn’t reacting the way I hoped.
So for now, I’m sticking with just the built-in physics, and adding actions to the onCollision callback. I’ve made a decent amount of progress over the past couple days, and I’m confident that I’ll have it working the way I want it soon.
In the meantime I’ve been looking back over the plot and storyline, and adding in some extra dream sequences and rewriting the way I want the waking sequences to go. I think it’ll be a more natural flow of events, and will feel less like something a third grader made.
Once I have something worth showing, I’ll get back into the habit of uploading EXEs. Until then, I’ll leave you with a piece of my loading screen.