Week 07

This week:

• fixed dropping-to-ledge-grab code
• prototyped grabbing ledges from mid-air
• prototyped inventory collection
• ported inventory collection into main prototype (kiiiiinda)
• slept an ungodly amount

Turns out the way I spent that “free weekend” was burnt out from a solid month of overwork and too little sleep. I don’t want to be too explicit, but suffice it to say, naps were had.

This week, I benefited from an extra office day by switching a shift at one of my dayjobs with a coworker. So the ledge-grabbing prototype was completed, and I also mocked up the inventory collection. Inventory collection turned out to be considerably easier than ledge-grabbing was, and took less time and fewer brain cells. Only snag was dealing with the Game Maker’s nuances (object_id, instance_id, and id are all different things, and two of them are not what you’d think they are). That took only a quick jaunt through the help document to suss out.

Incorporating climbing and ledge-grabbing into the main game is going to be rather an undertaking, mainly just because it’s tedious and requires rather a lot of new sprite work, so it’s still on a back burner for now. The code for inventory collection has been copied into the main game, but not, y’know, tested. Got sick last week and am also just kind of exhausted, so these tweaks can just sit down and cool their heels for a weekend, please and thank you!

By the way, folks: we’ve passed the halfway point.

Checklist:

• Basic Movement
• Character Switching
• Pushing/Pulling
• Dialogue
• Sentence Line
• Camera
• Climbing
• Collecting Inventory
• Entering/Exiting Rooms
• Using Inventory
• Carrying
• Crawling
• Throwing

Advertisements

Week 06

This week:

• prototyped climbable surfaces
• prototyped ledge-climbing
• prototyped transitioning from climbing to a ledge-climb
• prototyped transitioning from a ledge-climb to standing
• prototyped transitioning from standing to climbing

It was only a matter of time.

To get back in the swing of programming, I front-loaded the easier assignments. But I’m out of easy ones now. Where most of my coding so far has surprised me by taking an hour or less, I spent the better part of a day getting the climbing mechanics working. It’s not so much that any of it’s impossibly hard, merely that the work is pretty mentally taxing and I get tired out by it quickly. Still, I’m generally getting it all working properly, and my first idea still proved to work. I actually feel pretty clever with this one. I’d explain how, but it would involve a lot more words than would be interesting.

As it stands, most of it is working in prototype form. My little red box can reliably switch from walking state to climbing state to ledge-climbing and back to walking on the elevated surface. Which is one of the more complex things I’ve had to code so far. (Reading the Game Maker forums, it’s clear that there’s no simple, agreed-upon system for ledge-grabbing, so I’m rather proud that mine is actually kinda simple, and intuitive, and only a little stupid.) I’m having a few bugs with transitioning from standing on an elevated surface down into a climbing state, but that’s more to do with having the right idea but being too fried to do little tweaks. Fixing that up, and incorporating it all into the main prototype, will have to happen on Monday.

I’ve actually got a (mostly) free weekend ahead, so I might just do some animation for the game if there’s time between the other things I said I’d do with a free weekend.

Checklist:

• Basic Movement
• Character Switching
• Pushing/Pulling
• Dialogue
• Sentence Line
• Camera
• Climbing
• Entering/Exiting Rooms
• Collecting Inventory
• Using Inventory
• Carrying
• Crawling
• Throwing

Week 05

[disclaimer: last week school started up again, and I discovered that trying to do school on top of a schedule with zero wiggle room in it already doesn’t pan out so well; no programming happened on Week 04, so I went ahead and did two systems for Week 05]

This week:

• did some tweaking to the macro-level game code that tracks player characters
• prototyped the sentence line
• incorporated sentence line into main game
• put in camera controls

As tends to be the case, all these systems are integrated in the most dirt-stupid way imaginable. Sentence line: when you get close to an object you can interact with, its name appears above it in big block letters. Camera: the camera tracks along, Mario-style, with whatever character you’ve selected. I know how I want both to work in the future, and even coded them with an eye for how they will function later, but for the purposes of getting the vertical slice functional, we’re going fast and dirty. I’m on track to get all the core systems in place by early November, which will give me about 6 weeks before my self-imposed deadline to polish things.

