I started making games in C++ using SDL as a cross-platform library. I was only using Windows at the time but being prepared for other platforms seemed like a good idea; also it seemed a lot cleaner than the Windows libraries anyway. When I was preparing to sell Vertex Dispenser increpare helped me port it to Mac, he'd used SDL before and it wasn't much trouble. Actually how it worked was slightly confusing as I found out when I actually got a Mac and tried to do it myself, but ok. Then later I got an Ipad to port Kompendium to and it was pretty easy (in terms of code; adapting the design to touch was much harder). But there were a few problems with SDL on IOS - it didn't work with the simulator, it didn't handle orientations quite right (the taskbar would appear upside down, WEIRD). So I looked at what other people were using and switched to Openframeworks. At first this seemed better; it worked great on IOS; but I start getting occasional reports of Corrypt and 86856527 crashing on elsewhere which I couldn't reproduce but eventually through trial and error sending lots of versions back and forth tracked it down to being NOT MY FAULT and buried somewhere in the library I couldn't figure out. Also some other odd problems. I wasn't really worried if a few people couldn't play Corrypt but since I was planning to sell 868-HACK on PC I had to deal with this somehow. This stalled the PC release for ages; eventually I decided to just go back to SDL for that - yes I will use different cross-platform libraries for different platforms how perverse.
And operating system updates tend to break things. Actually really just Apple ones, Windows has been respectable here. MacOS broke my SDL stuff a version or two ago - updating SDL seems to fix it but they changed the library interface so it's a bit of work to actually go through and make everything work again; I haven't gotten around to it yet. IOS7 demanded an entire update just to add "View controller-based status bar appearance: NO" to info.plist if you didn't want a line of crap drawn on top of everything, and then 8 broke everything by moving the documents folder and pointlessly changing something about how you get to start putting things on the screen I don't even know?? It didn't take all that long to update most of the games I'd used Openframeworks for, just had to update the library and change where they looked for saved games. Except O; when I recompile that now there's no transparency so everything looks awful I DON'T KNOW WHY. But the SDL stuff's been more work, Zaga-33 is just crashing a bunch now and I can't figure out why because the debugger just won't connect to it WTF, all I can think of to do to track it down is comment out a bunch of stuff and see if it still crashes but it's infrequent enough that that will take far too long to get any degree of confidence.
Also the appstore keeps adding new requirements to slow down the process further; I was trying to update Corrypt to fix a bug and it was rejected with some crap like "we made a different-shaped telephone and now we won't accept anything that doesn't explicitly support that too". So of course I just stretched the screen to fit and it probably looks awful but who even cares. Stretching works okay for low-res like Glitch Tank but it's really quite bad for the medium-res stuff I've been doing lately, but doing layouts for a bunch of different resolutions is heaps of extra work too.
Also lol whenever one of my games is reviewed somewhere a sealion pops up to ask why it's not on Humanoid or whatever, like I have time for that. I used to kind of care that Glitch Tank and O were trapped in some super messed up closed platform, but so far the only alternative is even more of a mess so who can really be bothered.
So yeah getting/keeping things working on different computers has been taking up way too much of my time and attention lately. It's ended up taking much longer than it should have because I keep getting frustrated and giving up, I've been a bit preoccupied with other stuff / LIFE and when I get distracted it takes me a while to get back into it and figure out where I was again. And it's just destroying my motivation to work on anything new, I have a couple of new games I really want to be working on but it's hard when I have this older stuff hanging over me unfinished/unfixed/unported. I feel like I don't even know how to make games anymore, it's become so much more work to make them actually work, it's demoralising to start making something with the expectation that even if it's completely functional now something outside my control will break it in six months time and I'll have to fix it again.
I was too prolific and it left me with too many things to maintain. Maybe I shouldn't bother because nobody bought them in the first place but they actually do steadily sell a little bit whenever I release something new so I feel like I ought to keep them working.
Ugggh I miss when I just made things.
Tuesday, 2 December 2014
Thursday, 16 October 2014
Helix
When I first got an ipad and tried to port Kompendium to it I ran into a lot of problems with controls. The games were designed around how they felt to play with buttons and my naive touch implementations didn't feel good at all. (The exception being of course Glitch Tank which turned out to actually be a better fit.) I had no experience with touchscreens before then, didn't have a smartphone or anything. So I'd no idea what I was doing (good place to be IMO, recommend visiting often).
Experimenting with different controls I found that with touch everyone seems to have different expectations. What one found completely natural would baffle another. Then they'd suggest how it should obviously (to them) work, which in turn a third person would find totally wrong. Of course it's absolute, of course it's relative, of course you have to put your finger where your ship is now, or where you want it to end up, of course it doesn't matter where you touch.
All this was complicated by having two players. Often someone would end up reaching across the screen and blocking their opponent - completely accidentally. If that happens on purpose that's pretty interesting to me, eventually I did make O which embraced it, but at the time I was working with existing games that didn't have this concept. Similarly if you design a game to have a really clear distance between my bits and yours (as in Shot Shot Shoot) then you're probably fine - some of the Kompendium games did already but others it didn't make sense for. I decided to start making a singleplayer game and get the controls right before dealing with the harder case of multiplayer. So I started Helix at a jam in 2012 as a simple exercise in control schemes.
Once I added some enemies to avoid, playing around I enjoyed weaving around them and skimming close more than just keeping away from them so I added a rule that encouraged doing this. Added a few different enemy types, lots of particles, toned down the awful strobing lights, and then it was mostly done but I got sidetracked making VESPER.5 and then a bunch of other games. For a long time it kept sitting there basically finished but with a few critical things needing to be done, boring technical things like rewriting code from the jam to actually run smoothly on an older ipod, and I was much less motivated to do that than to make a new game. Other people kept telling me I should hurry up and finish it but I was always off making some kind of weird cyber roguelike or something. And then when I did get around to doing anything on it I usually ended up doing something simple and fun like adding a new enemy type instead of the important things. So it somehow ended up taking a couple of years longer than it should have to get done. (I feel pretty strange about that, it doesn't seem like so long, years shouldn't be thrown around lightly.) But it did benefit some from its long maturation, in particular there's one enemy that took a year to come up with that to me is the one sublime element that lifts it from being just a simple action game to something worth having made, also how the powerups work took some time to settle and just the enemy patterns have been refined. Also spent a long time tuning the controls, getting them exactly right.
At one point I accidentally deleted it and hadn't backed it up so I had to use some kind of deleted file recovery tool to get it back. I'm still convinced it returned with glitches it hadn't had before..
Andrew Toups did the sound for it and it's perfect. Tim Rogers introduced us after I'd been discussing the design with him with reference to their game ZiGGURAT, which was one of my inspirations for how to do a solid small-scale action game (the other main one being of course Super Hexagon).
Anyway it's out now for ios-things.
appstore link
Maybe now I can finally go back to the harder problem of making a multiplayer game with good touch controls?
Experimenting with different controls I found that with touch everyone seems to have different expectations. What one found completely natural would baffle another. Then they'd suggest how it should obviously (to them) work, which in turn a third person would find totally wrong. Of course it's absolute, of course it's relative, of course you have to put your finger where your ship is now, or where you want it to end up, of course it doesn't matter where you touch.
All this was complicated by having two players. Often someone would end up reaching across the screen and blocking their opponent - completely accidentally. If that happens on purpose that's pretty interesting to me, eventually I did make O which embraced it, but at the time I was working with existing games that didn't have this concept. Similarly if you design a game to have a really clear distance between my bits and yours (as in Shot Shot Shoot) then you're probably fine - some of the Kompendium games did already but others it didn't make sense for. I decided to start making a singleplayer game and get the controls right before dealing with the harder case of multiplayer. So I started Helix at a jam in 2012 as a simple exercise in control schemes.
Once I added some enemies to avoid, playing around I enjoyed weaving around them and skimming close more than just keeping away from them so I added a rule that encouraged doing this. Added a few different enemy types, lots of particles, toned down the awful strobing lights, and then it was mostly done but I got sidetracked making VESPER.5 and then a bunch of other games. For a long time it kept sitting there basically finished but with a few critical things needing to be done, boring technical things like rewriting code from the jam to actually run smoothly on an older ipod, and I was much less motivated to do that than to make a new game. Other people kept telling me I should hurry up and finish it but I was always off making some kind of weird cyber roguelike or something. And then when I did get around to doing anything on it I usually ended up doing something simple and fun like adding a new enemy type instead of the important things. So it somehow ended up taking a couple of years longer than it should have to get done. (I feel pretty strange about that, it doesn't seem like so long, years shouldn't be thrown around lightly.) But it did benefit some from its long maturation, in particular there's one enemy that took a year to come up with that to me is the one sublime element that lifts it from being just a simple action game to something worth having made, also how the powerups work took some time to settle and just the enemy patterns have been refined. Also spent a long time tuning the controls, getting them exactly right.
At one point I accidentally deleted it and hadn't backed it up so I had to use some kind of deleted file recovery tool to get it back. I'm still convinced it returned with glitches it hadn't had before..
Andrew Toups did the sound for it and it's perfect. Tim Rogers introduced us after I'd been discussing the design with him with reference to their game ZiGGURAT, which was one of my inspirations for how to do a solid small-scale action game (the other main one being of course Super Hexagon).
Anyway it's out now for ios-things.
appstore link
Maybe now I can finally go back to the harder problem of making a multiplayer game with good touch controls?
Thursday, 4 September 2014
assorted
Updated 868-HACK again. Even after all this time minor things still show up.
It was possible to get the tutorial frozen by dying on the step that advanced to a new message. I saw it when showing the game to someone last week, nobody had reported it but chances are it had happened to someone and ruined the game for them completely. I try to be thorough, and have some wonderful people who help test things for me too, but it's really hard to avoid things like this completely. Practically you have to look at the odds and accept a few people having a bad experience in exchange for ever actually getting around to releasing the damn thing but it still feels bad. So if you ran into that: sorry.
I'd justified .PULL having a lower acquisition cost than .PUSH because, although it combos well with some attacks, in isolation it's riskier to move enemies towards you than away (thought I'd written that in this post but apparently not; maybe I edited it out). But I was finding myself using it all the time, because it's so easy to find a combo for it I rarely needed to use it in isolation, so I've pushed it up to 4 to match. (Yes Leon, you were right all along.)
You can't use progs that have no effect. This seemed like a reasonable constraint to prevent some accidental moves and help people learn the rules. I was worried it might be too "hand-holdy" but the game's hard enough. (Now I'm not sure how much it did help with learning - it makes the rules for when you can use a prog complex rather than just "do you have enough resources", so some people were confused about why you can sometimes but not others.) Anyway this ended up giving me a whole lot of bugs, situations where something was permitted but shouldn't be or vice versa. And there was the question of what to do when the player didn't know whether there was an effect: when there's an invisible Cryptog that might be affected it could give away its position. I decided to make it not give away information and just permit things when a Cryptog is out of sight, but I put an OR instead of an AND and it was doing this whenever one was on screen at all. Also I'd forgotten to add this to the .DEBUG check since usually they won't be affected unless you've done something special, but for consistency it should apply there too. This is so so minor but hey perfectionism.
ALSO IT'S ON SALE YEAH?
Got back to finishing off Helix. Mostly boring technical stuff: it was born in a jam and was in some parts quite inefficient, so even though it ran fine on my ipad it was a bit slow when I put it on my ipodtouch and I had to figure out why and optimise. Main thing was I was drawing everything on the CPU and then just uploading one big texture for the whole screen, so I shifted some of that work to the GPU and it was suddenly way faster. (Except, for some reason, on the ipad1 - so I ended up using the old method for that WHAT THE HECK.) And then for some reason on the iphone5 the colours got messed up but I just changed ten different things and it worked and I don't know why. Thing is, I have an ipad2 and an ipodtouch but there's all these other models things can go wrong on and I rely on other people to let me know and I don't want to waste too much of their time (and mine) changing something / uploading a build / sending a message / waiting for a reply. The simulator picks up some things but not everything and also it's slow as heck.
Andrew Toups is doing sounds for it, he did the music for Tim Rogers' ZIGGURAT which is amazing and Tim introduced us. Anyway he's doing some last few things and I'm trying to deal with some nonsense (it does have the image mentioned, I don't understand) and then we'll be good to go; release early October.
Ugh this game's been hanging on far too long, it feels good to be finally purging it. This and the 868-HACK PC release (which will happen some time honest) have been getting in the way of me doing new things and it's frustrating, I miss two years ago when I was constantly making things. Although I get paid now so that's a definite plus.
Okay the other thing
the important thing
I don't know what to say just
be kind
love
okay a while back i'd done a talk somewhere and i was reading some responses on twitter afterwards, i clicked on one of them and someone had replied to it in quite a nasty fashion
it seemed a non-sequitur
but then i looked at the rest of their tweets and there were dozens, all directed at the same woman, full of the most horrific violent threats and insults
i read them
i fucking read all of them
i was pretty certain she wouldn't have, she'd probably just blocked him immediately, you get pretty quick at blocking when you endure this kind of harassment
but i read them
and i sat there in the corner, by myself in a room full of people, shaking
just shaking
she's one of the gentlest people i've ever met and even if she wasn't nobody deserves that
nobody
and this is a thing that happens regularly, if you're a woman on the internet
i've seen it a bunch of times since. messages directed at women. always women.
and it's not okay
so if you're criticising someone, anyone but especially women because that's who get this all the time, bear in mind this context
even if you think you have a valid point, maybe you do, i'm not saying anyone's above criticism, but when you come in the middle of this sickening stream of abuse you have to make an effort not to be part of it
and sometimes just don't, just be quiet because others are already making enough noise
and if you're one of the people writing this abuse
you are the problem
not women infiltrating games
not 'social justice warlocks'
you are
stop
you're above this. you're a human being. have dignity. you don't need to do this.
stop it
you can change. we all do bad things, that's part of life, you have to admit that you were wrong, turn aside and do better. when you realise you're wrong it's easy to go into anger and denial. it's hard to change. but it's worth doing things that are hard, you become more than you were. please.
It was possible to get the tutorial frozen by dying on the step that advanced to a new message. I saw it when showing the game to someone last week, nobody had reported it but chances are it had happened to someone and ruined the game for them completely. I try to be thorough, and have some wonderful people who help test things for me too, but it's really hard to avoid things like this completely. Practically you have to look at the odds and accept a few people having a bad experience in exchange for ever actually getting around to releasing the damn thing but it still feels bad. So if you ran into that: sorry.
I'd justified .PULL having a lower acquisition cost than .PUSH because, although it combos well with some attacks, in isolation it's riskier to move enemies towards you than away (thought I'd written that in this post but apparently not; maybe I edited it out). But I was finding myself using it all the time, because it's so easy to find a combo for it I rarely needed to use it in isolation, so I've pushed it up to 4 to match. (Yes Leon, you were right all along.)
You can't use progs that have no effect. This seemed like a reasonable constraint to prevent some accidental moves and help people learn the rules. I was worried it might be too "hand-holdy" but the game's hard enough. (Now I'm not sure how much it did help with learning - it makes the rules for when you can use a prog complex rather than just "do you have enough resources", so some people were confused about why you can sometimes but not others.) Anyway this ended up giving me a whole lot of bugs, situations where something was permitted but shouldn't be or vice versa. And there was the question of what to do when the player didn't know whether there was an effect: when there's an invisible Cryptog that might be affected it could give away its position. I decided to make it not give away information and just permit things when a Cryptog is out of sight, but I put an OR instead of an AND and it was doing this whenever one was on screen at all. Also I'd forgotten to add this to the .DEBUG check since usually they won't be affected unless you've done something special, but for consistency it should apply there too. This is so so minor but hey perfectionism.
ALSO IT'S ON SALE YEAH?
Got back to finishing off Helix. Mostly boring technical stuff: it was born in a jam and was in some parts quite inefficient, so even though it ran fine on my ipad it was a bit slow when I put it on my ipodtouch and I had to figure out why and optimise. Main thing was I was drawing everything on the CPU and then just uploading one big texture for the whole screen, so I shifted some of that work to the GPU and it was suddenly way faster. (Except, for some reason, on the ipad1 - so I ended up using the old method for that WHAT THE HECK.) And then for some reason on the iphone5 the colours got messed up but I just changed ten different things and it worked and I don't know why. Thing is, I have an ipad2 and an ipodtouch but there's all these other models things can go wrong on and I rely on other people to let me know and I don't want to waste too much of their time (and mine) changing something / uploading a build / sending a message / waiting for a reply. The simulator picks up some things but not everything and also it's slow as heck.
Andrew Toups is doing sounds for it, he did the music for Tim Rogers' ZIGGURAT which is amazing and Tim introduced us. Anyway he's doing some last few things and I'm trying to deal with some nonsense (it does have the image mentioned, I don't understand) and then we'll be good to go; release early October.
Ugh this game's been hanging on far too long, it feels good to be finally purging it. This and the 868-HACK PC release (which will happen some time honest) have been getting in the way of me doing new things and it's frustrating, I miss two years ago when I was constantly making things. Although I get paid now so that's a definite plus.
Okay the other thing
the important thing
I don't know what to say just
be kind
love
okay a while back i'd done a talk somewhere and i was reading some responses on twitter afterwards, i clicked on one of them and someone had replied to it in quite a nasty fashion
it seemed a non-sequitur
but then i looked at the rest of their tweets and there were dozens, all directed at the same woman, full of the most horrific violent threats and insults
i read them
i fucking read all of them
i was pretty certain she wouldn't have, she'd probably just blocked him immediately, you get pretty quick at blocking when you endure this kind of harassment
but i read them
and i sat there in the corner, by myself in a room full of people, shaking
just shaking
she's one of the gentlest people i've ever met and even if she wasn't nobody deserves that
nobody
and this is a thing that happens regularly, if you're a woman on the internet
i've seen it a bunch of times since. messages directed at women. always women.
and it's not okay
so if you're criticising someone, anyone but especially women because that's who get this all the time, bear in mind this context
even if you think you have a valid point, maybe you do, i'm not saying anyone's above criticism, but when you come in the middle of this sickening stream of abuse you have to make an effort not to be part of it
and sometimes just don't, just be quiet because others are already making enough noise
and if you're one of the people writing this abuse
you are the problem
not women infiltrating games
not 'social justice warlocks'
you are
stop
you're above this. you're a human being. have dignity. you don't need to do this.
stop it
you can change. we all do bad things, that's part of life, you have to admit that you were wrong, turn aside and do better. when you realise you're wrong it's easy to go into anger and denial. it's hard to change. but it's worth doing things that are hard, you become more than you were. please.
Saturday, 19 July 2014
Corrypt post-cariem
Okay Pippin wanted me to finish writing this, ugh it's way too many words and it's been a while so no promises on accuracy, chances are I remember some things totally wrong.
Will assume you've played Corrypt because spoilers or whatever. Play Game Title and Lost Levels too if you want but it matters less.
In general I make games because I want to play them myself, which means fixed content is pretty much out - I'll know what's there so it can't surprise me. Also there's a cost to making it. So: procedural. But not necessarily in the specific limited sense of writing software to build worlds, the way the term's often used ("procedural" means done by a program and "content" means stuff so PCG is a pretty silly buzzword since it could describe any software or system); the thing is that's actually a huge time investment as well, it takes a long time to cost less than just making things directly. What I try to do is make games where interesting structures grow through the players' actions without needing to be prepared in advance (an arrangement of pieces in e.g. chess is content, the rules describe a procedure to generate them). Or else really simple randomisation like shuffling a deck of cards - Zaga-33 and 868-HACK's levels are generated in the simplest way.
Corrypt (along with the Game Titles) is an exception: I made levels. It was a ton of work and it's clear why I don't do that very often. But it still has that element of generating structure through what the player does, changing the level layout in a chaotic way, which keeps it a bit more interesting for me than static puzzles.
I talked a bit about how the idea evolved through Game Title to Lost Levels to Corrypt in this interview, will try not to repeat myself.
Game Title was for a jam so basically I threw things in quickly without much planning. Mostly basic lock/key interactions - open the door, get through the forcefield, destroy the wall. I tried to do some hidden areas but didn't end up with anything more interesting than "bump into every wall to find the secret", I didn't have the tools to signpost them in a way that was clear enough to notice but ambiguous enough to be non-trivial. Best thing was the teleporter, allowed for a maze that wasn't really difficult but was interesting to perceive.
Lost Levels turned out really enjoyable to make, it was this difficult problem to arrange levels bearing in mind how the positions of objects on different screens could interact. It's not interesting for me to play; I know the solutions because I set them up; but sometimes it's worth making things just for the sake of them being hard to make.
I prototyped another puzzle trying to take the superposition idea further: certain tiles in each room (the monochrome areas in this image) were a void that carried over whatever had been in that position in the previous room. So there were multiple possible versions of each room depending on which direction you entered it from (and, if adjacent rooms had voids in the same place, where you'd entered those from etc.). It didn't work out, it was completely dependent on levels being designed to let things happen and you could feel it, you were just finding the path I'd prepared for you not doing anything for yourself. Wasn't interesting to play and - more importantly - wasn't interesting to make.
One approach I find appealing is to give a very open-ended toolkit for construction - see Spacechem for example - so the challenges are more like real engineering problems than mere puzzles. I got to thinking about combining a construction game with the Game Title ideas, basically Spacechem with an avatar and the goal of the machine you build is to open the way for you, plus glitches. Also I was thinking about a still-unreleased game by Alan Hazelden which this beautiful interlocking thing that grows until it must be all solved at once, the idea of the whole thing converging into a single puzzle is pretty, Riven had something of that feeling too towards the end.
Started by just throwing in some elements to see how they would combine. First sokoban box-pushing as a simple thing to do. Then the "dart" creatures, I was thinking of these as computational elements, they carry one bit of information (whether they turn right or left) and you could set a magic switch tile to flip that bit when passed over. Flipping didn't stay in so they ended up kind of under-explored, but I kept them because I liked how they interacted with the boxes. Had a couple of other tile attributes you could set, by far the most interesting was "lock this so it doesn't change" - new variation on the Lost Levels / void mechanic. Putting the player in control of which tiles locked was way better than predefining them in fixed levels.
It rapidly became clear that glitching tiles like this didn't really mix with the idea of setting up delicate computational engines so I just focused on this. But there were a few puzzles with the darts I thought were interesting enough to keep, and they were too rigid to just be able to throw a different tile into without breaking them, so it made sense to put them first and introduce ＊ＭＡＧＩＣ＊ later. And anyway to provide a choice of what to lock into each tile position you needed access to a few different rooms, so it made made sense that you'd acquiring that later. Plus I'd started to think about a loose narrative to fit this corrupting pollution into, and for its destructive power to mean something the world needed to be set up first, it became a priority to make it feel worldy.
I was reluctant to add an undo button because of this worldiness priority; being able to arbitrarily turn back time costs verisimilitude. I tried to just make sure puzzles couldn't get into unwinnable states. Added box-pulling in an attempt to make sokoban reversible - which didn't work: if you pull a box towards another and end up between them then pushing the first one back now pulls the second; but I didn't think this through at first. But anyway the better puzzles I found could get stuck, so undo was just kind of unavoidable out of basic politeness.
I tried making just ＊ＭＡＧＩＣ＊ immune to undo. Pretty exciting, doing permanent irreparable damage. (Best of all - you'd end up carrying a negative number of mushrooms if you rewound to before you'd collected the ones you'd spent on the magic you'd used.) I loved the idea of maybe having puzzles that required using undo as a tool, and maybe just breaking the game forever, but nobody else could tolerate it so it had to go. It was pretty bad, people would experiment not knowing what ＊ＭＡＧＩＣ＊ would do and then just be stuck, there was no space to learn. It's like the least reversible part of the game, the most in need of undo. (I'm now somewhat satisfied by 868-HACK having .UNDO as a constructive ability.)
So how undo ended up working isn't completely ideal. Most conventional puzzles these days undo individual steps because repeating from the start of a room isn't interesting, but here with ＊ＭＡＧＩＣ＊ you often want to undo something you did in a different room so you need to undo big chunks. I could have done multiple scales of undo but that seemed unnecessary complexity. A lot of people got confused that it returns the room you're in to the state it was when you most recently entered it, rather than its original state - so if you leave something in a bad position and go away, when you come back it'll still be there. This isn't ideal, but resetting rooms would be much stranger given that they can be part of multiple interlocking puzzles, and maybe you've magicked objects over from different rooms, what happens to them? The only thing that really makes sense is to just have a single linear timeline.
Basically this possibility of getting stuck and having to unravel quite a way is the cost of having everything interconnected; worth imo. And it's fine with me if it makes the game a bit spiky and hostile, that's appropriate, I really don't care if someone doesn't "get to the end" or whatever not my problem.
World map was initially quite a bit bigger (bottom right of that image), 7x7x2, I just didn't have enough stuff to fill all that space. Like the forest was 9 screens instead of 2 without anything extra happening in it. Compress.
First screen introduces the box behaviour, pushing and pulling.
Cringed a bit watching the few mainstream sites that covered it try to explain what the fuss was about without bothering to play it. The thing that you discover on the first screen, that's probably it I guess. Ah well.
Second screen tells you that box movement is recursive. Actually this rule showed up unplanned because I'd reused code from Glitch Tank, but it seemed legit so I kept it. Of course, it makes box-pulling even less reversible.
Some people criticised the game for not having a tutorial, maybe if I'd written TUTORIAL in large font across these first few screens they'd have noticed.
So, the dart puzzles.
This version has three solutions (use the dart to put the box on the button, use the box to put the dart on the button, use your body to direct the dart to the button and run quickly to the exit); the first two both seemed interesting so I separated them out, it was quite tricky to find configurations that allowed one but prevented the other. The third didn't interest me at all and was very difficult to eradicate from all the variations on this design. Also, if you get the box pushed to the wrong part, it can let the dart escape out into the corridor at the left where it's just annoying.
Moving the button two spaces away from the edge prevents the box deflecting the dart onto it. And putting two wall tiles at the top end stops the dart escaping. But in this version it's really easy to race to the exit, only 5 steps.
This is pretty good - the river is as short as it can be (it only needs to be two spaces from one end), there's a nice long route to the exit so you can't run it, but the problem is the space you need to manipulate the box in the bottom left is also enough to rotate the child later on - it's more interesting for that puzzle to require going to the next room. Also the dart can escape again.
The final version. Box can't send dart to button, child must go to next room, narrow opening and extra water mean dart can't escape. It's 7 steps to race to the exit, which wasn't quite enough so I increased the dart speed a little (could have done that with some of the others too but it would have had to be very fast).
This one went through similar iterations. You can get it stuck by pushing the box over - it should be possible to anticipate this but everyone tries it anyway - so UNDO becomes necessary here. I added a message, detecting this and reminding about undo, so nobody would leave it like that. Good to introduce the concept that something can get irrevocably stuck because constant paranoia about trapping yourself is an interesting way to approach ＊ＭＡＧＩＣ＊.
This one was the hardest of the three, so awkward to rule out the other methods.
Ended up with two solutions, one of which needs the dart to both push and pull, the other is push-only. Since it's harder ideally it would come after the other two, but when I was arranging the map I couldn't find room to gate this while also having things fairly open and non-linear. I'm okay with that because maybe it's interesting to encounter an obstacle that requires concepts you don't have yet, so you can realise you don't and come back later - or maybe figure it all out at once like a pro.
The first couple of rooms in the mines were just meant to be reminders that you can push and pull, probably superfluous.
I really liked how in Engage to Jabberwock you'd often see passages that you can't reach yet, it's all laid out on a grid really cleverly, I was trying to get that same feeling here.
I like this one because there's a sequence of moves you can do which each feels like making progress but which take you around in a circle. Some players go around that circle several times before realising and stepping back. Also I like leaving the boxes organised like this, though you don't need to.
Tried to make this look intimidating with lots and lots of boxes, but it's actually completely straightforward.
This is about how pushing a box next to another is irreversible. I like that you can get the mushroom but then find yourself trapped.
This is the only (pre-＊ＭＡＧＩＣ＊) puzzle that's actually hard. I kind of wanted to show yes I can do really hard puzzles if I want, that's not the point but yes I can. I mean this whole thing is basically game designer braggadocio, whatever. It's optional.
Anyway I think of the rows of boxes shifting back and forth as like pistons pumping, it has the feeling of operating heavy machinery.
And yeah this one can get stuck too, no way around that really, what's nice/cruel about it is it's not at all obvious when you do get stuck so you can waste a lot of time on it after that without realising. This is a warning about a way we often approach puzzles in videogames, pushing buttons and hoping to get through without bothering to think; here you can't trust that something is always possible and so thinking is mandatory. It's all about instilling that paranoia for when ＊ＭＡＧＩＣ＊ comes and makes everything much worse. Maybe I should have included a room that looks much like all the others but actually starts unsolvable, to really get this across.
I found some pictures of earlier versions I guess.
This one's interesting because depending on which position you enter the room it can be a lot more difficult, you might have to go off the screen and come back to adjust the mimic's relative position (because it only copies you when you're on the same screen). I should have made more out of that.
This is the other puzzle that's a bit hard, but mostly just because it takes a lot of steps most of which you don't have to think about and the one you *do* have to think about doesn't look obviously different. It's like that Nethack thing where you're grinding through trivial enemies then suddenly you're facing death. This probably isn't interesting to solve but it was to set up.
The nice thing with the child is sometimes you have to return to a previous room to get her in the correct orientation to proceed. This tripped up some players pretty well because they assume that what looks like progress is progress (especially on the rooms that had been dart puzzles, because "I've already solved this room"); I like too how the first forest room is just a pleasant ramble going in but turns into a puzzle on the way out. Guess it's a bit like how once you get one face of a Rubik's cube you have to break it up to get further, but less interesting.
Apart from that I kind of used all the tricks on the right half of this screen already, maybe a bit hasty.
Finished up the pre-＊ＭＡＧＩＣ＊ section with a couple of puzzles that combine most of the elements introduced so far. They're not great but it seemed important to do combinations anyway.
The magician is rich with many mushrooms. You might think you're clever for stealing them then selling them back to him but he know's what's up, he's getting what he wants anyway.
I had a few people report ＊ＭＡＧＩＣ＊ as a bug, figuring out its exact behaviour and letting me know, it's pretty much unplayable at this point because I have this glitch in the same place on every screen, really liked it before this happened, hope this'll help you track it down, looking forward to an update fixing this problem!
Fun.
Lot of people didn't make it to ＊ＭＡＧＩＣ＊ at all, that's cool with me; it feels special because it's not apparent on the surface. I'm happy with the game before that point too, it's just puzzles but they're decent ones. They're not hard but it's totally okay if they're not your thing.
Some of the rooms afflict you with ＊ＭＡＧＩＣ＊ the first time you visit them. I felt this was necessary to introduce the mechanic before putting the player in charge, but maybe it's a bit hand-holdy. It's kind of unsatisfactory really, and way over-used, definitely one of the weakest points. The concept was like maybe it's something the magicians have done already just lying around and then it gets stuck to you? Anyway it meant I could plan around some positions, making sure they lined up with walls in convenient or inconvenient ways, have a few partially-constructed puzzles before going full chaos, that seemed useful at the time.
One of them erases the mother. I wanted a character to be erased for HORROR PURPOSES, it would have been nicer to have it be entirely the player's fault but I couldn't make that happen, probably I should have made more effort to predict them and set something up.
One tester went back to the start before going here, and picked up another piece of forced magic which overwrote the button so they couldn't get the key. I rearranged that room ("WAREHOUSE") to shift the forced magic down to prevent that happening, but it made its layout a bit clumsier (also easier to get stuck in, if the dart follows you up the ladder).
The forced ＊ＭＡＧＩＣ＊ wall makes getting out harder; I thought this was pretty nice to have an unexpected obstacle appear like that. But it also means you can't get back in if you leave without getting the key, not ideal but pretty rare; I accept some probability of bad things happen.
It's interesting to have a ＊ＭＡＧＩＣ＊ wall to deal with and you'd never make one yourself intentionally (which is really a weakness of the design - it'd be better to have reasons to want both).
Once you have ＊ＭＡＧＩＣ＊ it doesn't allow for fixed puzzles, instead I just tried to make there be enough obstacles around in different coordinate positions that you'll run into some of them no matter what you've done. The mobile creatures especially are good at getting in your way. Also just tried to be really careful placing walls so that you can't open up everything at once. I had this map drawn on paper with the 9x9 grid counting how many rooms had a wall/mushroom/enemy in each position to make sure they were spread out well, can't find it now probably it's in Scotland somewhere. I remember there were some specific coordinates I got really angry at but I've forgotten which ones now.
At some point I realised I had a red key, score thing, magic door but NOT skeleton, so to carefully fit the authentic definition of game I added skeleton; this was a good addition because skeleton is very good at providing obstacle even with much magic.
The dart in this room is in a cute setup: a wheel. It constantly cycles the three boxes around and around (incidentally turning the switches on and off). By the time you reached this room you'd probably ruined everything anyway so you might not have seen it in action, it's just there as a novelty I guess, there's no purpose for it, I didn't find a way to fit it into a puzzle, it might have been a neat way to do a timer if this had stayed a Spacechem-like.
Spent lots of time trying to balance the economy, by adding just a few more mushrooms in walls or whatever. This started to feel more like balancing a strategy game than designing puzzles, because it didn't matter exactly where they were they just had to be spread out across different coordinates and gated by different walls, and there had to be enough of them to get through even if you made some mistakes but not so many it became trivial. The increasing price at the magicians helps control how it grows here, as you open up more of the world you have to explore further to find what you need. There are are several caches of many mushrooms: whichever you find first will supply ~3 ＊ＭＡＧＩＣ＊ while the later ones might just give 1. Played it lots of times from the checkpoint trying different approaches, if I ran out of mushrooms I'd place a new one somewhere that was accessible with whatever I'd done differently that time. This was a whole bunch of work but I don't have a record of it (aside from the final game) because it was very fluid and intuitive, editing it as I played it. Got pretty sick of the game at this point, since even though it was a bit different with different choices it wasn't that different and it took a lot of replays to get it satisfactory.
At first I had both ladders in the same position to simplify the problem of designing levels, but then of course that made it very easy to erase them both and get stuck on one level, they had to be in different positions. You can still erase them both but it's much less likely.
Okay.
Will assume you've played Corrypt because spoilers or whatever. Play Game Title and Lost Levels too if you want but it matters less.
In general I make games because I want to play them myself, which means fixed content is pretty much out - I'll know what's there so it can't surprise me. Also there's a cost to making it. So: procedural. But not necessarily in the specific limited sense of writing software to build worlds, the way the term's often used ("procedural" means done by a program and "content" means stuff so PCG is a pretty silly buzzword since it could describe any software or system); the thing is that's actually a huge time investment as well, it takes a long time to cost less than just making things directly. What I try to do is make games where interesting structures grow through the players' actions without needing to be prepared in advance (an arrangement of pieces in e.g. chess is content, the rules describe a procedure to generate them). Or else really simple randomisation like shuffling a deck of cards - Zaga-33 and 868-HACK's levels are generated in the simplest way.
Corrypt (along with the Game Titles) is an exception: I made levels. It was a ton of work and it's clear why I don't do that very often. But it still has that element of generating structure through what the player does, changing the level layout in a chaotic way, which keeps it a bit more interesting for me than static puzzles.
I talked a bit about how the idea evolved through Game Title to Lost Levels to Corrypt in this interview, will try not to repeat myself.
Game Title was for a jam so basically I threw things in quickly without much planning. Mostly basic lock/key interactions - open the door, get through the forcefield, destroy the wall. I tried to do some hidden areas but didn't end up with anything more interesting than "bump into every wall to find the secret", I didn't have the tools to signpost them in a way that was clear enough to notice but ambiguous enough to be non-trivial. Best thing was the teleporter, allowed for a maze that wasn't really difficult but was interesting to perceive.
Lost Levels turned out really enjoyable to make, it was this difficult problem to arrange levels bearing in mind how the positions of objects on different screens could interact. It's not interesting for me to play; I know the solutions because I set them up; but sometimes it's worth making things just for the sake of them being hard to make.
I prototyped another puzzle trying to take the superposition idea further: certain tiles in each room (the monochrome areas in this image) were a void that carried over whatever had been in that position in the previous room. So there were multiple possible versions of each room depending on which direction you entered it from (and, if adjacent rooms had voids in the same place, where you'd entered those from etc.). It didn't work out, it was completely dependent on levels being designed to let things happen and you could feel it, you were just finding the path I'd prepared for you not doing anything for yourself. Wasn't interesting to play and - more importantly - wasn't interesting to make.
One approach I find appealing is to give a very open-ended toolkit for construction - see Spacechem for example - so the challenges are more like real engineering problems than mere puzzles. I got to thinking about combining a construction game with the Game Title ideas, basically Spacechem with an avatar and the goal of the machine you build is to open the way for you, plus glitches. Also I was thinking about a still-unreleased game by Alan Hazelden which this beautiful interlocking thing that grows until it must be all solved at once, the idea of the whole thing converging into a single puzzle is pretty, Riven had something of that feeling too towards the end.
Started by just throwing in some elements to see how they would combine. First sokoban box-pushing as a simple thing to do. Then the "dart" creatures, I was thinking of these as computational elements, they carry one bit of information (whether they turn right or left) and you could set a magic switch tile to flip that bit when passed over. Flipping didn't stay in so they ended up kind of under-explored, but I kept them because I liked how they interacted with the boxes. Had a couple of other tile attributes you could set, by far the most interesting was "lock this so it doesn't change" - new variation on the Lost Levels / void mechanic. Putting the player in control of which tiles locked was way better than predefining them in fixed levels.
It rapidly became clear that glitching tiles like this didn't really mix with the idea of setting up delicate computational engines so I just focused on this. But there were a few puzzles with the darts I thought were interesting enough to keep, and they were too rigid to just be able to throw a different tile into without breaking them, so it made sense to put them first and introduce ＊ＭＡＧＩＣ＊ later. And anyway to provide a choice of what to lock into each tile position you needed access to a few different rooms, so it made made sense that you'd acquiring that later. Plus I'd started to think about a loose narrative to fit this corrupting pollution into, and for its destructive power to mean something the world needed to be set up first, it became a priority to make it feel worldy.
I was reluctant to add an undo button because of this worldiness priority; being able to arbitrarily turn back time costs verisimilitude. I tried to just make sure puzzles couldn't get into unwinnable states. Added box-pulling in an attempt to make sokoban reversible - which didn't work: if you pull a box towards another and end up between them then pushing the first one back now pulls the second; but I didn't think this through at first. But anyway the better puzzles I found could get stuck, so undo was just kind of unavoidable out of basic politeness.
I tried making just ＊ＭＡＧＩＣ＊ immune to undo. Pretty exciting, doing permanent irreparable damage. (Best of all - you'd end up carrying a negative number of mushrooms if you rewound to before you'd collected the ones you'd spent on the magic you'd used.) I loved the idea of maybe having puzzles that required using undo as a tool, and maybe just breaking the game forever, but nobody else could tolerate it so it had to go. It was pretty bad, people would experiment not knowing what ＊ＭＡＧＩＣ＊ would do and then just be stuck, there was no space to learn. It's like the least reversible part of the game, the most in need of undo. (I'm now somewhat satisfied by 868-HACK having .UNDO as a constructive ability.)
So how undo ended up working isn't completely ideal. Most conventional puzzles these days undo individual steps because repeating from the start of a room isn't interesting, but here with ＊ＭＡＧＩＣ＊ you often want to undo something you did in a different room so you need to undo big chunks. I could have done multiple scales of undo but that seemed unnecessary complexity. A lot of people got confused that it returns the room you're in to the state it was when you most recently entered it, rather than its original state - so if you leave something in a bad position and go away, when you come back it'll still be there. This isn't ideal, but resetting rooms would be much stranger given that they can be part of multiple interlocking puzzles, and maybe you've magicked objects over from different rooms, what happens to them? The only thing that really makes sense is to just have a single linear timeline.
Basically this possibility of getting stuck and having to unravel quite a way is the cost of having everything interconnected; worth imo. And it's fine with me if it makes the game a bit spiky and hostile, that's appropriate, I really don't care if someone doesn't "get to the end" or whatever not my problem.
World map was initially quite a bit bigger (bottom right of that image), 7x7x2, I just didn't have enough stuff to fill all that space. Like the forest was 9 screens instead of 2 without anything extra happening in it. Compress.First screen introduces the box behaviour, pushing and pulling.
Cringed a bit watching the few mainstream sites that covered it try to explain what the fuss was about without bothering to play it. The thing that you discover on the first screen, that's probably it I guess. Ah well.
Second screen tells you that box movement is recursive. Actually this rule showed up unplanned because I'd reused code from Glitch Tank, but it seemed legit so I kept it. Of course, it makes box-pulling even less reversible.
Some people criticised the game for not having a tutorial, maybe if I'd written TUTORIAL in large font across these first few screens they'd have noticed.
So, the dart puzzles.
This version has three solutions (use the dart to put the box on the button, use the box to put the dart on the button, use your body to direct the dart to the button and run quickly to the exit); the first two both seemed interesting so I separated them out, it was quite tricky to find configurations that allowed one but prevented the other. The third didn't interest me at all and was very difficult to eradicate from all the variations on this design. Also, if you get the box pushed to the wrong part, it can let the dart escape out into the corridor at the left where it's just annoying.
Moving the button two spaces away from the edge prevents the box deflecting the dart onto it. And putting two wall tiles at the top end stops the dart escaping. But in this version it's really easy to race to the exit, only 5 steps.
This is pretty good - the river is as short as it can be (it only needs to be two spaces from one end), there's a nice long route to the exit so you can't run it, but the problem is the space you need to manipulate the box in the bottom left is also enough to rotate the child later on - it's more interesting for that puzzle to require going to the next room. Also the dart can escape again.
The final version. Box can't send dart to button, child must go to next room, narrow opening and extra water mean dart can't escape. It's 7 steps to race to the exit, which wasn't quite enough so I increased the dart speed a little (could have done that with some of the others too but it would have had to be very fast).
This one went through similar iterations. You can get it stuck by pushing the box over - it should be possible to anticipate this but everyone tries it anyway - so UNDO becomes necessary here. I added a message, detecting this and reminding about undo, so nobody would leave it like that. Good to introduce the concept that something can get irrevocably stuck because constant paranoia about trapping yourself is an interesting way to approach ＊ＭＡＧＩＣ＊.
This one was the hardest of the three, so awkward to rule out the other methods.
Ended up with two solutions, one of which needs the dart to both push and pull, the other is push-only. Since it's harder ideally it would come after the other two, but when I was arranging the map I couldn't find room to gate this while also having things fairly open and non-linear. I'm okay with that because maybe it's interesting to encounter an obstacle that requires concepts you don't have yet, so you can realise you don't and come back later - or maybe figure it all out at once like a pro.
The first couple of rooms in the mines were just meant to be reminders that you can push and pull, probably superfluous.
I really liked how in Engage to Jabberwock you'd often see passages that you can't reach yet, it's all laid out on a grid really cleverly, I was trying to get that same feeling here.
I like this one because there's a sequence of moves you can do which each feels like making progress but which take you around in a circle. Some players go around that circle several times before realising and stepping back. Also I like leaving the boxes organised like this, though you don't need to.
Tried to make this look intimidating with lots and lots of boxes, but it's actually completely straightforward.
This is about how pushing a box next to another is irreversible. I like that you can get the mushroom but then find yourself trapped.
This is the only (pre-＊ＭＡＧＩＣ＊) puzzle that's actually hard. I kind of wanted to show yes I can do really hard puzzles if I want, that's not the point but yes I can. I mean this whole thing is basically game designer braggadocio, whatever. It's optional.
Anyway I think of the rows of boxes shifting back and forth as like pistons pumping, it has the feeling of operating heavy machinery.
And yeah this one can get stuck too, no way around that really, what's nice/cruel about it is it's not at all obvious when you do get stuck so you can waste a lot of time on it after that without realising. This is a warning about a way we often approach puzzles in videogames, pushing buttons and hoping to get through without bothering to think; here you can't trust that something is always possible and so thinking is mandatory. It's all about instilling that paranoia for when ＊ＭＡＧＩＣ＊ comes and makes everything much worse. Maybe I should have included a room that looks much like all the others but actually starts unsolvable, to really get this across.
I found some pictures of earlier versions I guess.
This one's interesting because depending on which position you enter the room it can be a lot more difficult, you might have to go off the screen and come back to adjust the mimic's relative position (because it only copies you when you're on the same screen). I should have made more out of that.
This is the other puzzle that's a bit hard, but mostly just because it takes a lot of steps most of which you don't have to think about and the one you *do* have to think about doesn't look obviously different. It's like that Nethack thing where you're grinding through trivial enemies then suddenly you're facing death. This probably isn't interesting to solve but it was to set up.
The nice thing with the child is sometimes you have to return to a previous room to get her in the correct orientation to proceed. This tripped up some players pretty well because they assume that what looks like progress is progress (especially on the rooms that had been dart puzzles, because "I've already solved this room"); I like too how the first forest room is just a pleasant ramble going in but turns into a puzzle on the way out. Guess it's a bit like how once you get one face of a Rubik's cube you have to break it up to get further, but less interesting.
Apart from that I kind of used all the tricks on the right half of this screen already, maybe a bit hasty.
Finished up the pre-＊ＭＡＧＩＣ＊ section with a couple of puzzles that combine most of the elements introduced so far. They're not great but it seemed important to do combinations anyway.
The magician is rich with many mushrooms. You might think you're clever for stealing them then selling them back to him but he know's what's up, he's getting what he wants anyway.
I had a few people report ＊ＭＡＧＩＣ＊ as a bug, figuring out its exact behaviour and letting me know, it's pretty much unplayable at this point because I have this glitch in the same place on every screen, really liked it before this happened, hope this'll help you track it down, looking forward to an update fixing this problem!
Fun.
Lot of people didn't make it to ＊ＭＡＧＩＣ＊ at all, that's cool with me; it feels special because it's not apparent on the surface. I'm happy with the game before that point too, it's just puzzles but they're decent ones. They're not hard but it's totally okay if they're not your thing.
Some of the rooms afflict you with ＊ＭＡＧＩＣ＊ the first time you visit them. I felt this was necessary to introduce the mechanic before putting the player in charge, but maybe it's a bit hand-holdy. It's kind of unsatisfactory really, and way over-used, definitely one of the weakest points. The concept was like maybe it's something the magicians have done already just lying around and then it gets stuck to you? Anyway it meant I could plan around some positions, making sure they lined up with walls in convenient or inconvenient ways, have a few partially-constructed puzzles before going full chaos, that seemed useful at the time.
One of them erases the mother. I wanted a character to be erased for HORROR PURPOSES, it would have been nicer to have it be entirely the player's fault but I couldn't make that happen, probably I should have made more effort to predict them and set something up.
One tester went back to the start before going here, and picked up another piece of forced magic which overwrote the button so they couldn't get the key. I rearranged that room ("WAREHOUSE") to shift the forced magic down to prevent that happening, but it made its layout a bit clumsier (also easier to get stuck in, if the dart follows you up the ladder).
The forced ＊ＭＡＧＩＣ＊ wall makes getting out harder; I thought this was pretty nice to have an unexpected obstacle appear like that. But it also means you can't get back in if you leave without getting the key, not ideal but pretty rare; I accept some probability of bad things happen.
It's interesting to have a ＊ＭＡＧＩＣ＊ wall to deal with and you'd never make one yourself intentionally (which is really a weakness of the design - it'd be better to have reasons to want both).
Once you have ＊ＭＡＧＩＣ＊ it doesn't allow for fixed puzzles, instead I just tried to make there be enough obstacles around in different coordinate positions that you'll run into some of them no matter what you've done. The mobile creatures especially are good at getting in your way. Also just tried to be really careful placing walls so that you can't open up everything at once. I had this map drawn on paper with the 9x9 grid counting how many rooms had a wall/mushroom/enemy in each position to make sure they were spread out well, can't find it now probably it's in Scotland somewhere. I remember there were some specific coordinates I got really angry at but I've forgotten which ones now.
At some point I realised I had a red key, score thing, magic door but NOT skeleton, so to carefully fit the authentic definition of game I added skeleton; this was a good addition because skeleton is very good at providing obstacle even with much magic.
The dart in this room is in a cute setup: a wheel. It constantly cycles the three boxes around and around (incidentally turning the switches on and off). By the time you reached this room you'd probably ruined everything anyway so you might not have seen it in action, it's just there as a novelty I guess, there's no purpose for it, I didn't find a way to fit it into a puzzle, it might have been a neat way to do a timer if this had stayed a Spacechem-like.
Spent lots of time trying to balance the economy, by adding just a few more mushrooms in walls or whatever. This started to feel more like balancing a strategy game than designing puzzles, because it didn't matter exactly where they were they just had to be spread out across different coordinates and gated by different walls, and there had to be enough of them to get through even if you made some mistakes but not so many it became trivial. The increasing price at the magicians helps control how it grows here, as you open up more of the world you have to explore further to find what you need. There are are several caches of many mushrooms: whichever you find first will supply ~3 ＊ＭＡＧＩＣ＊ while the later ones might just give 1. Played it lots of times from the checkpoint trying different approaches, if I ran out of mushrooms I'd place a new one somewhere that was accessible with whatever I'd done differently that time. This was a whole bunch of work but I don't have a record of it (aside from the final game) because it was very fluid and intuitive, editing it as I played it. Got pretty sick of the game at this point, since even though it was a bit different with different choices it wasn't that different and it took a lot of replays to get it satisfactory.
At first I had both ladders in the same position to simplify the problem of designing levels, but then of course that made it very easy to erase them both and get stuck on one level, they had to be in different positions. You can still erase them both but it's much less likely.
Okay.
Tuesday, 24 June 2014
Impossibility
Some things are impossible.
That shouldn't be controversial, but our culture is filled with messages that go against it. Nothing is impossible, you can do whatever your dream, don't give up, just try harder, believe that you can, have faith. Our fiction/mythology is full of people overcoming difficult odds - and impossible is just a harder kind of difficult, even more admirable to inevitably overcome.
And like, that's sometimes a good attitude to have, we've accomplished a bunch of stuff by being persistent and obstinate. "Try harder" can be pretty good advice. But sometimes things that look impossible really are. And if you're attempting something impossible, giving up isn't defeatism - it's the rational thing to do.
(IMPORTANT NOTE: even when something is technically possible, "try harder" can still be bad advice. We know about burnout and depression from working too hard, we know working "crunch time" damages people. Plus it's generally awful to tell someone to work harder from a position of privilege when they're facing obstacles you don't even know OKAY.)
Impossibility is beautiful, because it's so much bigger than possibility. Finding a solution to a problem is a small thing, you can just show it to me. But to claim that there is no solution, that no solution will ever exist, no solution can ever exist, that no amount of ingenuity and effort will solve it - that's enormous.
OKAY what does a genuine impossibility look like?
Guess I'll point you to some classics http://en.wikipedia.org/wiki/Seven_Bridges_of_K%C3%B6nigsberg, http://en.wikipedia.org/wiki/Square_root_of_2, http://en.wikipedia.org/wiki/Squaring_the_circle, http://en.wikipedia.org/wiki/Angle_trisection, you probably know about these already whatever. In general this is something that mathematics does, proving things impossible. And then because humans are bad at accepting impossibilities we still get amateur mathematicians (less charitably, "cranks") trying to square circles and trisect angles because hey the establishment thinks it's impossible but maybe if I just try really hard I'll find something they missed, never mind that it would take a lot less time to verify the proof.
Importantly, these claims are definite but conditional; they say "this is impossible with the methods of Euclidean geometry" or whatever but with different tools you can do the thing. You can't write this as a fraction but sure you can write it some other way, maybe you can build another bridge or a teleporter idk. That doesn't diminish their beauty - like there are infinitely many constructions you can do in geometry and to be able with just a finite amount of work to show none of them square a circle is pretty rad. But yeah it's a thing, the only way we get to be 100% confident that something is true is by tying it down with enough qualifiers. Mathematics is fairly special because we do have those qualifiers, most places we don't and so we can't unambiguously prove impossibilities. Science operates by inventing mathematical models and experimenting to test them against reality - we can prove impossibilities in the model but never be certain whether the world follows the same rules. So while actual definite impossibility exists and is beautiful, it is something alien, we mostly live in an ambiguous world of uncertainty. (Which is not to say things aren't impossible, just we don't get to know for sure.)
Okay this is a blog about games right.
Now games are often power fantasies. Everything in them was placed for us to play with: here's a ledge, you can jump to it / a door, you can open it. Everything you see is possible, it's there for you. If there's a door that's just scenery and can't be opened, that's a failure of the game - and players complain like anything. The "perfect" game is imagined as a wide open space in which anything is possible, that never tells players what they can't do.
Which is fine i guess. But games also have the scope to let things be impossible. They're self-contained systems with fixed rules we can know; so we can prove impossibilities. And I said that's beautiful so okay let's, how?
(Note that the process of creating complex software can obscure what the rules actually are, we can end up with unintended rules - bugs, glitches, exploits. So as @flantz often points out, players end up doing actual science in experimenting to discover the laws of the toy universe, rather than the mathematics of knowing the rules and deducing their implications. In a videogame, the actual rules are what's written on the software, not what the designer or the player had in their head. Board games though, the rules run in the player's minds so they literally are exactly what you think, it's pure mathematics.)
(Lots of videogames do let things be impossible FOR NOW. The metroid thing of areas being inaccessible until you've acquired a new ability. Decent compromise I guess.)
With puzzles, what I usually see people do first is just push buttons, try to solve them without having to think. A good puzzle takes a long time to solve that way but is quickly solved once you think of the right idea, to make you give up and switch your brain on. But if it takes too long to think of the idea you'll just start going through a list of all possibilities, which isn't interesting either.
Now what if it's actually impossible? It can't be solved by button-mashing, you're wasting your time. If the state-space is finite then it can be solved (proven impossible) by exhaustive search, but very slowly - if infinite it can't. A good impossible puzzle would require a long time to be confident it can't be solved by trial and error while being quickly proven impossible once you think of the right idea.
Okay I don't really like puzzles in general and this kind of thinking might lead to things I like more? Looking at a puzzle and not knowing whether it's even solvable, and thus which approach to take, kind of a delicious uncertainty. Trying all possible moves to rule them out is super boring though just as much as trying them all to find the right ones, so that really has to be avoided. But the classic "prove or find a counterexample" topology exam questions are the best so.
Vertex Dispenser was my attempt to put an idea from mathematics into a game somehow more interesting than just make a puzzle like everyone else does. It's this dense knot of ideas, the space you move through in an action game is also the territory you command in a strategy game is also the graph you colour in a puzzle game which feeds resource management for abilities in the action game / the negative space protects the positive and everything's connected. Too weird. Anyway I ended up putting in a bunch of conventional puzzle levels too, I wanted the last one of those to be impossible but was convinced not to. What I did instead was have the level be a collection of ten separate puzzles which you have to solve half of, the rest being impossible - so you have to recognise which ones are possible and solve them while not wasting time on the others.
Maybe that wasn't a good example but here's this idea of recognition. Actually formally proving something is a specialised skill most people lack (it's not scary but it's not instinctive), I'd love to see a game that teaches this but I don't know if you can do it in an interesting way without just being maths, also to verify proofs in software tends to require input in a way that's way less intuitive than what mathematicians usually do so yeah it'll be hard to make a good game out of that (someone do it please). But just requiring recognising impossible situations without proof is still pretty interesting, usually how this works is you find some invariant feature that the allowed moves can't change (parity's a common one), recognition doesn't have the beauty of absolute certainty because a modified trial-and-error approach will still work if you're right most of the time but hey compromise.
Corrypt was getting into this kind of area too - it starts solvable but you can enter unsolvable states and then you have to recognise them and undo, preferably without wasting time on
That shouldn't be controversial, but our culture is filled with messages that go against it. Nothing is impossible, you can do whatever your dream, don't give up, just try harder, believe that you can, have faith. Our fiction/mythology is full of people overcoming difficult odds - and impossible is just a harder kind of difficult, even more admirable to inevitably overcome.
And like, that's sometimes a good attitude to have, we've accomplished a bunch of stuff by being persistent and obstinate. "Try harder" can be pretty good advice. But sometimes things that look impossible really are. And if you're attempting something impossible, giving up isn't defeatism - it's the rational thing to do.
(IMPORTANT NOTE: even when something is technically possible, "try harder" can still be bad advice. We know about burnout and depression from working too hard, we know working "crunch time" damages people. Plus it's generally awful to tell someone to work harder from a position of privilege when they're facing obstacles you don't even know OKAY.)
Impossibility is beautiful, because it's so much bigger than possibility. Finding a solution to a problem is a small thing, you can just show it to me. But to claim that there is no solution, that no solution will ever exist, no solution can ever exist, that no amount of ingenuity and effort will solve it - that's enormous.
OKAY what does a genuine impossibility look like?
Guess I'll point you to some classics http://en.wikipedia.org/wiki/Seven_Bridges_of_K%C3%B6nigsberg, http://en.wikipedia.org/wiki/Square_root_of_2, http://en.wikipedia.org/wiki/Squaring_the_circle, http://en.wikipedia.org/wiki/Angle_trisection, you probably know about these already whatever. In general this is something that mathematics does, proving things impossible. And then because humans are bad at accepting impossibilities we still get amateur mathematicians (less charitably, "cranks") trying to square circles and trisect angles because hey the establishment thinks it's impossible but maybe if I just try really hard I'll find something they missed, never mind that it would take a lot less time to verify the proof.
Importantly, these claims are definite but conditional; they say "this is impossible with the methods of Euclidean geometry" or whatever but with different tools you can do the thing. You can't write this as a fraction but sure you can write it some other way, maybe you can build another bridge or a teleporter idk. That doesn't diminish their beauty - like there are infinitely many constructions you can do in geometry and to be able with just a finite amount of work to show none of them square a circle is pretty rad. But yeah it's a thing, the only way we get to be 100% confident that something is true is by tying it down with enough qualifiers. Mathematics is fairly special because we do have those qualifiers, most places we don't and so we can't unambiguously prove impossibilities. Science operates by inventing mathematical models and experimenting to test them against reality - we can prove impossibilities in the model but never be certain whether the world follows the same rules. So while actual definite impossibility exists and is beautiful, it is something alien, we mostly live in an ambiguous world of uncertainty. (Which is not to say things aren't impossible, just we don't get to know for sure.)
Okay this is a blog about games right.
Now games are often power fantasies. Everything in them was placed for us to play with: here's a ledge, you can jump to it / a door, you can open it. Everything you see is possible, it's there for you. If there's a door that's just scenery and can't be opened, that's a failure of the game - and players complain like anything. The "perfect" game is imagined as a wide open space in which anything is possible, that never tells players what they can't do.
Which is fine i guess. But games also have the scope to let things be impossible. They're self-contained systems with fixed rules we can know; so we can prove impossibilities. And I said that's beautiful so okay let's, how?
(Note that the process of creating complex software can obscure what the rules actually are, we can end up with unintended rules - bugs, glitches, exploits. So as @flantz often points out, players end up doing actual science in experimenting to discover the laws of the toy universe, rather than the mathematics of knowing the rules and deducing their implications. In a videogame, the actual rules are what's written on the software, not what the designer or the player had in their head. Board games though, the rules run in the player's minds so they literally are exactly what you think, it's pure mathematics.)
(Lots of videogames do let things be impossible FOR NOW. The metroid thing of areas being inaccessible until you've acquired a new ability. Decent compromise I guess.)
With puzzles, what I usually see people do first is just push buttons, try to solve them without having to think. A good puzzle takes a long time to solve that way but is quickly solved once you think of the right idea, to make you give up and switch your brain on. But if it takes too long to think of the idea you'll just start going through a list of all possibilities, which isn't interesting either.
Now what if it's actually impossible? It can't be solved by button-mashing, you're wasting your time. If the state-space is finite then it can be solved (proven impossible) by exhaustive search, but very slowly - if infinite it can't. A good impossible puzzle would require a long time to be confident it can't be solved by trial and error while being quickly proven impossible once you think of the right idea.
Okay I don't really like puzzles in general and this kind of thinking might lead to things I like more? Looking at a puzzle and not knowing whether it's even solvable, and thus which approach to take, kind of a delicious uncertainty. Trying all possible moves to rule them out is super boring though just as much as trying them all to find the right ones, so that really has to be avoided. But the classic "prove or find a counterexample" topology exam questions are the best so.
Vertex Dispenser was my attempt to put an idea from mathematics into a game somehow more interesting than just make a puzzle like everyone else does. It's this dense knot of ideas, the space you move through in an action game is also the territory you command in a strategy game is also the graph you colour in a puzzle game which feeds resource management for abilities in the action game / the negative space protects the positive and everything's connected. Too weird. Anyway I ended up putting in a bunch of conventional puzzle levels too, I wanted the last one of those to be impossible but was convinced not to. What I did instead was have the level be a collection of ten separate puzzles which you have to solve half of, the rest being impossible - so you have to recognise which ones are possible and solve them while not wasting time on the others.
Maybe that wasn't a good example but here's this idea of recognition. Actually formally proving something is a specialised skill most people lack (it's not scary but it's not instinctive), I'd love to see a game that teaches this but I don't know if you can do it in an interesting way without just being maths, also to verify proofs in software tends to require input in a way that's way less intuitive than what mathematicians usually do so yeah it'll be hard to make a good game out of that (someone do it please). But just requiring recognising impossible situations without proof is still pretty interesting, usually how this works is you find some invariant feature that the allowed moves can't change (parity's a common one), recognition doesn't have the beauty of absolute certainty because a modified trial-and-error approach will still work if you're right most of the time but hey compromise.
Corrypt was getting into this kind of area too - it starts solvable but you can enter unsolvable states and then you have to recognise them and undo, preferably without wasting time on
Wednesday, 11 June 2014
868-HACK prog costs
Hello I felt like writing something about tuning the costs of the 868-HACK abilities. This is maybe quite boring and nerdy and also it's like lots of words but you don't have to read it ok.
You can see some of the process by comparing the 7-day version 86856527 to the released version (yes it's only on iOS right now I'll do something about that soon) but there's lots of missing bits in between.
Okay the central activity in a roguelike is choosing between different resources to lose - a typical choice is whether to engage in melee (spending hp, risking death) or use an item/magic to avoid it. Classical roguelikes lack many choices about which resources to acquire, you just take what you find and figure out how to use it, but 868-HACK also has the "data siphon" tool giving frequent acquisition choices. I put two currencies (credits and energy) so there'd be a choice of which of those to acquire, but you're also trading those off against abilities and points. (In the original concept energy was for using abilities and credits were for spending between rounds to gain abilities, but it was cleaner to collapse that into siphoning and so the choice just became which abilities to spend them on.)
So okay there were a whole bunch of abilities (the game calls them progs, I'll call them progs now too since it's shorter though a little pompous) and they needed prices, and this is kind of too big a problem. The possibility space is just too large to think about: each prog has a 2d currency cost and also you can change what they do and what they are, how many there are, how they interact. Also working with small numbers rules out cheap statistical effects like "+5% damage"; every small change makes a big difference. Balance is hard. But there's no right answer, probably lots will do fine they'll just be different games.
I started by trying to distinguish the two currencies with a conversion prog (.EXCH) going one way but not the other (credits to energy). Initially gave you 3 for 4, a slightly unfavourable exchange rate, because I thought it should cost something to use to make you think about whether it was worth it. (Could have had a second one in the other direction at a different ratio - 2 for 3? - but also such a direct resource conversion isn't interesting to have very much of, just a little is good.) Eventually it became clear that it was usually a bad choice and it wouldn't hurt to push it up to 4 for 4. I realised there's still a cost to it - the siphon spent and the risk taken acquiring the ability in the first place, and the constraint of having to do it in blocks of 4 (consider: a 100/100 exchange would never be useful, even though it's the same ratio).
This imbalance between the two currencies helped guide later decisions. Because you have the possibility to turn credits into energy you can more likely avoid running out of energy - energy is more reliable, you can sink it into using a prog over and over again, so this determines the types of progs that should use it. If something's main utility is using it several times to set up a combo or get control of a bad situation (.PUSH, .PULL, .STEP) then it should cost energy; if it is interesting to use sparingly with precision after some setup (.DEBUG, .D_BOM, .CRASH) then it costs credits. (Of course you might like to use some of these latter progs with reckless abandon, but they're still valuable when you can't, so.) There ended up being slightly more progs costing credits than energy, which aligns with the idea that energy progs are each used more often (and means there's sometimes pressure to actually find something to spend that energy on).
Having a limited number of enemy types with specific counters was part of the initial concept. I expected to have multiple subtypes within those - several varieties of virus all affected by .ANTI_V or whatever - but keeping it focused with just one of each turned out really well. Started with a counter to each type all at the same price - .ANTI_V, .KIL_D (now D_BOM), .DEBUG, .DCRPT (now .SHOW) all at $$$, and these didn't change drastically. They're in the same currency to force a choice between them: you can't deal with every type at once.
The general pattern that started to come through was: credits for damage, energy for movement/evasion. Not everything fits that pattern but keeping it in mind made many other decisions easier - e.g. .WARP both attacks something and moves something so it costs an even mix, .REDUC and .DELAY are similar in that both make enemy spawns easier to deal with, but .REDUC's cost is weighted towards credits because it prevents enemies outright (pre-destroying them) while .DELAY just holds them at bay in a weakened state. Even though the currencies have different values, I treated it as meaningful for pairs like this to have mirrored costs ($$% and $%%) because it helped simplify the decision of where to put them (other such pairs are .WAIT/.UNDO, .ROW/.COL).
Originally .ROW and .COL only did 1 damage and cost $$% and $%%, and were quite a bit more tactically interesting to use than they are now but so efficient they completely overshadowed the other attack progs (especially since they don't depend on enemy type). I couldn't find a completely satisfactory fix; there wasn't room to weaken the effect and putting up the cost by 1 was enough to leave them pretty underpowered. What I ended up doing seems balanced (which is counterintuitive - an effect is too strong at cost 3 but double the effect is fine at 4? non-linearity, having the effect twice in one go is nowhere near as valuable as having it twice at carefully selected moments) but isn't as fun to play with - but balance makes the game better overall; conservation of fun. .COL costing mainly energy clashes a little with the principle of damage mostly costing credits so to compensate I pushed up the alert cost to 5 (vs .ROW's 4): breaking a pattern merits a higher cost.
.RESET explicitly converts energy to hp, but its efficiency varies situationally: it restores you to 3 so ideally you'd use it when on 1 to maximise the effect, but sometimes you must do it on 2 when you can't avoid being hit twice next turn, or when you only need 1 because you'll restore 1 on leaving the level. Usually (ideally) it gives 1 hp for each 2 energy. Several other progs can be thought of as converting currencies to hp - at different ratios under certain conditions, so how much 1 hp is worth is pretty variable. If there's an enemy one space away from you diagonally so you can't move without being hit, then .WAIT gives 1 hp for just 1 energy (by preventing subtraction rather than by adding). With .PUSH you can very often get a bit more than 1 hp for 2 energy (avoid a hit from a nearby enemy while inconveniencing other enemies). Occasionally you need to use $$$ for 1 hp (with .ANTI-V /.DEBUG/.D_BOM) but usually these can get you quite a lot more. So I think .RESET's 1 hp = 2 energy is kind of a bad deal, but it has reliability in its favour; to emphasise this I put the alert cost really low making it safe and accessible for beginners.
Some thought went into the order in which progs unlock. The initial set has no mixed costs; they're slightly more complex to use (they clash with everything, can't be used if either currency is exhausted), and it seemed like it might make the unlocks feel a bit more special by setting up a pattern then breaking it. Also all the attacks that are independent of enemy type have mixed cost (to compensate for them being more reliable), so this meant the initial set forces you to pay special attention to enemy types which might help with learning their behaviours. When you unlock a new prog you start the next game with it, giving an opportunity to try it out straight away - which meant .SCORE had to be in the initial set because starting with it would give a huge score advantage (some of the others are a bit of a concern too but that's the worst). A side-effect of that though is it's maybe easier to score before you've unlocked everything because .SCORE shows up more reliably, this is hopefully somewhat compensated for by not having .SIPH+. In general the game gets harder as you unlock more stuff; there are some stronger abilities but you're less likely to find something that combines well. I tried to keep the balance of credits/energy fairly even at each stage of unlocking, also tried to leave gaps and then fill them later so someone might have time to wonder what something might be before unlocking it, or when something obvious was coming; no idea if this worked at all.
(For reference, initial set is .WAIT, .SHOW, .PUSH, .STEP, .ANTI-V, .DEBUG, .D_BOM, .RESET, .EXCH, .SCORE and unlock order is .WARP, .POLY, .ROW, .DELAY, .UNDO, .ATK+, .PULL, .CRASH, .COL, .CALM, .REDUC, .HACK, .SIPH+)
NOW I WILL SUM UP SOME IDEAS WITH BULLETPOINTS
You can see some of the process by comparing the 7-day version 86856527 to the released version (yes it's only on iOS right now I'll do something about that soon) but there's lots of missing bits in between.
Okay the central activity in a roguelike is choosing between different resources to lose - a typical choice is whether to engage in melee (spending hp, risking death) or use an item/magic to avoid it. Classical roguelikes lack many choices about which resources to acquire, you just take what you find and figure out how to use it, but 868-HACK also has the "data siphon" tool giving frequent acquisition choices. I put two currencies (credits and energy) so there'd be a choice of which of those to acquire, but you're also trading those off against abilities and points. (In the original concept energy was for using abilities and credits were for spending between rounds to gain abilities, but it was cleaner to collapse that into siphoning and so the choice just became which abilities to spend them on.)
So okay there were a whole bunch of abilities (the game calls them progs, I'll call them progs now too since it's shorter though a little pompous) and they needed prices, and this is kind of too big a problem. The possibility space is just too large to think about: each prog has a 2d currency cost and also you can change what they do and what they are, how many there are, how they interact. Also working with small numbers rules out cheap statistical effects like "+5% damage"; every small change makes a big difference. Balance is hard. But there's no right answer, probably lots will do fine they'll just be different games.
I started by trying to distinguish the two currencies with a conversion prog (.EXCH) going one way but not the other (credits to energy). Initially gave you 3 for 4, a slightly unfavourable exchange rate, because I thought it should cost something to use to make you think about whether it was worth it. (Could have had a second one in the other direction at a different ratio - 2 for 3? - but also such a direct resource conversion isn't interesting to have very much of, just a little is good.) Eventually it became clear that it was usually a bad choice and it wouldn't hurt to push it up to 4 for 4. I realised there's still a cost to it - the siphon spent and the risk taken acquiring the ability in the first place, and the constraint of having to do it in blocks of 4 (consider: a 100/100 exchange would never be useful, even though it's the same ratio).
This imbalance between the two currencies helped guide later decisions. Because you have the possibility to turn credits into energy you can more likely avoid running out of energy - energy is more reliable, you can sink it into using a prog over and over again, so this determines the types of progs that should use it. If something's main utility is using it several times to set up a combo or get control of a bad situation (.PUSH, .PULL, .STEP) then it should cost energy; if it is interesting to use sparingly with precision after some setup (.DEBUG, .D_BOM, .CRASH) then it costs credits. (Of course you might like to use some of these latter progs with reckless abandon, but they're still valuable when you can't, so.) There ended up being slightly more progs costing credits than energy, which aligns with the idea that energy progs are each used more often (and means there's sometimes pressure to actually find something to spend that energy on).
Having a limited number of enemy types with specific counters was part of the initial concept. I expected to have multiple subtypes within those - several varieties of virus all affected by .ANTI_V or whatever - but keeping it focused with just one of each turned out really well. Started with a counter to each type all at the same price - .ANTI_V, .KIL_D (now D_BOM), .DEBUG, .DCRPT (now .SHOW) all at $$$, and these didn't change drastically. They're in the same currency to force a choice between them: you can't deal with every type at once.
The general pattern that started to come through was: credits for damage, energy for movement/evasion. Not everything fits that pattern but keeping it in mind made many other decisions easier - e.g. .WARP both attacks something and moves something so it costs an even mix, .REDUC and .DELAY are similar in that both make enemy spawns easier to deal with, but .REDUC's cost is weighted towards credits because it prevents enemies outright (pre-destroying them) while .DELAY just holds them at bay in a weakened state. Even though the currencies have different values, I treated it as meaningful for pairs like this to have mirrored costs ($$% and $%%) because it helped simplify the decision of where to put them (other such pairs are .WAIT/.UNDO, .ROW/.COL).
Originally .ROW and .COL only did 1 damage and cost $$% and $%%, and were quite a bit more tactically interesting to use than they are now but so efficient they completely overshadowed the other attack progs (especially since they don't depend on enemy type). I couldn't find a completely satisfactory fix; there wasn't room to weaken the effect and putting up the cost by 1 was enough to leave them pretty underpowered. What I ended up doing seems balanced (which is counterintuitive - an effect is too strong at cost 3 but double the effect is fine at 4? non-linearity, having the effect twice in one go is nowhere near as valuable as having it twice at carefully selected moments) but isn't as fun to play with - but balance makes the game better overall; conservation of fun. .COL costing mainly energy clashes a little with the principle of damage mostly costing credits so to compensate I pushed up the alert cost to 5 (vs .ROW's 4): breaking a pattern merits a higher cost.
.RESET explicitly converts energy to hp, but its efficiency varies situationally: it restores you to 3 so ideally you'd use it when on 1 to maximise the effect, but sometimes you must do it on 2 when you can't avoid being hit twice next turn, or when you only need 1 because you'll restore 1 on leaving the level. Usually (ideally) it gives 1 hp for each 2 energy. Several other progs can be thought of as converting currencies to hp - at different ratios under certain conditions, so how much 1 hp is worth is pretty variable. If there's an enemy one space away from you diagonally so you can't move without being hit, then .WAIT gives 1 hp for just 1 energy (by preventing subtraction rather than by adding). With .PUSH you can very often get a bit more than 1 hp for 2 energy (avoid a hit from a nearby enemy while inconveniencing other enemies). Occasionally you need to use $$$ for 1 hp (with .ANTI-V /.DEBUG/.D_BOM) but usually these can get you quite a lot more. So I think .RESET's 1 hp = 2 energy is kind of a bad deal, but it has reliability in its favour; to emphasise this I put the alert cost really low making it safe and accessible for beginners.
Some thought went into the order in which progs unlock. The initial set has no mixed costs; they're slightly more complex to use (they clash with everything, can't be used if either currency is exhausted), and it seemed like it might make the unlocks feel a bit more special by setting up a pattern then breaking it. Also all the attacks that are independent of enemy type have mixed cost (to compensate for them being more reliable), so this meant the initial set forces you to pay special attention to enemy types which might help with learning their behaviours. When you unlock a new prog you start the next game with it, giving an opportunity to try it out straight away - which meant .SCORE had to be in the initial set because starting with it would give a huge score advantage (some of the others are a bit of a concern too but that's the worst). A side-effect of that though is it's maybe easier to score before you've unlocked everything because .SCORE shows up more reliably, this is hopefully somewhat compensated for by not having .SIPH+. In general the game gets harder as you unlock more stuff; there are some stronger abilities but you're less likely to find something that combines well. I tried to keep the balance of credits/energy fairly even at each stage of unlocking, also tried to leave gaps and then fill them later so someone might have time to wonder what something might be before unlocking it, or when something obvious was coming; no idea if this worked at all.
(For reference, initial set is .WAIT, .SHOW, .PUSH, .STEP, .ANTI-V, .DEBUG, .D_BOM, .RESET, .EXCH, .SCORE and unlock order is .WARP, .POLY, .ROW, .DELAY, .UNDO, .ATK+, .PULL, .CRASH, .COL, .CALM, .REDUC, .HACK, .SIPH+)
NOW I WILL SUM UP SOME IDEAS WITH BULLETPOINTS
- Start by fixing some initial values to base things off (which could change later if needed).
- Invent principles of symmetry to guide the rest. Symmetry is good because it cuts out a whole bunch of possibilities and also it might have some aesthetic value maybe?
- Tools to convert between different resources are maybe interesting, but better if they vary situationally rather than just having a set exchange rate, and better the weirder the resources themselves are.
- Be aware of non-linearity; don't assume the meaning of numbers scales in an intuitive way. It might be more than twice as hard to pay 6 as 3, doubling an effect shouldn't necessarily double its cost, etc.
- Be aware of different types of cost - unreliability, difficulty of acquisition, opportunity costs - as well as the explicit numeric resources.
- Breaking a pattern merits a higher cost.
- The whole is more important than its component parts. Be comfortable making a component worse if it's better for the whole.
- there's no perfect
- What is balance anyway idk
Friday, 25 April 2014
why am i making games for ios
NO REALLY WHY?
Someone asked me this yesterday because I was complaining along the way to finishing Helix.
Writing this more for myself to figure out if it still makes sense.
I got into this when I was working on Kompendium; someone suggested the games might work better on a mobile device. I was pretty skeptical at first, partially because I'd never owned a phone or anything and so it would mean buying expensive stuff I couldn't really afford, partially because the games were very much designed around the constraint of each player using just the arrow keys and I didn't know how that would translate to a different control scheme. But I decided to go for it, bought an iPad, the first game I ported over was Glitch Tank which turned out to work amazingly well, better than on a keyboard. So I released that one on its own while I kept working on the others, it didn't sell enough to cover the cost of the device, justifying some of my skepticism - but I was really happy with how it turned out, falsifying the rest.
The other games didn't transfer over anywhere near so well, they felt pretty bad. So I got interested in the problem of how to use a touchscreen well. Touchscreens are really interesting to design for, they have this immediacy to them - you're directly touching the videogame. They're malleable, you can divide up the space however you like, invent new button configurations and change them on the fly, adjust to accommodate different numbers of players. They constrain you in that all controls take up screen space, but I feel that's the right kind of constraint, forcing elegance and good design. Their obvious weakness is a lack of tactile feedback, but just wait. (This is where Helix came from - since it was really hard to do movement controls for two players well I decided to solve it for just one player first. Which is still pretty hard, hardly any games get it right. I've done it to my satisfaction now, but it might not be to everyone's; it seems like everybody has a slightly different expectation of how a touchscreen will work.)
I've ended up really enjoying working on the iPad, it just fits really well with how I make things, it feels like the right size for my games - compact but rich. It's really convenient to have games on a portable device, handy for being able to show people what I've been working on, and perfect for multiplayer, being able to play games together when out places. I don't like working with telephones at all though, they're far too cramped, supporting a different resolution is a bunch of work (more with this low-res pixel stuff I've been doing than if you just do scalable vector graphics, and even more now they've brought out widescreen ones as well), BUT HEY IT'S A BIGGER MARKET so.
Also it kind of feels to me like games at the scale I've been making it's easier to sell on mobile. I'm pretty sure the most reliable source of income from videogames is big PC games with lots of graphics and lots of fiddly bits and inelegant content to justify a substantial pricetag, but if you're making small focused things and want to get paid at all I think mobile's the best bet at the moment? That's just my impression though, it's a subject on which I could easily be quite wrong.
I really don't like that putting games on iOS means people can't play them without some expensive gadget. It excludes people, and it doesn't feel true to myself - I've been disappointed many times by games being exclusive to some console I couldn't afford. I shouldn't do this I'd rather not do this. It makes me quite unhappy that Glitch Tank and O are confined to proprietary Apple products but it's a real pain to do anything about it. Obviously it'd be nice to cover Android devices too but those are even more of a nuisance to develop for: way more different resolutions, whole bunch of extra technical nonsense to fight through (probably not that much worse than iOS but it's separate & one only has so much time in a life), plus it tends to pay a lot less than iOS and until 868-HACK I really wasn't making much. (I actually did get Glitch Tank running on Android, with some ugly hacks, but it's not getting a good framerate and I'm not quite motivated enough to dig into that mess to figure out why.) Obviously games that don't require a touchscreen I can release on PC, I do this, I've been delayed with 868-HACK because I got into a bit of a mess trying to track down some obscure crashes on a few people's computers that I can't reproduce on my own - something that is a bit less of a concern on iOS, having fixed target hardware is pretty nice (although Apple tends to break stuff with every update; I had a bunch of complaints when iOS7 broke something, though it was fortunately non-critical and only required one line added to a config file to fix. More of a concern is that Vertex Dispenser is crashing on startup on the latest MacOS, no idea why, haven't had time to dig into it, it can't really be my priority right now, but it's hanging over me. Wish I could just release games and be done with them, but each one is an additional maintenance cost at random intervals forever, and each platform it's on adds a multiplier on top of that.).
Really a lot of the reason I've stuck with iOS for a while is the multiplayer games. This is what got me into this in the first place, it's something I got really excited about for a while, it's so perfect for them but there are very few and they don't do well. I think a lot of people just don't realise that they're carrying around multiplayer consoles everywhere they go? Culture. Anyway I was hoping if I stuck with the platform for a while and made some singleplayer games maybe I could get some attention to reflect back on the multiplayer ones - because they can't so much go elsewhere. This has worked a little I guess, but of course they're not new, I'm thinking about making a new one or maybe doing a sequel to Glitch Tank, but it's hard for me to work on these at the moment because I got so excited and then demoralised.
Anyway at some point Apple will drive me away and I guess I'll go back to only making PC games again, yay.
Someone asked me this yesterday because I was complaining along the way to finishing Helix.
Writing this more for myself to figure out if it still makes sense.
I got into this when I was working on Kompendium; someone suggested the games might work better on a mobile device. I was pretty skeptical at first, partially because I'd never owned a phone or anything and so it would mean buying expensive stuff I couldn't really afford, partially because the games were very much designed around the constraint of each player using just the arrow keys and I didn't know how that would translate to a different control scheme. But I decided to go for it, bought an iPad, the first game I ported over was Glitch Tank which turned out to work amazingly well, better than on a keyboard. So I released that one on its own while I kept working on the others, it didn't sell enough to cover the cost of the device, justifying some of my skepticism - but I was really happy with how it turned out, falsifying the rest.
The other games didn't transfer over anywhere near so well, they felt pretty bad. So I got interested in the problem of how to use a touchscreen well. Touchscreens are really interesting to design for, they have this immediacy to them - you're directly touching the videogame. They're malleable, you can divide up the space however you like, invent new button configurations and change them on the fly, adjust to accommodate different numbers of players. They constrain you in that all controls take up screen space, but I feel that's the right kind of constraint, forcing elegance and good design. Their obvious weakness is a lack of tactile feedback, but just wait. (This is where Helix came from - since it was really hard to do movement controls for two players well I decided to solve it for just one player first. Which is still pretty hard, hardly any games get it right. I've done it to my satisfaction now, but it might not be to everyone's; it seems like everybody has a slightly different expectation of how a touchscreen will work.)
I've ended up really enjoying working on the iPad, it just fits really well with how I make things, it feels like the right size for my games - compact but rich. It's really convenient to have games on a portable device, handy for being able to show people what I've been working on, and perfect for multiplayer, being able to play games together when out places. I don't like working with telephones at all though, they're far too cramped, supporting a different resolution is a bunch of work (more with this low-res pixel stuff I've been doing than if you just do scalable vector graphics, and even more now they've brought out widescreen ones as well), BUT HEY IT'S A BIGGER MARKET so.
Also it kind of feels to me like games at the scale I've been making it's easier to sell on mobile. I'm pretty sure the most reliable source of income from videogames is big PC games with lots of graphics and lots of fiddly bits and inelegant content to justify a substantial pricetag, but if you're making small focused things and want to get paid at all I think mobile's the best bet at the moment? That's just my impression though, it's a subject on which I could easily be quite wrong.
I really don't like that putting games on iOS means people can't play them without some expensive gadget. It excludes people, and it doesn't feel true to myself - I've been disappointed many times by games being exclusive to some console I couldn't afford. I shouldn't do this I'd rather not do this. It makes me quite unhappy that Glitch Tank and O are confined to proprietary Apple products but it's a real pain to do anything about it. Obviously it'd be nice to cover Android devices too but those are even more of a nuisance to develop for: way more different resolutions, whole bunch of extra technical nonsense to fight through (probably not that much worse than iOS but it's separate & one only has so much time in a life), plus it tends to pay a lot less than iOS and until 868-HACK I really wasn't making much. (I actually did get Glitch Tank running on Android, with some ugly hacks, but it's not getting a good framerate and I'm not quite motivated enough to dig into that mess to figure out why.) Obviously games that don't require a touchscreen I can release on PC, I do this, I've been delayed with 868-HACK because I got into a bit of a mess trying to track down some obscure crashes on a few people's computers that I can't reproduce on my own - something that is a bit less of a concern on iOS, having fixed target hardware is pretty nice (although Apple tends to break stuff with every update; I had a bunch of complaints when iOS7 broke something, though it was fortunately non-critical and only required one line added to a config file to fix. More of a concern is that Vertex Dispenser is crashing on startup on the latest MacOS, no idea why, haven't had time to dig into it, it can't really be my priority right now, but it's hanging over me. Wish I could just release games and be done with them, but each one is an additional maintenance cost at random intervals forever, and each platform it's on adds a multiplier on top of that.).
Really a lot of the reason I've stuck with iOS for a while is the multiplayer games. This is what got me into this in the first place, it's something I got really excited about for a while, it's so perfect for them but there are very few and they don't do well. I think a lot of people just don't realise that they're carrying around multiplayer consoles everywhere they go? Culture. Anyway I was hoping if I stuck with the platform for a while and made some singleplayer games maybe I could get some attention to reflect back on the multiplayer ones - because they can't so much go elsewhere. This has worked a little I guess, but of course they're not new, I'm thinking about making a new one or maybe doing a sequel to Glitch Tank, but it's hard for me to work on these at the moment because I got so excited and then demoralised.
Anyway at some point Apple will drive me away and I guess I'll go back to only making PC games again, yay.
Monday, 17 February 2014
CYBERGALLOP
netrunner demake
made for retro remakes "cassette 50" jam
windows download
mac download
(mac version is only running in windowed mode right now because i haven't figured out all the new hoops i have to jump through since apple most recently coerced me to submit to their updates. and maybe i won't bother.)
clearly it doesn't capture all - or even many - of netrunner's dynamics, but there's something there.
Friday, 17 January 2014
868-hack update
Okay, 868-HACK has been updated on iOS. The update clears the high score tables and starts fresh. The old scores can still be viewed through gamecenter under "legacy". If you don't update, any new scores you get will remain separate. If you're in the middle of a streak, updating will reset that so scores can't be carried over that way (sorry!). Your local score list is also cleared, so if you want to keep that record take a screenshot before updating.
Since release I've been learning more about the game and tweaking the balance. Most of the changes are smallish, but they add up and make a difference to how easy it is to score. Many of the things I've learnt have come from observing the game in the wild; I couldn't have known to account for them before release.
At some point during development .STEP allowed stepping off the edge of the level to wrap around to the opposite side: this felt very cool as a glitch in an abstract digital space, but was far too useful for skipping levels (because it makes the corners adjacent) so it didn't stay. So at release I felt like .STEP was slightly underpowered because it was weaker than it had been; it was more expensive than .WAIT / .PUSH / .PULL as a parity flip and it was less useful for grabbing lots of points on the last level and getting out safely than before. I WAS WRONG. It's still extremely effective, you just need to make sure to save up enough energy. I've nerfed it a little: it now spawns 4 enemies instead of 3 on acquisition, and it can no longer be used to instantly siphon (since while that was a neat interaction it's a more interesting problem to find a safe space to siphon while stepping through a level full of enemies). This means it's now harder to get a high score because you're more likely to have to deal with the enemies you alert, and it's harder to get a streak because you're less likely to be able to skip the hardest levels.
I wrote before about the question of whether .SCORE was overpowered. I don't believe that it technically was because I was able to get scores as high without it as with it. But many others did believe that it was and that belief was shaping the way they played in a way they were unhappy with - it doesn't always matter if a belief is true if it has genuine effects anyway. This belief reinforced itself: players convinced that it was the only way to get high scores would only try to get high scores when they had it, so the high score list filled up with .SCORE-based scores, convincing anyone else looking at it that this was the way to get high scores. James Lantz describes the process of constantly restarting the first level to get a good run - this is mostly a problem with .SCORE because it is clear from the first level whether you'll be able to get many points out of it, whereas other ways of scoring big aren't obvious until later. Meanwhile I would almost never pick up .SCORE myself because it just wasn't worth the risk. Also I noticed that many of the high scores weren't quite as high as they could have been because they'd forget to dump their remaining energy into .SCORE on the last level when it was safe - which is admittedly a boring requirement. I'm attempting to fix these concerns in a way that remains balanced by making .SCORE grant one less point with each use, while spawning one less enemy on acquisition. This means it's harder to get high scores with it (you'll need to take even more risks or rely on other methods of scoring as well), every use of it is an interesting gamble (you can't use it safely at the end because it's worth 0 by then), it less encourages restarting lots to get a good run (because it has less variance), and it's more viable during streaks (because it's less dangerous to pick up).
SPOILERS: There is a secret level. It's expensive and risky to get there but sometimes it can be exploited for an advantage. There was a design error which is now fixed, in which it was possible to recursively access it and maybe push that advantage too far. It remains a possible way to get extra points, but not so many as before.
SEMI-SPOILERS: During streaks difficulty modifiers get applied to provide an extra challenge and hopefully end the streak eventually. I didn't want streaks to continue indefinitely because then the optimal way to play would be to get one point per game for a thousand games rather than taking any risks, so I increased the chances of failure as you go.
(It seems like bad form to just present an impossible run, but with a finite discrete game you can't just keep increasing the difficulty without it ending up impossible. The best I can hope for here is that when you eventually lose it'll be because of a risk you took that you could have done differently: this feels less unsatisfactory even though in the limit it's still outside of your control.)
When I made the game I was enamoured with the idea that a streak might last a very long time, that there could be some elite hacker known only by a mysterious pseudonym somehow *STILL RUNNING* against all odds. And this happened exactly as imagined, nobodyweknow has an amazing streak, 1228 points in 47 games at time of writing. But there's a side-effect to this that I hadn't anticipated: it's putting other players off even trying for streaks, leaving them just grinding at the (less interesting) single-game scoreboard. Additionally, nobodyweknow has said that at the level he's playing at some of the runs seem pointless because they're not offering enough challenge - the difficulty modifiers, originally conceived just as a way to kill off streaks, have become a core part of what makes the game varied and interesting. So I've significantly ramped up the difficulty increase to hopefully end streaks quicker and more consistently challenge experts. This has a more dramatic effect on scoring than the single-game changes because of how much the points can add up across a streak.
All of these combine to make scoring more difficult, but in ways that are somewhat ambiguous - I can't just recalculate old scores to fit the new scale. There may only have been one score that exploited the old secret level (my own) but I can't be sure, and certainly there were many that exploited the old .STEP and .SCORE. Probably all the old scores would be beaten eventually even though it's harder - just by someone eventually being more skilled and having a luckier run - but until then they'd be hanging around in the lists and I worry this would seem unfair to new players. Also it matters because you can examine what progs a score was obtained using, so this would be providing misleading information to anyone hoping to learn from it (similarly, you can examine what modifiers were applied to games in a streak). So all up I think it is best not to have the old scores hanging around. I hope this is okay with everyone!
Since release I've been learning more about the game and tweaking the balance. Most of the changes are smallish, but they add up and make a difference to how easy it is to score. Many of the things I've learnt have come from observing the game in the wild; I couldn't have known to account for them before release.
At some point during development .STEP allowed stepping off the edge of the level to wrap around to the opposite side: this felt very cool as a glitch in an abstract digital space, but was far too useful for skipping levels (because it makes the corners adjacent) so it didn't stay. So at release I felt like .STEP was slightly underpowered because it was weaker than it had been; it was more expensive than .WAIT / .PUSH / .PULL as a parity flip and it was less useful for grabbing lots of points on the last level and getting out safely than before. I WAS WRONG. It's still extremely effective, you just need to make sure to save up enough energy. I've nerfed it a little: it now spawns 4 enemies instead of 3 on acquisition, and it can no longer be used to instantly siphon (since while that was a neat interaction it's a more interesting problem to find a safe space to siphon while stepping through a level full of enemies). This means it's now harder to get a high score because you're more likely to have to deal with the enemies you alert, and it's harder to get a streak because you're less likely to be able to skip the hardest levels.
I wrote before about the question of whether .SCORE was overpowered. I don't believe that it technically was because I was able to get scores as high without it as with it. But many others did believe that it was and that belief was shaping the way they played in a way they were unhappy with - it doesn't always matter if a belief is true if it has genuine effects anyway. This belief reinforced itself: players convinced that it was the only way to get high scores would only try to get high scores when they had it, so the high score list filled up with .SCORE-based scores, convincing anyone else looking at it that this was the way to get high scores. James Lantz describes the process of constantly restarting the first level to get a good run - this is mostly a problem with .SCORE because it is clear from the first level whether you'll be able to get many points out of it, whereas other ways of scoring big aren't obvious until later. Meanwhile I would almost never pick up .SCORE myself because it just wasn't worth the risk. Also I noticed that many of the high scores weren't quite as high as they could have been because they'd forget to dump their remaining energy into .SCORE on the last level when it was safe - which is admittedly a boring requirement. I'm attempting to fix these concerns in a way that remains balanced by making .SCORE grant one less point with each use, while spawning one less enemy on acquisition. This means it's harder to get high scores with it (you'll need to take even more risks or rely on other methods of scoring as well), every use of it is an interesting gamble (you can't use it safely at the end because it's worth 0 by then), it less encourages restarting lots to get a good run (because it has less variance), and it's more viable during streaks (because it's less dangerous to pick up).
SPOILERS: There is a secret level. It's expensive and risky to get there but sometimes it can be exploited for an advantage. There was a design error which is now fixed, in which it was possible to recursively access it and maybe push that advantage too far. It remains a possible way to get extra points, but not so many as before.
SEMI-SPOILERS: During streaks difficulty modifiers get applied to provide an extra challenge and hopefully end the streak eventually. I didn't want streaks to continue indefinitely because then the optimal way to play would be to get one point per game for a thousand games rather than taking any risks, so I increased the chances of failure as you go.
(It seems like bad form to just present an impossible run, but with a finite discrete game you can't just keep increasing the difficulty without it ending up impossible. The best I can hope for here is that when you eventually lose it'll be because of a risk you took that you could have done differently: this feels less unsatisfactory even though in the limit it's still outside of your control.)
When I made the game I was enamoured with the idea that a streak might last a very long time, that there could be some elite hacker known only by a mysterious pseudonym somehow *STILL RUNNING* against all odds. And this happened exactly as imagined, nobodyweknow has an amazing streak, 1228 points in 47 games at time of writing. But there's a side-effect to this that I hadn't anticipated: it's putting other players off even trying for streaks, leaving them just grinding at the (less interesting) single-game scoreboard. Additionally, nobodyweknow has said that at the level he's playing at some of the runs seem pointless because they're not offering enough challenge - the difficulty modifiers, originally conceived just as a way to kill off streaks, have become a core part of what makes the game varied and interesting. So I've significantly ramped up the difficulty increase to hopefully end streaks quicker and more consistently challenge experts. This has a more dramatic effect on scoring than the single-game changes because of how much the points can add up across a streak.
All of these combine to make scoring more difficult, but in ways that are somewhat ambiguous - I can't just recalculate old scores to fit the new scale. There may only have been one score that exploited the old secret level (my own) but I can't be sure, and certainly there were many that exploited the old .STEP and .SCORE. Probably all the old scores would be beaten eventually even though it's harder - just by someone eventually being more skilled and having a luckier run - but until then they'd be hanging around in the lists and I worry this would seem unfair to new players. Also it matters because you can examine what progs a score was obtained using, so this would be providing misleading information to anyone hoping to learn from it (similarly, you can examine what modifiers were applied to games in a streak). So all up I think it is best not to have the old scores hanging around. I hope this is okay with everyone!