Archive

Monthly Archives: January 2015

EveHeader

The parameter editor is pretty much done. It crashes whenever I try to do anything still, but all of the things that are supposed to make it do things are in place, so it’s just a matter of ironing all that stuff out and making a few minor UI improvements. The biggest benefit to the system as it is now is that just by changing a few things around I should be able to use the exact same editor to make entity templates as to modify specific entity instances as placed in the level, which is pretty exciting. Thus, in a roundabout way, I’ve come to a point where I’m going to get for free all of the stuff that I was wracking my brains looking for a way to add to my entity editor before. This is why it sometimes pays off trying to make things nice and elegant, because nice and elegant things tend to be much friendlier when you want to do something complicated with them later on.

Throughout all this, the biggest nightmare has just been figuring out how to handle arrays. It’s essentially impossible, as it turns out, to find out at run-time what the intended contents of an empty array is. I wasted pretty much a whole day trying to figure out a way around that problem, but in the end was only able to solve it by tagging all arrays used in behaviors and behavior parameter types with metadata describing the content they held. I’m not wild about that since it’s another solution that places pressure on anyone who wants to add new behaviors later (realistically that means me, but you never know), but it is a solution and it was the least onerous one I could think of while still maintaining some semblance of type safety.

I think I’ve got all of the hard parts done on this, so it should be just a day or two to finish it. I may take another day or two to build a template editor using the same code, and then I think either the animation system improvements needed for the secondary attack or a basic lighting system.

Advertisements

jazzpunk

Yeah. the title just didn’t feel quite right without an exclamation mark. I’m not sure why ‘JazzPunk!’ isn’t the official title, because if any game deserves exclamation marks it’s this one. The entire experience of JazzPunk revolves around

Surprise!

With every action you take, the game has an unequal and perpendicular reaction. Every bit of every environment is full of little jokes, and even if most of the jokes are kind of dumb each one is, in its context, given the element of surprise, hilarious. Sometimes all that makes a good joke is telling a bad joke at the perfect moment. Everything is timing. Everything is context.

You play as some kind of secret agent. Who you work for isn’t important. Who you’re working against also isn’t important. There seems to be a lot of deception and skullduggery going on, but none of that’s important. What’s important is in the moment, and at the moment you’re collecting spiders for some reason or making a cowboy vomit up his kidney or murdering a mechanical pig. Why? Also not important. Just do it.

Given that looseness, you would expect something similar to the non-sequiter cartoons of [Adult Swim], who published the game – and, to a certain extent, that is the case. Weird nonsense keeps happening, tied vaguely together by a surreal spy-thriller pastiche narrative. What makes it feel different, though, is the character you play, Polyblank, seems to be, rather than a helpless audience member for the craziness, the primary force of chaos, weirdness, and hilarity in this world. Though the interactions surprise you, the player, each action undertaken seems to be exactly what PolyBlank intended to do. PolyBlank is Bugs Bunny, walking into a fancy penthouse, flipping eggs into the face of his enemies, bouncing off of the pavement effortlessly after a four-story fall, wearing sexy drag to seduce unwitting foes, hamheadedly walking into the most obvious traps because that’s what the narrative requires. In JazzPunk, you’re not just being told jokes, you’re telling the jokes along with the game, and that participation makes them that much more hilarious.

In this hyper-active environment, even the most tired gameplay tropes take on a new and humorous light. The absurd fetch quest, where you have to find an arbitrary number of some item and any less simply won’t suffice, actually fits perfectly into a world full of game parodies and references, even as it serves the player-routing purpose those quests usually serve. You have to collect 5 spiders – why five? Because there’s a ‘0/5’ at the bottom of the screen and a little bell will chime and tell you you’re done when you get them. This is little different than the completely straight-faced execution of games like World of Warcraft except that the context that they’re set within is so ridiculous that the inherent absurdity of these actions becomes self-parody.

What makes JazzPunk such a vibrant experience is just how responsive the environment is – not just anticipating your actions, but using them as platforms to build jokes off of. It is the closest a pre-scripted game has felt to the kind of improv game that actors play, building off of every strange premise towards a stranger conclusion, fractal weirdness spiraling outwards and inwards. This kind of responsiveness has to be exhaustively designed into a game: The idea of somehow coding this experience into an algorithm is inconceivable. How do you turn the truly unexpected into a procedure? It’s an inherent contradiction. There are no labor-saving methods. There is no easy path to making a game like this. The only way to make a game like this is to put the time in, to really engage with your hypothetical player, and to fill every inch of the game with little love notes. That love shows.

