« January 2015 | Main | April 2015 »

February 13, 2015

How Projects Run Late, in the small

Today I was working on a project and I've been doing my best, given recent events, to do some reasonable thinking about how things will go before I do them, and then jot down an estimate which I compare to real time after the fact¹. Here's the story of one of those tasks, a tiny little task which is a microcosm of game programming (and indeed, game development as a whole).

It was simple. I just wanted to add a little close box in the upper right hand of a dialog box, and make it so that when I clicked on it, it closed that dialog box. These dialogs are rendered by my own code, rather than an operating system, and so I'm responsible for that sort of thing.

The code for this project is *dead simple* at this point, and so I estimated this task at about 15 minutes. Five to draw a little box with an X in it, and five to deal with the mouse-handling logic, and five of buffer because hell, something always goes a little bit wrong. Sure, I could have doubled it, but I didn't. This couldn't really go *that* wrong, could it?

Well, I tossed in the logic to draw the box and all that and it worked first time so I was already ahead of schedule, it took about three minutes to do that. Excellent! Here I am, ahead of schedule and half-way done.

I threw in the logic next to handle the mouse click. This was really simple code: if the mouse position is in the box when clicked, change the state of the game to not display that dialog. (Like I said, this project is *dead simple* at this point.)

Huh. That didn't work. That should have worked, shouldn't it? Well, double-check the code, run with the debugger and we'll have it sorted in no time.

Now, I'm working on my Mac and using DLLs for my game logic (inspired by Handmade Hero) and between not being a long-time Mac dev and some stuff with Xcode of which I'm not fond, just stepping through this code sensibly takes a little bit of time. Sure, it might have been better on my PC, but I'm not working on the PC today, oh well, better remember next time to pad my estimates a little more when I'm working on the Mac. Still, this is maybe two minutes of fiddling, still plenty of time left.

I step through the response to the mouse click and it just jumps over my test and says I haven't clicked the button and I scratch my head with the hand that hasn't just clicked the button. UI stuff is always fiddly, too, because you sort of need to hold the mouse down while you step over your event processing stuff, because while you're in the debugger, those things are going to queue up and so I do it a few more times to make sure I'm doing the right thing here, just getting a down event and not an up, all that.

Huh, well, we've reached that 15 minutes and we have no idea why.

So I look a little more closely at the input logic. I mean, I've used this code on this other project I'm working on and it's just fine there, I don't know why it wouldn't... oh dear.

See, I had copied that logic out of that project before I found this exact same bug over there, and while the details of the bug aren't relevant, the way your mind plays the trick on you of thinking a bit of code is tested and ready is. It takes me another five minutes having figured that out to dig out the code I really want, remove the broken code, and get it all going so I can show that it is now working as promised.

But of course, it isn't. Because my double-click logic in this new project is eating up these mouse clicks (in error) and the single-click I actually want isn't getting through to this code. Ok, tidy that up... and... yes, okay, there, it works. Lovely. I check that in, look at the clock and see that here we are, just over thirty minutes into a 15 minute task.

I've been programming professionally for almost twenty years and I can't estimate reliably a 15 minute task. I mean, sure, most of the time I probably do, but there's no knowing when I'll miss. To a degree, too, I generally estimate better at less granularity, but properly figuring out how long a bigger task will take involves lots of little tasks like these. And this is an example where I know *everything* about the code, I've written it all myself. Add in a team of coders and fixing even a simple bug without breaking something else rapidly becomes a danger-ridden process.

Of course, these are the simple problems. One little bug in a 15 minute task doubles its time, and you can't know which one of those simple tasks it'll be. This isn't even a particularly creative problem, where you might spend a fair bit of time on a solution and discover that the solution you've designed just doesn't work -- because it's a design that is meant to be fun, and in the end it isn't, and you have to figure out where to go from there and the schedule is blown.

This is not a business of products. We are not simply making widgets more efficiently to increase profits by .001 cents per unit. We're making things, usually new things, and because we're chasing the technology dragon² the years of experience we have often amounts to very little. All the experience in the world can't help you when the measures are enormous and enormously subjective.

I can tell you how many lines of code I can write in a day; it's quite a lot. But I can't tell you how long it'll take me to write the lines you actually want. Not even after all these years.

¹I've also strained today to mostly avoid social media, so that my undivided attention is on these tasks as I do them.
²Every few years, drastically new hardware. Every few months, increased expectation from those who play our games. It's Sisyphean.

