if(adventure): Pre-Post-Mortem Part III

All Out of New Pictures

Alright, in the last couple of posts we've talked a bit about the past and present of if(adventure). Now let's talk about what the future holds for it. If you the previous posts, you may want to check the previous parts before jumping into this one. Or you might not. Either way, here we go.

As we discussed in the last post, the biggest setback during the game jam when I initially created if(adventure) was that I couldn't come up with a gameplay system that fit with the 'code-based' theme of the game. I still can't, but I can at least say what it should be like. And maybe, just maybe, by writing down the thoughts and ideas I do have, they might gel together into something by the end of this post. Wishful thinking, but at the very least I'll have a log of ideas to come back to.

The coolest aspect of this game, in my humble opinion, is that it pulls back the curtain of how games function in a fairly unique way. There are plenty of "coding" games, where players actually write code to play, but those usually require at the very least a programming mindset if not coding knowledge. This game should be fairly accessible to anyone, requiring only reading ability. Potentially, it could be a way for players without programming knowledge to get some exposure to the wonderful world of code.

Furthermore, in traditional games the player has to suss out the results and consequences for their actions more or less through trial and error. Similarly, in a Choose Your Own Adventure book, as the player is presented with choices, the consequences are spelled out for them on the next page (and then they go back to the previous page when they don't like the ending they get).

This game, on the other hand, is sort of a blend between the two. A decision might go into a difference function, in which case the player won't know what's about to happen. Alternatively, the player could also potentially see exactly what will happen, such as in a combat system where the player can adjust their actions based on the enemy AI code. For instance, imagine a turn-based combat system with the player facing off against a dragon. The player can see from the code that comprises the dragon's attack behavior that the dragon bites when the player is in close range and breathes fire when the player is far. So the player backs off in order to use a fire absorption shield to counter the dragon's attack, which they knew would happen. Admittedly, it's not fully fleshed out, but you get the idea. The ability to 'exploit' the game's own functionality could lead to very interesting gameplay.

There's also a lot of fun that could be had with the idea of the player playing a game that is in "active development." The player could find code files have been changed since their last visit. Bugs could even be introduced and patched during development. Something along the lines of "Uh oh, someone updated the code and now your attacks do damage to you." It probably wouldn't be the focus of the game, but it might be a fun addition to keep players on their toes.

It's easy enough to think of ideas for this game. The problem lies in piecing them together into a cohesive experience. While I wasn't honestly hopeful that writing this post would help me come up with new ideas, now that I've gotten to this point, I've just thought about how the player could be "in" the code. Existing inside a world of functional text that can change around them, opening up new 'areas' to explore. Not much there yet, but it's some food for thought.

That's about all I've got in terms of if(adventure) for now. The source code is still around for your viewing pleasure, but I think it's time for this one to go back on the shelf for a while. It was great to revisit this project and reminisce. This post in particular certainly helped renew my drive to come up with the gameplay this game deserves. Hopefully in the not-so-distant future there will be another part to this series, when development resumes.