For all the joy of that direct engagement, there’s a few spots where the game could have probably used a bit more polish. Wandering around for 15 minutes looking for the right place to cook a mechanical pig kind of kills the pace of the game, especially when there is an actual oven which you apparently can’t use, and.are several fires around which look very similar to the one you need, using the same animated fire sprite at approximately the same size. This could have easily been resolved by changing the color of the fire slightly, making it bigger, making it cast more light or flicker more, increasing the size of the stones lining it or making them brighter, making it cast a plume of smoke visible from a distance… anything to make it obvious that this thing is an Important Thing. As it is, it kills the pace of a game that relies primarily on timing to be enjoyable, so I would consider this single moment to be the game’s biggest flaw.

Playing JazzPunk, observing how readily and effortlessly it cribs aesthetic and jokes and ideas from disparate sources, I’m reminded of the oft-quoted phrase, “good artists borrow; great artists steal.” This phrase can be and has been interpreted in many disparate and contradictory ways – that’s what makes it so useful. But when I play JazzPunk, when I think about my own work, I think about how when I set out to evoke an impression or emotion inspired by another work, to imitate an aesthetic, I move gingerly, am easily waylaid by ideas, self-doubts, and confusion. However, if I decide to just copy something, my agency and need to make conscious decisions is forestalled, and I can just create. And, because I am flawed, my creations, my theft, will be imperfect, and I will have, in my plagiarism, created something new, something uniquely of myself even as it attempts theft. How much of the greatest art is created by attempting to imitate something and failing? How many great works are crafted of a clear medium, using the message of another, and imprinted with the indelible and personal flaws of the artist?

We all imitate. We are all echo chambers. But our shape which wraps around the reverberations carves them into forms, makes them new, even as it strives for fidelity. Steal however much you want; your fingerprints will always show.

Next: BattleBlock Theater

EveHeader

It took way damn longer than I meant it to and it was far more frustrating than I thought it would be, but the new entity system is fully armed and operational.

I was going to use this space to complain about exactly why it was frustrating, what I was trying to do and why it didn’t work, but I find at this point that I don’t really feel like it. Suffice it to say, due to some specifics of how haXe is implemented I had to either add a bunch of extra semantically redundant lines of boilerplate code to all of my behaviors or dig deep into the intricacies of the haXe macro system in an extremely complex and specific way that would likely leave me sidetracked for at least another week, if not a month or two. I chose the former, but I didn’t like it. I will say this, though: If you’re going to replace a simple system, like C’s #define code replacement feature, with a powerful system, like haXe’s macros, maybe make it so it’s not a nightmarish clusterfuck to achieve the functionality of the original system with the new system? Thanks.

Anyway. The new entity system seems to work perfectly. It should be safer and less bug-prone now, since entity behavior parameters are now type-safe unless specifically bypassed. It’s also a lot easier to separate which properties belong to the entity template, which are saved with the specific entity instance, and which are transitory and only needed for calculations while the entity is in use. These all being neatly separable will make it a lot easier to create a tool to edit these values, which is what I’ve started working on now.

The trickiest part of creating this parameter editor tool is that I have no real way of knowing beforehand what each parameter will be. Most of them will be basic data types, strings, integers, boolean flags. A few of them will be arrays of the same, which are a bit trickier. Some of them will be custom classes, needed for animation handling and other complex instructions, and those may be quite tricky – and, making them more difficult, in most cases these complex types are themselves stored in arrays, meaning I’ll have to tackle both those problems at once.

I’m not really worried though. I have a lot of tools to work with here, and this is a much more manageable problem than before, when parameters were scattered everywhere and I had no real way of knowing what to save and what to delete with the entity aside from manually flagging each parameter. I think there’s a good chance I can get this editor complete within a week, at which point the entity editor will be done. Again. Goddammit.

From there, I’ll finish making the test storytelling system and make sure it works. After that… either make some test enemies that can actually fight back, making the secondary attack work, or adding a basic lighting system.

Hopefully progress will pick up again now that I have that onerous horseshit out of the way.

EveHeader

This is the week I decided that a lot of what I had been doing was wrong and ended up completely reworking it. I can’t really claim to have made a lot of progress, since everything has kind of just been rearranging things so that things go smoother in the future, but I’ve been working pretty hard anyway.