The character tracking code is one of the things I was leaving to polish later, but doing it up right now was helpful to make both of this week’s systems work. I had trouble with the old prototype in displaying sentence line text when the player was nearby, because it was looking for the player class of objects and got confused when there were more than one of such class in the room. Now I have a global variable that tracks which character is active at a given moment, and the object pays attention to that. A character’s grabbing state is actually a separate object from its walking state, so I added code that makes the global variable recognize which of these two versions of a character is in the room at a given moment (will do similar for other states, like climbing, as they get integrated).

I’m constantly baffled by the fact that every system I try to make is more or less working right off the bat. I did two systems today, and it took an aggregate of about an hour. I’m used to code involving hours of banging my head against the wall, but so far I’ve only been stumped by the smart character switching. I don’t know how much of this is me being a better programmer and how much is me letting a system be imperfect for now, so long as it works. Part of me still worries that the polishing phase is actually going to be a nightmare, as I try to make this stuff not just function, but feel good. I hope by the time I get there my brain starts associating coding with speed instead of stress.

Checklist:

• Basic Movement
• Character Switching
• Pushing/Pulling
• Dialogue
• Sentence Line
• Camera
• Entering/Exiting Rooms
• Collecting Inventory
• Using Inventory
• Climbing
• Carrying
• Crawling
• Throwing

Week 03

This week:

• discovered offline registration on Game Maker had stopped working
• work computer only goes online with ethernet
• work space only has wifi
• fuuuuuuuuuuuuuuuuuuuu
• …
• brought computer home over weekend
• incorporated dialogue prototype into core game
• applied push/pull code to all four characters
• smoothed out a few glitches with movement code

Not sure what’s up with Game Maker, as I’ve had the offline registration file downloaded for months and it’s always worked until now. Suddenly it tells me me on bootup that I need an internet connection to verify my registration. So I go through the offline registration rigamarole, like ya do, and pointing to blacklist.yoyo and saying “it’s right there,” and Game Maker’s all “oh, cool beans, just reboot the program and we’re square. And then it tells me on bootup that I need and internet connection to verify my registration…

If Game Maker has figured out when YoYo Games starts phasing out 8.1 without even connecting to the web, then we’ve got some serious singularity shit going on. Anyway, dialogue was already prototyped and most of the code was already in the main game, just needed to test it and apply it to all the characters. So it was fortunate that Game Maker decided to crap out on a week when I had very little to do. This might be a sign that I have to switch to Studio, unless I want to borrow a car and bring the desktop home once a month. Guh.

OEM’s code gets buggier with each system I add, and part of this week’s goals was a lot of tedious cleanup. I work a lot more efficiently from the office, though, and I really don’t want to do boring shit from my basement, so that’s getting tabled for next week. Or never.

Checklist:

• Basic Movement
• Character Switching
• Pushing/Pulling
• Dialogue
• Entering/Exiting Rooms
• Collecting Inventory
• Using Inventory
• Climbing
• Carrying
• Crawling
• Sentence Line
• Throwing
• Camera

Week 02

This week:

• began prototyping objects you can push and pull
• got confused by collision code
• finished prototype of pushing/pulling objects
• drank water
• incorporated pushing/pulling into main game
• tweaked movement code
• drank more water

Pushing and pulling objects means tangling with Game Maker’s persnickety collision-checking system. Theoretically, when you register a collision with and object – for our purposes, we’ll call it o_pancreas – you can use the affix “other” to go digging around in the object’s variables – i.e. other.islets_of_langerhan += 1. This is mainly useful because I want to call certain code any time I collide with an object you can grab (o_grabbable), but want to access the variables only of the one I’m touching at the moment, like its x-position (other.x -= 2). For some time couldn’t get any code that would let me use “other” properly, and though I could get the engine to recognize the collision between two objects in certain instances, I couldn’t in others, despite having written nearly identical (and fully functional) code in the past. After breaking out the laptop and banging around the web a bit, I picked up a new trick that’s working well. Still a little bothered that I don’t know why the other code wasn’t working, but I’m just plowing forward for now.

