I challenged myself to make one game a month in 2013, and I'm starting the year off getting something complete(ish) with almost a day to spare, and published with more than 12 hours on the clock before the end of the month.
I've mentioned it before, but January's game is Switch 2013, a port of a game design idea that I've been poking at for several years now (hey, there's even a history page kicking around the old webpage).
I had got most of the functionality working early on in the month, but there's a pattern that I like to use that I call "ModeMgr", which is usually a stack of game modes. This allows you to have the normal gameplay happen in its own class, and then if you need a dialog box, or an options menu, or whatever, that all is implemented in separate classes. A dialog box probably is pushed on top of a gameplay mode, and the dialog will select what to pass along the "chain of responsibility" - for example, the dialog will let the underlying game mode draw the screen once, and then the dialog will draw itself, perhaps darkening the game scene to draw attention to the dialog. Updates will probably not be passed along to the game mode for a modal dialog. (Maybe you want a modeless dialog, but I don't think this is a great system for that.)
Anyway, that system has worked well for me in systems past, but I had some difficulty getting the system up and running on JavaScript, and in particular, with the Closure Compiler. I'm not yet thinking clearly about what depends on what, and what needs to include what - programming in Python has allowed me to get lazy about circular dependencies.
What I ended up getting implemented last night was to create the ModeMgr as a singleton (I'm not entirely sure I like that decision, and may revisit it as I do my next game(s)), and then register each game mode with the ModeMgr with a string. Right now, I have raw strings floating around in disconnected parts of the code, but it'd be easy enough to capture those in a constants file. When a game mode wants to switch modes, it tells the ModeMgr to switch modes (there's no stack at this point, again, something to add over time) by passing the tag and an optional argument. The argument is only currently used when the player is choosing a level; I pass the level number in as a special function call.
There are a lot of gross things about the current implementation, several of which I hinted at above. An awkward thing is that the modes are objects, but I hand the constructor to JawsJS, so I don't get the option of passing arguments to the constructor, so choosing the level is this extra bit of initialization that happens after construction. Gross.
Another disappointing thing is that I managed to get 600 levels into the original Switch, and I generated 256 levels for Switch 2013, but due to laziness, and font kerning hassles, I couldn't be bothered to make a compelling UI to select more than 10 levels (the base level, plus 9 additional selectable levels). With a little work, I could implement the Angry Birds level selection model, which might be OK.
But that's an idea for a game for next month.
Thursday, January 31, 2013
Thursday, January 3, 2013
On Shallowness, Sturgeon, and Laundry
So, this sort of touches on the "one game a month" challenge that I've taken up. I had mentioned it to a buddy after I had pretty much committed to it, and he suggested that I raise the ante from just making a game a month to also use different gameplay styles for each of the games (only one boardgame port, only one puzzle, only one side-scrolly-running-and-jumping-platformer, only one flight sim, only one massively multiplayer game).
I'm split on this - I think I'm going to strive towards that ideal, but I may fudge it (even more than I expect to fudge what I count as a "finished game"). I've got a list of small game ideas that I want to work on, but I know there's a bunch that end up in the same game style bucket.
One good part of this additional challenge is that it pushes me to explore more game design space than I might otherwise have. If I implement checkers or chess, I'm not going to do reversi or attaxx. That's not terrible, and it keeps me from implementing an Alpha-Beta library and reskinning it in a month and calling it a new game.
On the down side, I will end up implementing a lot of infrastructure (loose quadtrees, cached alpha-beta search trees, influence maps, racing line optimizers) that won't see reuse this year. Maybe that's OK, but I'm concerned that I'll find myself throwing some technology together that's good enough for one game, and not hone it with use.
One thing I thought was interesting about my college curriculum was that each semester, we had a new computer language to learn. At first, I thought this was madness, but after a while, I appreciated the breadth of exposure. Perhaps 12 different kinds of games will accomplish the same thing.
Thinking about 12 games in a year, I know that they'll all be small games, and I'm OK with that. Thinking about Sturgeon's Law, they'll doubtless have some that are better than others. If I model Sturgeon by a fair 10-sided die, and each of the 12 games has a 90% chance of being bad, that's a 28% chance of zero games coming up good. That's actually higher than I would have guessed (people are bad at probability), but if you flip the glass over, that's a 72% chance of at least one playable game in the bunch.
Of course, game development isn't just rolling dice (though, I kind of want to incorporate some random elements along the way to knock loose some creative surprises), and presumably the later games in the year will benefit from lessons learned along the way. By forcing myself to diversify, I won't be learning nuances about optimizing racing game AI, instead I'll have the opportunity to learn bigger picture lessons. That sounds exciting.
I wonder about the value of developing "in public" - if I were to make a dozen games in a year and present the one I liked the best, it'd be easier to imagine that this one really good idea came to me and everything was easy. But there's a lot of trial and error, and sometimes gold turns up where you don't expect it - so I'm open to sharing the journey here, even if it is a bunch of dead ends. It isn't so much showing my dirty laundry, it's being honest about the creative process.
I'm split on this - I think I'm going to strive towards that ideal, but I may fudge it (even more than I expect to fudge what I count as a "finished game"). I've got a list of small game ideas that I want to work on, but I know there's a bunch that end up in the same game style bucket.
One good part of this additional challenge is that it pushes me to explore more game design space than I might otherwise have. If I implement checkers or chess, I'm not going to do reversi or attaxx. That's not terrible, and it keeps me from implementing an Alpha-Beta library and reskinning it in a month and calling it a new game.
On the down side, I will end up implementing a lot of infrastructure (loose quadtrees, cached alpha-beta search trees, influence maps, racing line optimizers) that won't see reuse this year. Maybe that's OK, but I'm concerned that I'll find myself throwing some technology together that's good enough for one game, and not hone it with use.
One thing I thought was interesting about my college curriculum was that each semester, we had a new computer language to learn. At first, I thought this was madness, but after a while, I appreciated the breadth of exposure. Perhaps 12 different kinds of games will accomplish the same thing.
Thinking about 12 games in a year, I know that they'll all be small games, and I'm OK with that. Thinking about Sturgeon's Law, they'll doubtless have some that are better than others. If I model Sturgeon by a fair 10-sided die, and each of the 12 games has a 90% chance of being bad, that's a 28% chance of zero games coming up good. That's actually higher than I would have guessed (people are bad at probability), but if you flip the glass over, that's a 72% chance of at least one playable game in the bunch.
Of course, game development isn't just rolling dice (though, I kind of want to incorporate some random elements along the way to knock loose some creative surprises), and presumably the later games in the year will benefit from lessons learned along the way. By forcing myself to diversify, I won't be learning nuances about optimizing racing game AI, instead I'll have the opportunity to learn bigger picture lessons. That sounds exciting.
I wonder about the value of developing "in public" - if I were to make a dozen games in a year and present the one I liked the best, it'd be easier to imagine that this one really good idea came to me and everything was easy. But there's a lot of trial and error, and sometimes gold turns up where you don't expect it - so I'm open to sharing the journey here, even if it is a bunch of dead ends. It isn't so much showing my dirty laundry, it's being honest about the creative process.
Wednesday, January 2, 2013
Hello, Two Thousand Thirteen
Many years ago, my grandfather called the house and asked "Hello, is this one nine seven nine?" (or some sequence of four digits) - the gag being that his was the first phonecall of the new year, and the digits he was asking about was the new year, in a format we were unfamiliar with, for a year we had just welcomed in.
I imagine it's perhaps a bit funnier if you're old enough to have used the two-character prefix names "Klondike 5-1234", so a phone number was only five digits to recall, and then "is this one nine seven nine" might actually almost make sense as a first thing to ask somebody over the phone.
I don't know if that was in 1979 - sometime within a few years of that, anyway.
I mention that, I suppose, to ask the reader "is this two thousand thirteen?", and of course, yes, it is. But maybe you're one of those folks who like saying "twenty thirteen", which grates on my ear, so I invite you to indulge in the single extra syllable that "two thousand thirteen" requires. And I also suggest that "twenty-four teen" is going to grate on all of our ears next year.
Over the past week and a bit, I puttered a bit at home with a variety of projects - some game-related, some not. Some computer-related, some not. I also revelled in far more nostalgia than necessary (or, probably, healthful), but the holidays are pretty much built for that.
One thing that I turned up, in digging through some old stuff, was my old case of Star Wars action figures. And I turned up the insert that came in the case, with the exhortation "collect them all!", which seemed weird to see in an artifact that predated Pokemon. That insert showed the case filled with action figures, each one in their own little slot. The weird bit was that the case came with two trays, and each tray had twelve slots. So, clearly, the child-collector was meant to buy a full complement of 24 action figures to get full use out of their case. Except that, at that time, there weren't 24 different action figures in production. I don't even think they made 20 action figures from the first movie; Boba Fett was the mysterious extra character shown on the insert, and you had to collect proofs-of-purchase to get him (at least, initially). So, they doubled up on some characters. Three Stormtroomers, sure. And two Tuskein Raiders. Um, yeah, because they were faceless evil creatures that your play scenarios needed a bunch of. Only one Jawa - I guess they only had so many half-size slots, and after one Jawa, and one Artoo-Deetoo, and one, um, R5-D4, and a Power Droid, they had filled their quota. I suspect Jawas weren't an interesting part of most kids' imaginings. Pew pew! I zap your droid, and he falls over! Pew! I sell him back to you! And then he stops working! Pew!
As for game projects, I made some progress revisiting an old game that I had built years ago when I wanted to teach myself Windows programming, back when that was a weird and esoteric art. I guess it's still weird and it seems pretty esoteric again, so funny how things turn around. The game I made back on Windows 286 (yeah, back before Windows 3.0, things were weird) was a little sliding tile game, inspired a tiny bit by the old 15-tile sliding tile puzzle, but mine didn't move in obvious ways. I invite you to check out http://bigdicegames.com/Switch2013/ to get a vague idea of what's going on. I think I still have a copy of Switch.exe kicking around somewhere, but it's a 16 bit Windows program, which was able to run on some versions of 32 bit Windows, but I can leave that bit of nostalgia behind - perhaps things I've made with my own hands are less precious to me.
The original Switch had several levels, which I generated using a separate program, which generated a big blob of data which I compiled in to the EXE (in those days, packaging data separate from the code meant headaches that I didn't want to deal with in terms of packaging - you couldn't rely on people having PKZIP installed, much less WinZip). I don't recall how many levels there were, but I knew that I could use up to 64 kilobytes in one addressable segment before having to start doing weird stuff with the compiler to page in additional segments. So, there were, maybe, 100 levels? Maybe 128? Something in that range, anyway.
Switch 2013 has several levels, but it (so far) lacks the ability to select levels, or to progress from one level to the next. So, since you're pretty much locked in to just one level, it's more meaningful to say it just has one level, even though the other levels are baked in, similar to the hardcoded data of the original Switch.
I think I probably will end up having the game procedurally generate the level at runtime, which shouldn't be too hard - and will stretch my JavaScript skills a bit, which is the point of the project, anyway. Right now, the levels are generated by a Python script that uses generators to create a big list of "cycles" - the paths that the tiles move on. One piece that I think is important is that most levels have some sort of symmetry to make them feel more intentional and less arbitrary. I've captured that idea in my Python level generator script, and I'll be able to do it in JavaScript, I'm sure - I just will have to learn how some stuff is done differently.
Another game-related project that I'm working on involves the OUYA game console. I got a developer's kit (which, really, is just a pre-retail version with "OUYA DEVS" printed on it) on New Year's Eve. I plugged it in to the display in the living room, and it shows up in 1080p glory. I unplugged it, walked it in to the office/den/spare bedroom and, sure enough, it shows up as an android device when plugged in to the Linux box that I consider my home base for coding. I pushed the sample apps up from the Linux box, and they showed up when I walked the dev kit back into the living room, and after a few more cycles back and forth, I got an app of my own running, based on the PlayN game framework that I've been using of late. My goal was to get the OUYA controllers to move stuff around on the screen, but that didn't come together. I fully expect that once I get a HDMI display for the den, then I'll be able to run the app and see the debug output at the same time. Debugging blind is possible, to be sure, but I don't have that kind of patience.
I was somewhat hopeful that I'd have brought either or both of these mini-projects to the point where I could claim one of them as the first of my "12 games in 12 months" challenge, but no such luck. But there's almost a full month of January left, so I'm OK.
I imagine it's perhaps a bit funnier if you're old enough to have used the two-character prefix names "Klondike 5-1234", so a phone number was only five digits to recall, and then "is this one nine seven nine" might actually almost make sense as a first thing to ask somebody over the phone.
I don't know if that was in 1979 - sometime within a few years of that, anyway.
I mention that, I suppose, to ask the reader "is this two thousand thirteen?", and of course, yes, it is. But maybe you're one of those folks who like saying "twenty thirteen", which grates on my ear, so I invite you to indulge in the single extra syllable that "two thousand thirteen" requires. And I also suggest that "twenty-four teen" is going to grate on all of our ears next year.
Over the past week and a bit, I puttered a bit at home with a variety of projects - some game-related, some not. Some computer-related, some not. I also revelled in far more nostalgia than necessary (or, probably, healthful), but the holidays are pretty much built for that.
One thing that I turned up, in digging through some old stuff, was my old case of Star Wars action figures. And I turned up the insert that came in the case, with the exhortation "collect them all!", which seemed weird to see in an artifact that predated Pokemon. That insert showed the case filled with action figures, each one in their own little slot. The weird bit was that the case came with two trays, and each tray had twelve slots. So, clearly, the child-collector was meant to buy a full complement of 24 action figures to get full use out of their case. Except that, at that time, there weren't 24 different action figures in production. I don't even think they made 20 action figures from the first movie; Boba Fett was the mysterious extra character shown on the insert, and you had to collect proofs-of-purchase to get him (at least, initially). So, they doubled up on some characters. Three Stormtroomers, sure. And two Tuskein Raiders. Um, yeah, because they were faceless evil creatures that your play scenarios needed a bunch of. Only one Jawa - I guess they only had so many half-size slots, and after one Jawa, and one Artoo-Deetoo, and one, um, R5-D4, and a Power Droid, they had filled their quota. I suspect Jawas weren't an interesting part of most kids' imaginings. Pew pew! I zap your droid, and he falls over! Pew! I sell him back to you! And then he stops working! Pew!
As for game projects, I made some progress revisiting an old game that I had built years ago when I wanted to teach myself Windows programming, back when that was a weird and esoteric art. I guess it's still weird and it seems pretty esoteric again, so funny how things turn around. The game I made back on Windows 286 (yeah, back before Windows 3.0, things were weird) was a little sliding tile game, inspired a tiny bit by the old 15-tile sliding tile puzzle, but mine didn't move in obvious ways. I invite you to check out http://bigdicegames.com/Switch2013/ to get a vague idea of what's going on. I think I still have a copy of Switch.exe kicking around somewhere, but it's a 16 bit Windows program, which was able to run on some versions of 32 bit Windows, but I can leave that bit of nostalgia behind - perhaps things I've made with my own hands are less precious to me.
The original Switch had several levels, which I generated using a separate program, which generated a big blob of data which I compiled in to the EXE (in those days, packaging data separate from the code meant headaches that I didn't want to deal with in terms of packaging - you couldn't rely on people having PKZIP installed, much less WinZip). I don't recall how many levels there were, but I knew that I could use up to 64 kilobytes in one addressable segment before having to start doing weird stuff with the compiler to page in additional segments. So, there were, maybe, 100 levels? Maybe 128? Something in that range, anyway.
Switch 2013 has several levels, but it (so far) lacks the ability to select levels, or to progress from one level to the next. So, since you're pretty much locked in to just one level, it's more meaningful to say it just has one level, even though the other levels are baked in, similar to the hardcoded data of the original Switch.
I think I probably will end up having the game procedurally generate the level at runtime, which shouldn't be too hard - and will stretch my JavaScript skills a bit, which is the point of the project, anyway. Right now, the levels are generated by a Python script that uses generators to create a big list of "cycles" - the paths that the tiles move on. One piece that I think is important is that most levels have some sort of symmetry to make them feel more intentional and less arbitrary. I've captured that idea in my Python level generator script, and I'll be able to do it in JavaScript, I'm sure - I just will have to learn how some stuff is done differently.
Another game-related project that I'm working on involves the OUYA game console. I got a developer's kit (which, really, is just a pre-retail version with "OUYA DEVS" printed on it) on New Year's Eve. I plugged it in to the display in the living room, and it shows up in 1080p glory. I unplugged it, walked it in to the office/den/spare bedroom and, sure enough, it shows up as an android device when plugged in to the Linux box that I consider my home base for coding. I pushed the sample apps up from the Linux box, and they showed up when I walked the dev kit back into the living room, and after a few more cycles back and forth, I got an app of my own running, based on the PlayN game framework that I've been using of late. My goal was to get the OUYA controllers to move stuff around on the screen, but that didn't come together. I fully expect that once I get a HDMI display for the den, then I'll be able to run the app and see the debug output at the same time. Debugging blind is possible, to be sure, but I don't have that kind of patience.
I was somewhat hopeful that I'd have brought either or both of these mini-projects to the point where I could claim one of them as the first of my "12 games in 12 months" challenge, but no such luck. But there's almost a full month of January left, so I'm OK.
Subscribe to:
Posts (Atom)