Last week I said I’d created an entity ‘signature’ system to track them uniquely. I’ve decided that that system was redundant and poorly thought out, so I’ve deleted it: Instead I’m working on fleshing out each entity’s ability to track its own state between creation and destruction, the ability to set remembered parameters from outside or inside the entity and use those to create whatever long-term effects are needed. Because of this and because I’ve long felt the entire entity system is a bit suboptimal in terms of stability and understandability, I’m overhauling the entire entity system now. Here’s how it’s supposed to work:

EntityFlowchart

Each entity has a template, which stores all of the behaviors of the entity and thus defines basically what it is. It also houses the settings for each of those behaviors, which can be tweaked as necessary, and which are saved with the template. The entity itself also has two data storage points, parameters, which are saved with each entity instance, and status, which is transitory and created/deleted with the entity. Previously, I’d kept both parameters and status data together in one block, but separating them allows me to make certain assumptions which will prove invaluable when I start working with them more directly and regularly. Also sorry for my handwriting.

Before I went down that whole road, I spent a couple of days overhauling the entity editor, which is now much more streamlined and easier to work with since I took all of the template editing stuff out. For now all of that work will go unused, but I may create a separate dedicated template editor with the work if I decide that will be a good use of my time somewhere down the line. So, once I finish overhauling entities, now that all of the parameters I need to tweak for entities will be conveniently split out into their own object I should be able to fairly quickly and easily throw together a parameter editor to fit on top of the existing entity editor, and from there I should be able to very quickly start populating levels with entities while still being able to tweak them in a fairly detailed way as necessary.

There’ve been a few slow days in the mix here, but I think that once I get through this work will pick up again pretty rapidly. I’m looking forward to it.

 

moderate spoilers

the-swapper

Space is fucking cool.

I mean there’s a lot more to say about The Swapper, but I think that may be its most lasting impression of the game on my mind. No other 2d platformer has captured the loneliness, awe, and terror of space the way this game has. While its presentation is obviously influenced by Super Metroid, the Metroid games were far more about exploring an underground alien wilderness than outer space itself. The environments of The Swapper are largely traditional 2d puzzle-platformer rooms, but there are also a couple of segments where you have to navigate through a weightless environment – though, because the game is still mapped into 2d space and constrained to the boxes of the designed levels, you are never really in danger of losing your way and setting yourself adrift endlessly through a vast black void, the disorientation of being cut off from the tether of earthly gravity, the discomfort of no longer having a down to orient yourself against, still gnaws at the edge of your mind – makes you wonder, when you push away from the hull of the ship and out into the unknown, whether you will find your way back.

There are a few tricky puzzles in The Swapper, but I found most of them fairly easy. In games of this style, solving a puzzle is usually just a matter of reading the designer’s intent. All you have to do is figure out why each object is placed in the room, and the solution becomes obvious. This isn’t intelligence per se – this isn’t even exactly problem-solving. This is just reading the language of game design. An unfortunate drawback to creating puzzles like this, using a small set of game objects, is that it is easy to read the designer’s intent. It would be easy to obfuscate this, it’s true, by adding extraneous crates, buttons, switches, a sea of red herring: It would make the game feel less elegant, but also less contrived. It would make the solution harder to find, but perhaps a more genuine discovery. I’m not saying that the developer was wrong to create the puzzles the way they were created: I just want to point out an assumption, or set of assumptions, worth questioning. Is ‘elegance’ in puzzle design necessarily desirable?

The device which gives the game its title is the Swapper. It appears to have two functions: First, it can create a perfect clone of a human being and everything they are wearing and carrying, right down to the swapper itself. For some reason this capability is rarely commented on, though it seems possibly the more impressive of its two functions. Second, it can allow human consciousness to be transferred to another container.  The exact process at work here is an open question, around which much of the game’s plot centers: Does the device transfer the mind, some nebulous construct that exceeds the fleshy mechanics of the human brain? Or does it do something less metaphysical, more invasive, potentially dangerous? As the story progresses, it seems like there must be more to it than is immediately obvious. Given both that if your currently ‘active’ clone dies you have to restart the area, and that another person who uses the Swapper collapses immediately after, it seems certain that something must leave the body of the person who uses it. At the same time, as long as your clones are in close proximity they are easily controlled by the same consciousness that controls your ‘main’ body, so some connection must be maintained.