Posted by Brett Douville at 03:51 PM | Comments (0)

February 12, 2015

Ultima 2 Complete

Sadly, I finished this game a couple of weeks ago and forgot to post, so you'll get a couple of these in short order.

As I'll probably remark too many times, Ultima ][ is my least favorite of these first three games, but it's a step in the direction of more world-building and narrative that will produce Ultima IV and of course, the rest of the series (including a couple of very richly themed offshoots in the Adventures line, and also a return to much more systemic stuff in Underworld).

So I got through it pretty quickly; the grinding is pretty tedious and it's not worth going into the dungeons, so we don't do too much of that. We'll do quite a bit more of that (or at least I will) for Ultima ]|[.

Episode 5: Game intro, manual, character creation, and some grinding

Episode 6: A bit of grinding, sadly, but also an explanation of how attributes are raised

Episode 7: Space flight, killing innocents, and taking down Minax

Thanks for joining me!

Posted by Brett Douville at 07:28 AM | Comments (0)

February 04, 2015

Notes on This War of Mine

As with any post here, there may be spoilers for games under discussion. Caveat lector. Also, CW: this game is a game about war in an urban environment, and can feature suicide and rape as part of its procedural events, and I will touch on that briefly.

This semester I'm co-teaching a course at Wabash College with my friend and now colleague, Michael Abbott (aka Brainy Gamer). We are both designing and playing games, and so once we've had an opportunity to discuss games in class, I'm going to try and come back here and jot out some notes about what came of that.

If you're unfamiliar with it, This War of Mine¹ takes place in what seems to be an eastern European country, torn by civil war. It presents as a sort of sim game -- you are looking at a cross-section of a burned out house, and you can direct three characters within to perform tasks over the course of the day. Initially, this is simply scrounging for materials within the house, clearing away space, and maybe trying to make a bed so that you can get a bit of rest at night. Once night falls, however, you have the opportunity to send a character out of the house to scavenge at locations marked on an overhead map. The game takes place over about a month of time, and various thematic events can occur.

We had a really great in-class discussion about this game, starting off listing the emotions you feel when playing a blockbuster war shooter (e.g. Call of Duty) and then the mechanics that are characteristic of those games. We did the same for This War of Mine. And then we went and drew lines between the emotions and the mechanics which tended to engender them.

It's encouraging to play a game like This War of Mine, because the emotions that turned up on that side of the blackboard stood in stark contrast to those for the empowering first-person fantasy, despite being ostensibly about the same subject. Fear and anxiety vs. adrenaline. Drudgery vs immediacy. Regret rather than empowerment. But also ingenuity and hope on the This War of Mine side, and really nothing similar or comparable over on the warshooter side.

Mechanically speaking, we spent a lot of time talking about the procedural nature of This War of Mine vs the linear nature of the blockbusters, and that brought about a good discussion of various player stories. Students asked whether I thought that the game explicitly set up situations as a result of earlier encounters -- for example, if you chose to raid for food, that humanitarian aid might come the next day, making you feel guilty and wish that you had waited². We talked about some of the events that students saw in their play: one lost a member of his little band of survivors to suicide via depression, and another witnessed a rape that he tried to interrupt (leading to the character's death, as the rapist was a heavily armed soldier).

All of this brought us over to talk a little bit about complicity in games, how mechanics and thematic elements can teach us to do things of which we may not be proud in retrospect, even in a safe space like this. In the example above, the risk of intervention was brought home in a mechanical way that might lead to a player making a very different choice on a subsequent playthrough. It's also fair to reflect, though, that This War of Mine doesn't explicitly set goals, not even of survival -- a reasonable approach to play would be to maintain a moral stance even in the face of the horror of war, and to prefer death to a degradation of one's moral principles. The goal of survival is one the player implicitly brings to the game, but it's not necessarily required of you.

On the whole, a very interesting game and one I'm very glad I played, as disturbing as the subject matter can be. War is a failure, but This War of Mine is most definitely not.





¹Developed by Polish developer 11 Bit Studios. I played it via Steam, it's also available on the Mac App Store and other venues.

²For what it's worth, I suspect that it's random. I feel like we maybe should have explored this part of it a little bit more -- would one feel differently about the game if one knew one was being explicitly manipulated in this way rather than such outcomes happening as a result of systems?

Posted by Brett Douville at 09:45 AM | Comments (0)