Have you ever found a note written by yourself months ago? How it’s unmistakably you, but you have no idea what it means or why you felt it was important at the time? That’s basically the living reality for inhabiting any long-term, big project. It’s that curious combination of familiarity but novelty, like walking through a hedge maze I’m regularly surprised by Past Brett when writing The Day After, and mostly in a good way. It doesn’t make the progress swift, though.
My last few dev reports have been promises to work on the GUI system so I have something to show people. It’s been my goal this year to have something (anything!) to show by the end of the year. I’m still steadily moving towards it, but like a spaceship docking with a port, you keep moving forward and the goal gets larger and larger and impossibly larger still as you approach it.
The good thing is that my core application code seems to work buttery smooth. It takes in command-line arguments, reads in options, sets up the right subsystems and… dies gracefully. The issue at the moment is in the GUI Manager, which is probably the best place to have issues. When creating the GUI manager I was throwing all sorts of things together, hoping it’d work. I used example code and settings with an eye to cleaning that up later. Such was my desire to just get things working. It didn’t work so great.
It’s like in my haste to get things in order, I was throwing things in bags. Now I need to reach into those bags and inspect things carefully. Some bags are full of jewels (or at least, nicely rounded coal). Some bags are full of scorpions. I’m currently stuck with a bag of scorpions. Maybe plush scorpions because it’s not so bad, but still…
Currently the code dies because I’m using some GUI layout settings that are from an older version of the library, and it needs to be updated. But honestly, I’m using copy-pasted settings and I need to man up and write something properly. This means tackling the Falagard skinning library. Not a tough problem, but staring at XML is losing out to the delights of Grand Theft Auto V. Still, I have a long weekend coming up, so hopefully I can be useful.
I’ve been playing board games with some fine people lately. An assortment of games, so I’ve used the opportunity to examine various aspects of those games in order to inform The Day After. One thing I’ve been thinking about (and wrote half a blog post on!) the end of a game and how that plays out. This is intimately tied into pacing.
My current conception of play means a game will be fairly steady – the game is broken into chunks and if you do enough scenes, you complete a chunk. The final chunk is all to do with escaping the city. This could work okay, but I like the idea of rising and falling tension.
The game Escape: The Curse of the Temple does this fairly well. The idea of the game is that you and your friends need to escape a cursed temple by exploring it. You have some very simple tasks to achieve before escaping (activating gems to reduce the temple’s curse). If it were a straight-line path to the end like The Day After is at the moment, it’d be a lesser game. Arbitrarily, but excellently, Escape forces you to mini-climaxes where you have to stop exploring and get back to a safe zone. These peaks of action occur just about when you’re starting to get comfortable, which is perfect. The final peak of action requires everyone to make a bolt for the exit, and you don’t have time to rectify however well you’ve cleared out the temple. I highly recommend Escape. I also highly recommend Shut up and Sit Down‘s review of it.
I have certain options in The Day After to replicate this. To escape the city, you’ll be required to satisfy your rescuers’ demands. This might be turn the power back on, get samples of whatever’s causing the chaos, or stealing enough loot to pay them off. Rescue is for everyone, or for no-one, so the entire team needs to contribute. These missions can act like the peaks in Escape, although you may have to do extra legwork to ramp up the tension.
Other ideas I’ve been thinking about is the head fake. Imagine the Survivors making their way downtown to their rescue chopper. As they are mere blocks away, the helicopter swoops in… then gets taken out by a rocket launcher. This twist means the Survivors might have to survive another chunk or two of scenes, and gives a new mini-mission to pursue (“Kill whoever is shooting down your rescue!”). I’d worry though – I’ve played many board games where you can hamstring someone who looks like they were about to claim victory, thus extending the game. Movies that go on for twenty minutes longer than you expected can be unsettling. You tend to not get that with books or comics (since you can always see how many pages are left). Is it legit for a game to do? Is it good? Could you tell when it’d be beneficial or detrimental to throw in this head fake?
Another idea I had (but will hold close to my chest) is a form of the “pull the rug from under comfortable players”. Once you get over the introductions between players and the first few scenes, the players will settle into a routine and maybe form an idea of what’s going on. I came up with a great way to upset all that. It doesn’t necessarily change the routine, but it changes the narrative. If I can implement it and get at least one person going, “What the… oh noooooooo…” then I’ll have succeeded.
The Short and Sweet
Recently completed tasks:
- Fixed up some cross-platform code for Windows and Unix. I hope Unix more-or-less covers OSX.
- Fixed up the launch sequence for some subsystems.
- Added proper command-line options handling.
- Improved some of the error reporting and handling of funny situations.
I’m currently working on:
- Falagard skinning and getting a base UI scheme into place.
- Tracing the launch sequence from start to GUIs doing something (I estimate about 75% of the way there).
- Back-end tools for creating scenes and content.
I’m trying not to:
- Play too much GTA V.