The trick in question is to use Game Maker’s instance_place() instead of place_meeting(), because place_meeting() returns true or false, where instance_place() returns the instance ID of the object you’re touching. So now I’m touching one instance of the dozens of grab-able objects, but then saving its unique ID in a temporary variable and using that to fuck with its code. Functions that save data to temporary variables is a trick I’ve known of but haven’t really used effectively before, so I guess I can add that to the toolbox from here on. Getting better at this.

Incorporating the mechanic into the main prototype wasn’t too difficult, though I need to make some animations for pushing and pulling now, and I realize I haven’t budgeted new art into my checklist. It’ll just have to happen somewhere. Also F’d with collision masks a bit, needs further tweaking still.

Hydration is important.

Checklist:

• Basic Movement
• Character Switching
• Pushing/Pulling
• Dialogue
• Entering/Exiting Rooms
• Collecting Inventory
• Using Inventory
• Climbing
• Carrying
• Crawling
• Sentence Line
• Throwing
• Camera

Week 01

This week:

• completed movement code
• squashed bugs in movement code
• prototyped “smart” character switching
• discovered I had not in fact completed movement code
• spent hours trying to squash persistent bug in movement code (the solution was, as always, “you were being an idiot”)
• implemented “dumb” character switching

The incorrigible bug in question was a variable that was flat-out disappearing. Not amounting to the wrong number, just poof, not showing up in the debugger next to all its variable friends and neighbors. This led to 8 open tabs on the Game Maker/TIGSource forums and a lengthy email to some programmer friends, until I realized that I’d used the same name for a previously-declared global variable in an earlier prototyping session.

The primary learning mechanism to programming is raw embarrassment.

As for “smart” character-switching, that’s a totally low-priority thing I’m tackling for the fuck of it. I wanted to see if I could write code that would let you switch to whichever character was immediately to your right or left, rather than the next one on a predetermined order. This would mean creating a self-sorting list that tracks and ranks every character by their x-position, which I didn’t quite know how to do. Funnily enough, I figured out the self-sorting list part without much difficulty, and got weirdly stuck on actually cycling through said list. Went ahead and coded “dumb” character switching for the sake of a functional prototype, but will return to the “smart” kind next week. (After the global variable kerfuffle, I deserve to throw “smart” in scare quotes every time I use it for a while.) Anyway, this is the first time I’ve ever given myself a coding assignment just for the fun of it, which means coding is apparently, now and then, fun.

Here’s the vertical slice checklist:

• Basic Movement
• Character Switching
• Dialogue
• Entering/Exiting Rooms
• Collecting Inventory
• Using Inventory
• Pushing/Pulling
• Climbing
• Carrying
• Crawling
• Sentence Line
• Throwing
• Camera

Week 00

In the past couple months:

• transferred basic movement code to new computer, cleaning it up and better commenting it
• got basic dialogue system working

Yes, it’s been almost 2 years. I’ve gone in and out of trying to have someone else program this thing, and I’m back on doing it myself, with a couple code-savvy people and several internet communities on-hand for when I need to ask for help, which I’m forcing myself to do this time. Somewhere along the way I became a smarter programmer, which is not the same thing as a better programmer but is certainly useful. I’ve mapped it out: there are 13 systems necessary to have a functioning vertical slice. I am using a co-working space in Boston 2-3 days a week, with a much faster PC that (crucially) does not connect to the internet, and the amount of stuff I accomplish there as opposed to working from home or the library is mental. I have a lot else on my plate, but I’m committing to one system per week. Which means I should have a vertical slice done (or near-done) in just over 3 months. Oh, and I’m back in school, and folding this into an independent study for credit, which will certainly guarantee that work get done on it.

As for that dialogue system: trying to get that goddamn thing working two years ago is what made me finally give up on programming OEM myself. Josh finally offered to be the main tank on programming, but it meant starting over from scratch with a new engine, since he was far more adept at Flash than Game Maker. It’s largely my failing as a program manager that we never quite figured out a workflow. But somewhere along the way I got itchy to try my hand at programming again, and one of my first days at the new “office,” I got an idea for how to attempt the dialogue system and managed to get it functional in a couple of afternoons. Moreover, it was fun. So I’m back on this thing.

I’m going to update work as it gets done, so if I get ahead or behind, you’ll know about it. Cheers.