Putting these clues together, I surmise the following: First, use of the Swapper essentially destroys the ‘source’ mind it works on and stores a copy in the Swapper device. This turns out to be useful on the Theseus station in particular, since it seems to be full of rocks which act upon the mind in the same way as the Swapper, reading and writing memories, and were likely themselves instrumental in the development of the device: This is probably why usage of the Swapper was encouraged, because unprotected human minds would be quickly overwritten and destroyed by the thought-noise generated by the rocks, whereas a mind safely housed in a Swapper could operate indefinitely. Thus, the crew’s unwillingness to use the device, mentioned at the start of the game, likely contributed to the catastrophe that destroyed Theseus. It also seems to exert some ability to control nearby clones, entirely separately from the mind stored in the device, and operating some distance away – even though the mind is housed in a specific swapper device, it uses the body holding it to trigger the device to transfer the mind. This means that if the body holding the active Swapper dies, there’s no one to pull the trigger, and it lies inactive on the floor for a presumed eternity. Thus, while the Swapper can be used to transfer the stored mind into another container, if that container is not another Swapper it’s likely to stay there, since most containers won’t have the capability to transfer the stored consciousness back out.

The only restrictions on your ability to clone your body and swap between clones are line-of-sight and areas with colored lights that block the effect of your device. Using colored light to restrict player capabilities is an interesting choice: Though the effect is primarily pragmatic, a means of restricting the player’s frankly godlike powers just enough to make it possible to create a decent puzzle, and the choice of colored light to present it likely just the simplest and most obvious available solution, the fact remains that colors of light are also loaded with cinematic meaning. The blue light that keeps you from cloning also evokes coldness and loneliness, appropriate both to the setting and to the restrictions it places upon you, while the red light that keeps you from swapping evokes danger, also appropriate since it effectively closes off your normal escape route of transferring to another body. More than once in the game, I would find myself surprised to have my ability to use the Swapper restricted, only to realize a moment later that, of course I couldn’t, the entire room was bathed in a cold blue light. The blue and red light also sometimes mix together to make a purple light, which I guess mostly evokes a garish discotheque. It’s not a coincidence that this color is rarely used outside of puzzles where its presence is absolutely necessary: It’s unfortunate that the color had to be purple, because it does look a bit ridiculous, but I suppose better that than some counter-intuitive third color – though perhaps a cooler and less saturated tone might have helped.

The psychic rocks encountered throughout the game probably don’t think, as such, any more than the Swapper device itself thinks. They just remember: They’re just records of memories imprinted long ago, by other interlopers and passersby. Humans, encountering this, can easily mistake these words for intelligence, but in practice they’re just a collection of memories given voice and shape by the audience-human’s own personal history and experience. The closest thing to an emotion or opinion expressed by the rocks is “the chain has been broken”, which is essentially rock-speak for “404 FILE NOT FOUND”. Throughout the game we hear the sound of a record player under the background music, reinforcing this idea: This music is not being played by a person, it is just a record, a memory. Everything here is dead: Just because it speaks to you doesn’t mean it’s talking.

At the end of The Swapper, you’re asked to choose between two endings. A lot of the narrative up until this point has been leading up to this choice, so you have a pretty good idea of what it entails. Personally, I didn’t have a strong opinion on which ending I wanted to see, so I chose the slightly more appealing one on the basis that I could just reload and check out the other one afterwards. However, the game wouldn’t let me do so, just playing the credits sequence when I tried to continue from my last save. If I’d known this was the case, that I’d have to replay the entire game if I wanted to see the other ending, would I have chosen differently? I understand that they wanted the choice to mean something, so they made it irrevocable – but, if I only find out it was irrevocable after the fact, then it was only a meaningful decision in retrospect, with none of the gravitas inflected upon me at the time I made the decision that was supposedly so important. I don’t think it’s bad to make the player live with the consequences of their decisions in this way, but if the player has no idea what the ramifications of a decision are then it’s barely a decision at all. The entire gameplay of a game like The Walking Dead is based around these kinds of decisions, irrevocable and impossible to optimize, and this expectation is set very early on in the series. Making the player make a decision like this, supposedly loaded with meaning, without communicating the importance of the decision at any other point during the game, guarantees that the impact of the decision will be dulled. In the end, decisions like this aren’t really what the game is about: So why make me play through it again if I want to see the other ending?

