Uncategorized

Hiatus

I haven’t been able to find the time to sit down and work on my program in a while. My work schedule has been just kicking my ass, and trying to coordinate the college stuff at the same time (studying for and taking boat-loads of CLEPs, and applying, and trying to convince the college staff to reply to their emails, let alone actually answer any of my questions) has really cut into the time necessary to work on the game. I need to be able to spend a few days without distractions to get into the groove, otherwise I spend most of my time trying to remember where I was and what I was working on and how I was trying to accomplish whatever feature. Soon, though, my work schedule will get way better, and I only have a few more tests to take before I’ll have gotten as much of the pre-college stuff done as I can.

Say my name

The enemy thing turned out to be more involved than I was anticipating, though not actually because of enemies. I ran into an issue trying to calculate line of sight based off of the collision detection I was using. There’s a tile-layer object that you just fill up with graphics, and set collision polygons for that’s supposed to strreamline level design. However, there’s pretty much no way to detect collisions with it; everything is automatic and happens “behind the scenes.” The other recommended way of doing this is to create little invisible blocks that you overlay a non-collision image. For some reason, all of the collision routines work with that perfectly.
So I had to go through and add extra little objects to everything, and I noticed that I was starting to get a crapload of runtime errors involved with having more than one object with the same name.
What I was doing was naming everything collide-able “solid,” “ladder,” or “oneway,” and testing to find the name of the object the player hit. Names aren’t really meant for that, so instead I ended up creating different classes for the different types of blocks.
I then spent a couple hours tearing my hair out over trying to figure out how to test for the class.
GetClassName returns t2DSceneObject. Well no shit, but it’s a member of multiple classes. How do I test that? I dug through the messageboards until I found someone from 2006 who was trying to do the exact same thing as me. Turns out the sub-classes are actually called ClassNameSpaces.
So now I’m essentially back to square one, with all of the collisions working the way that they’re supposed to. Visually, the game doesn’t seem to operate any different than before, which is kind of discouraging, but at least now it’s set up to make enemy implementation a little easier. Of course, I’m about to spend a week away from my “second job,” and I decided not to try and bring anything with me. Aside from the ridiculous amount of work it would take to get my laptop set back up with Windows and get everything transferred back over at the last minute, I don’t really want the distraction. I like sitting at my desk and being able to put myself in the right mindset to get stuff done.

Making Enemies

I had a duty shift at work yesterday, so I couldn’t work on coding at all, but I spent a lot of time mentally working through methods for ramps and ladders and talking it over with some of my nerdier coworkers. I came home today and immediately sat down at the computer to put everything into motion (pun fully intended).  It took some finagling, and I’m still not 100% satisfied with the movement style of the dude walking up a ramp, but I managed to get ramps, ladders, and one way platforms finished off in just a few hours.  I tested everything out, and I’m satisfied that collision detection is about as done as it’s going to get.  Now it’s time to start designing some enemy behaviors.  I think I might try and translate some of my Python source code over from my deployment project; I had all of the Feudal Japan level bad guys fully programmed, and while the physics are going to be a little different, I can at least use it as a guideline.  Of course, having worked all day yesterday, I’m ridiculously tired, though I should have pretty much all of tomorrow to work on things.  I should probably try and pace myself to make sure I don’t get burned out too quickly.  There’s also a tornado watch in effect right now, and I can hear thunder off in the distance.  I’ve got a bad habit of not saving my work often enough, and perhaps I’d be better off taking a nap for now and not tempting fate.

Concept art for final boss- stage 3

Test EXE

Fixed the annoying rocket-ladder with a workaround; I found someone else who had the same problem as me, but no help from the forum. So I scrapped the trigger object I was using as a ladder and instead created an invisible block with no physics or collisions and placed it on top of the ladder graphic. Each frame I check to see if the guy is inside the invisible box, and if he is, it applies the ladder behavior. Problem solved.
Now I’m working on ramps; the way I’m doing collision detection doesn’t quite account for it, and so he falls up and down them instead of running up and down them. Pretty sure I can find a way to fix this without too much work, but I’m starting to get a little burned out; the rocket-ladder thing took me most of the last 5 hours.
I’m trying out Google Drive as a place to keep my EXEs uploaded. I’ve started updating the box to the right that shows when the last one was updated, and includes a link to the latest version. Let me know if anyone has any issues downloading it; I’ve never tried Google Drive before.

Rocket ladders

Learning to use TorqueScript has taken more effort than I initially thought. I’d assumed that it would be essentially pure C# with some added global variabels and built-in classes, but it turns out that there’s a lot more to it than that. It’s also been surprisingly difficult to find basic reference material. I’ve been chasing down a bug for hours now, and it turns out that you can’t compare strings using the usual “==” operator; instead there’s a special operator for that, $=. It’s also taken me a while to get back into the hang of a C-based language instead of Python. If I had a dollar for every semicolon I’ve left out since I started working in this language, I could afford a “you’ve got too much money” discharge from the Navy. And if doesn’t help that the compiler doesn’t catch errors; it’ll go right ahead and run anyways, just ignoring any statements that don’t make sense to it. It took me almost three days to figure out how to bring up the error-reporting console.
Long-story short, though, I’m finally starting to get the hang of it. I grabbed some sprites off of David Hellman‘s (the guy that did the artwork for Braid) site, just for something to use. Adding in new animations revealed a couple issues that weren’t too hard to fix, and it’s much more satisfying now that I have visible proof of progress instead of just the understanding that “It’ll look cool somewhere down the road, but it’s doing what it’s supposed to now.”
I’ve got collision detection down with the exception of ladders. I’m not entirely satisfied with the way it handles what happens once you’ve climbed to the top. More importantly, whenever you jump onto a ladder, it propels you skyward like a little rocket launcher. I figured that it had something to do with the way I turn off physics when you get on a ladder and turn it back on when you leave, but I’ve added a statement that displays a message every time the physics status changes, and I’m wondering if there isn’t something else going on in the background that just happens to look like my ladder-physics. I’ll get it narrowed down eventually. After that, I need to start working on one-way platforms (which I can probably use to fix my at-the-top-of-the-ladder issues) and then start working on enemies.
Lots of work to do, but it feels good to be back in the groove.

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.