I made a game for this year’s Global Game Jam called Super Hex Racer. It was another collaboration with my friend and longtime collaborator August Brown.
Here’s the presentation on it that I made for the VR & HCI meetup:
I made a game for this year’s Global Game Jam called Super Hex Racer. It was another collaboration with my friend and longtime collaborator August Brown.
Here’s the presentation on it that I made for the VR & HCI meetup:
I’m a huge fan of Looney Pyramids. Mostly because I think it’s the most successful game system ever produced. And by successful, I mean that it’s probably had the most games made for it.
Now that I’ve said this, I might argue that Chess is the most successful, especially by that metric, since there are probably way more chess variants in existence than pyramid games, but of course Chess was never meant to be a game system. Then again, we can’t actually imagine what Chess was meant to be, since it’s not even remotely known who invented chess originally. Maybe they imagined a future in 2 or 3 thousand years when their game would be used to play literally hundreds of games.
Okay, anyway, so over 3 years ago, I had an idea, chatting with a friend**, and asked another friend*** to make it for me. The idea was a deck of cards that depicted Looney Pyramids on them. I imagined you could make a ton of games using them. Then I imagined some of those games. I don’t think I really playtested any of those games much until months later.
But the point is that I never got around to posting the PnP files for the deck of cards. So without further ado:
Here’s v1.0 of Pyramid Cards, PnP edition.
…better late than never, right?
** Special thanks to Nate Yourchuck.
*** Special thanks to August Brown for making the art for these.
I’ve participated in a number of game jams over the last ~7 (or so) years. For the most part, these only get posted somewhere online when either it’s part of the process of “completing the jam”, or if I’m working with a team, and someone else takes the helm. I’ve decided I should be keeping track of these somewhere, and that place is, for the moment, organized chronologically below.
Also, here is my Global Game Jam profile. Other random jam-related profiles: I have one at one game a month (though I haven’t really used it in years), and grid.itch.io, which only has one game-jam game on it. (Though someday I hope/plan to post more there.)
I think I found them all, but who knows. In the future I’d like to make a “page” out of this list, and link it somewhere more prominently. (Maybe with images from each of the games!) I’ll add a link/note here if I do that, for posterity.
I’ve always wanted to make some interactive fiction, and last month I decided to spend some time working on a procedurally generated Inform7 game. You can read more about it on the Github “Issue” thread where I announced my intent to participate, but I’m reposting my final “wrap-up” entry here:
Post-mortem / wrap-up post:
Mainly, I didn’t make a 50k word “story”. Although you could maybe argue that the inform “story” isn’t the “whole story”, that’s what my script generates, and I was planning on using that for the word-count metric. My plan for getting to 50k had basically been to increase the number of rooms the script generates until I hit that number, but that isn’t possible because some of the items I’m using for randomization don’t contain that many items. (And I didn’t realize or notice this until just now as I was prepping this post!) Turns out I can only push the script to ~25 rooms, before it tries to randomize from several sources with only that many items. The word count at 25 rooms is only about 4700-4800.
Also worth noting that version with 25 items doesn’t always work. I went ahead and pushed an example of this output as `output/v0.5-source-broken.txt`. Pasting that script into inform gives errors that I’m probably not going to take the time to fix. (Essentially, some of the source for my randomized room text is probably problematic, and should be excluded.)
Additionally, I’m pretty sure the game as-is at the moment of this writing isn’t that fun to play. There isn’t enough randomization of the puzzles. Essentially, each room has the same fetch quest. (If you’d never played it before, and went into it without my spoiling it for you –which I’m not going to do here– it’s possible it would take you a bit to figure out, but once you did, you’d know how to solve every other room, and it would grow tedious pretty quick. I think the version with 4 rooms (in a 2×2 grid) is probably the best way to play. There is some novelty in the randomized room names and descriptions which can sometimes be pretty surprising. It might be fun up to 12 or 16, but again, it would get old pretty fast in its current incarnation.
Another failure, I could argue, was my goal of learning Inform7, but I’ll write more about that in a bit.
Because I wasn’t really happy enough with the output of this script to post it anywhere, I also didn’t submit it to ProcJam. That was/is also definitely a fail.
I wrote some Python! Python is ridiculously easy to write. It feels a bit like I say this about every new language I learn these days, but learning the syntax (there is almost none!) and the various APIs was a very minor part of this project, and generally quite fun and easy. Debugging errors was quite easy, as error messages were very easy to search for, and often even that step wasn’t needed.
I learned quite a bit about writing Inform7! Unfortunately, that’s about the best I can say about it. Inform got harder and harder to work with, and was generally the opposite of my experience with python. My take-away from Inform is that you want to write one sentence at a time, compiling after every one. Every new thing you try and do will require searching through the documentation for an example you can copy/paste. There were dozens of times when I would modify even just one word from an example and then scratch my head about why that changed caused it to stop working. And debugging was always a nightmare. The error messages sometimes contain (sometimes hilariously) a bit of randomization themselves. This seems interesting/funny the first few times you see the same error and the text is different, but the 3rd or 4th time, when you are at wit’s end, it’s no longer funny. Here’s an example of an inform error (but not one with randomized text, I don’t think):
You wrote ‘now the Greyish Blue Book Of Matches is nowhere’ , but although ‘the Greyish Blue Book Of Matches is nowhere’ is a condition which it is legal to test with ‘if’, ‘when’, and so forth, it is not something I can arrange to happen on request. Whether it is true or not depends on current circumstances: so to make it true, you will need to adjust those circumstances.
In general, my take-away is that Inform7 syntax is a great big can of worms. It would probably take me a month of working full-time to really understand the entire system and how it all works together, and feeling competent in it would probably take much longer. (This was obviously not that month!)
Wishlist / TODO list
If I wanted to spend more time on this project, these are the things I was planning on doing:
* Randomized puzzles. Right now there is really only one type of puzzle. I would love to have 4 or 5 types (at least!), and generate different room descriptions based on the type.
* Additional inform elements: Right now, there are rooms, objects (some edible), containers, and that’s about it. I really wanted to get to the point where there was also a randomized person in each room. The amount of things you can do with Inform is staggering really. I’ve only just scratched the surface, for sure.
* Finally, making this available to the rest of the world. This boils down to how I wanted to do this initially, and how I think it’s feasible. Both would have been published as a webpage. A) I wanted to make a version that was different every time you play it. But the only way I could imagine that happening would be to install the command-line version of inform on a server, and at request time, generate the source, compile it, and redirect the request to that output. I’ve no idea if that’s practical, but it’s not something I wanted to attempt. B) The more practical alternative would be to generate a bunch of outputs all at once. So that would be writing another script to run my `game.py` script X number of times, saving the output off to a tmp directory, then using the command-line version of Inform7 (i7) to compile each output and save off a web-playable version into a subdirectory somewhere. Tentatively I was planning on doing this 365 times and then writing some kind of index.php to swap them out based on day of the year.
I really enjoyed working on this project, and learned a lot about Inform7 and python, but wouldn’t really consider this a “successful” project, mostly because I just didn’t spend the required time on it. There is always more you can do, of course, but in this case, I didn’t take the project far enough where I think it’s ready for public consumption. (It is all public, however, and anyone can play with the stuff I created. If you do, I’d love to hear about it!)
This year’s Global Game Jam is over, and from my perspective it was a raving success. I took part with the other IGDA Twin Cities folks, as part of a relatively large team focused on making a local multiplayer game using Xbox controllers. (Click the image to read more about the project I worked on.)
The weekend began on Friday night with everyone “pitching” at least one idea for a game in front of the group. As there were about 40 people there, this took quite a while. Then people started splintering off into groups. I went into this year’s Global Game Jam with several “agendas”. (Incidentally, I probably wouldn’t recommend this for beginners, but this was my third year taking part, and at least my sixth game jam, so I felt it was okay for me to have some goals.) Here is a list of those goals, in order of importance to me, and whether or not I felt they were achieved:
As I mentioned, Friday night was pretty “unfocused”, but I still felt like it was worth it, because I got to learn a lot about controller input in Unity, and thus, also a lot about Unity in general. I was also instrumental in setting up version control for the project on Friday night, but I’m not sure that was a “success” really. I’ll say more about that in a bit. When I left around 4 AM on Saturday morning, there were somewhere between three and five independent “ideas” getting floated around our group, but only one (Bird Drop) had anything appearing on the screen. When I showed up again on Saturday, Bird Drop was playable, and quite fun! I spent a few hours implementing the score display, as well as the system that triggered the game over screen and restarted the game after about 10 seconds or so. Eventually, I also worked on the over-arching menu system, as well as implementing sound effects.
In addition to my personal goals, here are some bullet points about “What went right” from our team’s perspective (although this is all still “in my opinion”, I’m not speaking for the team here or anything):
This would not be a true postmortem without some bullet points about what went wrong over the weekend:
Overall, it was a great weekend, and I had a blast. Thanks to everyone on my team, and to everyone who participated at our location!
Here is my submission for this year’s global game jam: Heart Burn. Much like last year’s Global Game Jam, I wasn’t in attendance for all that much of the weekend after Friday night. But while I was there on Friday night, I made up a quick 25 card deck using colored post-it notes and a calligraphy pen. There were five colors and five “symbols”. You can see them in this image.
Already August, (who I collaborated with for the first time on last year’s game jam game Eat Thyself), has come up with some better looking artwork, and he and I are planning on working together to polish up the app’s look and feel, and possibly publish it to the app store.
The concept and rules are quite simple: An iPhone app (code created during the game jam is up on bitbucket) will tell the players both whose turn it is to play, and what cards they can play. The game uses the “No cheating (please)” diversifier, which means that you’re basically on your honor not to cheat and play when it isn’t your turn or not to play the wrong cards. And it needs that diversifier, because, at least as it plays right now, the game is far too fast-paced to pay attention to anyone else’s cards!
About halfway through the weekend, I decided I should make the game playable without the custom cards, so I spent most of my time on Sunday making it work with a standard Euchre deck. If we release the app, it’ll have a setting to play it either way.
Here’s a clip on youtube of the game being played at the gamejam.
A couple of weeks ago, I went to 360iDev, an iPhone/iOS conference that has been going on for a few years now, devoted entirely to iPhone (and now iPad) development. I actually went last year too, and that year had been to WWDC only a few months before. It was my first time at either conference, and I got a lot out of both of them. But the fact that 360iDev can even hold a candle to the flame that is Apple’s flagship developer conference (WWDC) speaks volumes about how great it is. This year, I elected to go to GDC instead of WWDC, but I still wanted to go to a big tech-focused conference, so I went to 360iDev.
Both years at 360iDev, I took part in the 360iDev Game Jam. (I also wrote a blog post about the game I made last year, which I then called ColorWheel.) This year, I teamed up with a guy named Levi that I’d never met or worked with before, we managed to make a pretty cool (albiet very simple) little puzzle game in the allotted 12 hours. I’ve tentatively started calling it Cloud Growth. I just finished a write-up of Cloud Growth (UPDATE: I’ve recovered the text from the game jam site, which no longer exists, and posted it below this post.), including some more details about the game’s development over on the Game Jam website. The theme of the game jam this year was “growth”, and our game heavily features clouds, so the naming was not particularly creative. The mechanics aren’t particularly creative either, but I can’t remember playing a game with them before, so I do want to polish this little prototype up, and release it at some point.
Anyway, Game jams are awesome. If you are interested in making games I would highly recommend the experience. But don’t take my word for it! At 360iDev, I attended a talk by Phil Hassey, an indie game developer who made a name for himself with a fantastic RTS called Galcon. Phil’s talk was mostly a postmortem for Galcon and his latest game Dynamite Jack, but he must have plugged Ludum Dare about twenty times. (He helps run the thing.) Ludum Dare actually happens bi-monthly. I was going to participate in August, but spent Friday evening working on a project to make games easier for me to write instead. (I will probably talk more about that project here on this blog eventually.)
It feels these days like there’s a game jam every weekend. Last weekend, for example, there was a game jam devoted to making games in the universe of Adventure Time, the TV show. (If I hadn’t been exhausted from a full week of 360iDev, and my lack of sleep that Tuesday night, I’d have been seriously tempted to take part, because Adventure Time is awesome.) A few months back there was a game jam where the participants were supposed to create games inspired by a twitter parody (@petermolydeux) of the relatively famous game creator/producer, Peter Molyneux. I think Peter Molyneux even attended the event!
Previously, I’ve also participated in the Global Game Jam. I can’t wait to do more of them.
Cloud Growth is a simple action puzzle game collaboration between Martin Grider (@livingtech), and Levi Brown, (@levigroker, blog).
We did about ten or twenty minutes of brainstorming, and eventually decided on this concept where we are placing simple clouds on a grid of open sky. There is a cloud “queue” in the upper right hand corner of the screen, so you know what the next one to be placed will be. Clouds have different colors, and if two clouds of the same color are placed next to one another, they will grow into a square of one size larger than the largest sized cloud of the two. You get points for placing clouds, and more points for growing clouds.
Martin wrote all of the game logic and most of the view controller code. Part of Martin’s enthusiasm for this particular concept was that he wanted to continue work on a generic GameModel object he’d been writing that abstracts away the “game grid”, as well as touch interactions on that grid. This was a resounding success, and much code was added to that library.
Levi did all the artwork and animations. These screenshots do not adequately capture the awesomeness of those animations. When a cloud is placed, for example, there is a really great bouncing effect, that is just fun to see. A good portion of Levi’s time in the wee hours of the morning was spent ensuring that the lightening bolts (currently shown when clouds reach the 3rd largest size), begin at the cloud of their origin, and end at the lightening tower at the bottom of the screen.
* Part of the original concept was that the clouds would get removed from the gameboard after a certain threshold, but as the clouds cannot currently grow more than three times, that made the game far too easy. When code is written for larger growth, this idea will be revisited.
* Some kind of lightening counter would be fun, maybe with progressively harder levels as the counter is filled.
I put together these slides to talk about my Global Game Jam entry, Eat Thyself.
…I also printed the following games for playing at our IGDATC meeting. (Where I did this presentation.)
Elegance in Game Design
Wikipedia says elegance is “the attribute of being unusually effective and simple”. I think the word “effective” here is very important. Essentially, if a strategic game is our goal, the more strategy we can create with the fewer (and thus more “effective”) rules, the more elegant the game design. Obviously, fewer rules equals a simpler design. Thus a simple game with complex strategy is elegant.
When I say a video game is elegant, (or board game, or a piece of art, or music), I actually mean it is deceptively complex. It may seem simple, either through simple rules, or simplicity of design, but through the interactions of those, it turns out to have some hidden complexity. For example, the rules for chess are fairly simple, a child can learn them, but the strategy that emerges from these rules is incredibly complex and there have been literally hundreds of books written about it.
When I play board games or video games, I have always appreciated this simplicity that leads to complexity. So far, even without necessarily thinking about these concepts explicitly, I have also attempted to incorporate elegance into my own game designs.
Emergent Complexity vs Rules Complexity
There is a whole camp of board games that doesn’t even attempt simplicity. If you’ve played a lot of board games, you probably know what I mean, rule books that are 20 pages long are not all that uncommon. I would generally have called them ‘ameritrash’ before today, (although the term is stupid for many reasons, not the least of which is that not all games with that monkier come from america) but then I read the board game geek page on ameritrash, and realized that I’ve been thinking of that term slightly differently from its commonly accepted use. The wiki page emphasizes the importance of theme in these games, and luck. It’s probably the luck I have a problem with, though that is not in opposition to simplicity and emergent complexity.
Anyway, let it suffice to say that there are a whole crap ton of games out there with what I’ll call now ‘rules complexity’, by which I mean that the game is complex, but that complexity comes more from complicated rules than elegance of design.
360iDev Game Jam
This last week I had the pleasure of attending the 360iDev Game Jam, where I designed and spent approximately eleven hours creating an iPad game I call ColorWheel. I had a simple design, one that I do hope will turn out to allow for some complex strategy when it’s all said and done. In case you haven’t visited the site yet, here is the description I wrote for the game:
Essentially, this is a two-player game, so you play on one side or the other. On your side are six fairly large buttons, one for each color. The colors that are situated across from one another are opposites (in the standard color wheel, google for “color wheel” if you don’t know what I mean), and they cancel each other out when they contact. You press a button, to select a color, and then touch in any of the six rows to “send” a piece down that row. The gameboard is only 6×6, so it’ll fill up pretty fast. Right now I’m thinking two game modes, both limited to 100 moves, or “sends” of pieces across the board. Mode 1 will be “real time”, where you are basically sending blocks as fast as you can to out-race/color match your opponent. Mode 2 will be “turn based”, where you make a move, then your opponent makes a move. When the 100 moves are over, whichever side has the least pieces on it is the victor’s.
I actually think the jury is still out on whether this game will have emergent complexity. There are a lot of choices at any given time (well, 36, I guess–maybe that’s not so many), but the problem as I see it is that for every move you make, your opponent has exactly one move that will counter it. The game, especially in a turn-by-turn mode, could easily stalemate. I haven’t really thought of a good “fix” for that problem… then again, it was made in a night.