I think this is a good video game. It’s pulled in a few different directions by ideas of what it’s supposed to be, and this indecision hampers it in several areas, but it brings a lot to the table: Clever puzzle design and a beautiful aesthetic presentation make it easy to engage with, and the story is, while not hugely novel or mind-blowing, definitely meaty enough to be satisfying to think about for a while even after completion.

Next:Jazzpunk

EveHeader

Well, missed last weeks update due to holiday craziness. I worked as much as I could, but it was pretty difficult to sneak time in for it between everything else that was going on. I’ve mostly been working on a whole lot of small miscellaneous improvements, so it’s a bit difficult to sum up my progress over the last couple weeks.

I roughed out a Monologue class. I’ve been saying for a while that this game needs a dialogue system, but, for this particular project, I can assume only one person is going to be speaking most of the time, in a very specific way, and I can make a lot of assumptions on that basis. I think making this assumption very clear will allow me to code more easily and, in the end, present the final version much more elegantly – but this system still has a ways to go, and I haven’t entirely decided how I want to approach it yet. This is far more of a design challenge than a technical one: The difficult part is not in figuring out how to achieve the system, but in figuring out what exactly I want the system to achieve. Hopefully in a day or two I’ll have a solid idea of what I want.

I also added a system for keeping track of entities when they’re not actually active, by giving each entity a unique ‘signature’ based on its starting position. Using this, I should be able to write code affecting whether and how entities spawn, which will be useful for, for instance, making it so a defeated enemy no longer respawns. There’s a problem with this system, though: If I move the entity to a new location while editing the level, the stored signature is different from the new one. Not sure if or how I’ll be addressing this, but it is something worth keeping in mind as I move forward in case it causes problems further down the line.

I went through and did a lot of tweaks to the different editors, ranging from bug fixes to small new features to slight interface improvements. There’s a handy dandy grid on the tile editor now, making it easier to line up passageways between levels. I made a bunch of tweaks in editors and elsewhere to make things behave more smoothly and predictably, fixed a couple of issues with controller input and with the player sticking to surfaces, debugged and streamlined transitions between maps and levels.

So, for the last couple of weeks, no huge changes, but lots and lots of little ones. As I get closer and closer to making these editors the toolset that I actually use every day for the next couple of years, I find it increasingly urgent to really try and get it running smoothly and intuitively.

Also, during a bit of downtime during the holidays, I did this sketch of Eve:

EveSketch00

I left the mask blank, after drawing it a number of ways, partially out of frustration and partially to demonstrate here the reasons why I was frustrated. There’s a few things I want to capture in this character design: I want her to seem otherworldly, humanoid but not quite human. Towards that, I exaggerated her slenderness and the length of her limbs, and I gave her a physically impossible ‘mask’. The problem with the elongated body and limbs is that, in this world of crazy and exaggerated art designs, and seeing her by herself, it doesn’t necessarily read as unusual. It’s not clear that this is anything different than whatever the standard human anatomy is in this world. And, for at least the first chapter of the game, it will probably remain this way: Heck, maybe it will work out better because of it, and it will increase the impact when we see her next to actual humans and see the differences that we’d previously overlooked. So maybe it will work out! Nevertheless, in the moment when I’m drawing and trying to capture this strangeness, it is frustrating.

The second problem is similar to the first, and illustrated here:

MaskComparison

The mask is supposed to have three equidistant holes in it, each going deep into a void. Here’s the problem: It’s actually really really difficult to put three holes approximately where a human face would be and have it not be read visually as a human face! In the first version, on the left, even though the two parallel holes are well under where the eyes would normally be, they still look like eyes under a huge forehead with a third eye in the middle. In the second, middle version, the two on top look like eyes, even though they’re right on top of the head, and the bottom one looks like a mouth. The only way to avoid this problem even slightly is to make it so the holes are two on one side and one on the other… which just straight-up doesn’t look that great, because the mask is no longer symmetrical. And, honestly, it still kind of looks like the hole on the right is an eye.

Frankly, I don’t think either of these problems really have solutions. I’m probably just going to have to live with them as I go. I thought it might be interesting for some of you to read about some of the challenges of this dang character design, though. On balance, I think the one on the left is probably the best. Perhaps I could do better if I tried changing the shape of the mask, though. Dunno! Fortunately I don’t have to decide right now.