Around the beginning of October, I found out that there was going to be an open source XR conference (called FOSS XR) in my neighborhood. I attended, and took some notes. I posted some of my notes in the MSPGameDev slack, and Zach, who runs our local VR & HCI meeting, asked if I would give a short recap of my impressions. I put some slides together, which I’ll embed below the video. There were some technical difficulties getting started, so the beginning of the video is actually as I’m getting into my second or third slide.
I’ve previously only mentioned once on this blog (in passing) that I spent some time a couple of years back working on a prototype for the Blinks game system (https://move38.com/). I backed the first Blinks Kickstarter, and was very excited to make games for the platform when I received my development kit.
I worked the most on a game called Takeover (https://github.com/mgrider/takeover), which I’ll admit doesn’t take advantage of the real-time possibilities that Blinks as a platform affords. It uses the digital aspect for a sort of rules enforcement, but the game is more or less a traditional board game, gussied up in fancy LED clothes. It’s got fairly simple rules that you can read on the Github page linked above (in the README.md file that is automatically displayed on that page). Although since I’ve made a physical prototype, (more about that in a second) I’ve been experimenting with different rules variations.
Takeover was well-received at the events where I showed it off, but much like demoing VR, it’s hard to gauge whether that reception was for the game I’d developed, or the medium in which it was presented. In contrast, Takeover had a rather lackluster reception on the Blinks forums, so I sort of soured on making another game for Blinks. Or probably more accurately, I just didn’t have another idea that compelled me to spend the time it would take to code it for the platform. (It’s also worth noting that all of this happened before I got the final retail version of Blinks in my hands, and by the time that did occur, I hadn’t worked on anything Blinks related in several months.)
Fast forward about a year, and it occurred to me that, precisely because Takeover doesn’t use the Blinks platform to its fullest advantage, it would be entirely possible to play it with only physical components. This of course led to the question of what those components would look like.
I landed on 3D printing hexagonal trays with “slots” for 1 cm cubes to sit in. Because I think there’s a chance other game designers have these 1 cm cubes laying around, and they might also have access to a 3D printer, I’ll also make the .obj file available for download.
To use this, you’ll obviously want to print a bunch of them. I think there are lots of possibilities for these above and beyond “simulating” blinks games. If you come up with something cool, please let me know!
There are a few different specialized “languages” out there now for describing games. Perhaps because Abstract Strategy games are often quite “simple” in terms of rules complexity, these sorts of game description languages typically have examples that are abstract strategy games. (But also, I think, there’s probably an overlap between people interested in this topic and people who are interested in games that require an extraordinary amount of logical analysis to play.)
I have been very interested in this topic many times over the years as I became aware of various projects and aspects of this topic, and this post will be my attempt to outline some of my findings.
Early game description work / History
There is a relevant “History” section of the Wikipedia article on General Game Playing (https://en.wikipedia.org/wiki/General_game_playing#History). This is a page on Artificial Intelligence (AI) that can play multiple games – as opposed to a specialized program that just plays a single game like Chess, for example. The article says that this concept was first proposed by AI researcher Barney Pell in 1992, with something the article called a “Metagame System”. Pell’s research, at least some of it, is still available via the wayback machine, and I read through one article called “Metagame: A New Challenge For Games and Learning” (https://web.archive.org/web/20070706185808/http://www.barneypell.com/papers/metagame-olympiadUCAM-CL-TR-276.pdf) from 1992 that was surprisingly readable (and fascinating). In it, Pell says:
“In order to write programs which can accept a set of different games, we must specify how these games will be represented. Although fully-general representation languages are possible (like first-order logic or Turing Machines), it is likely that classes of games will be much more specific, especially those which can actually be produced by a generator. So, any representation language can be used, so long as the games produced are guaranteed to be unambiguous in the chosen representation, and so long as the semantics corresponding to the representation is clear. A natural method of representation, pursued in ([Pel92]), is by means of a game grammar.”Metagame: A New Challenge For Games and Learning
“[Pel92]” here refers to a companion article titled Metagame in Symmetric Chess-Like Games. This second article does get far more into the weeds with details about the game grammar used to define games that the Metagame-playing AI will learn to play. I found it actually kind of disappointing, because much of the article is dedicated to defining the types of game the grammar will describe, and it was surprisingly limited in scope.
It’s worth saying a bit about the context of these papers, and noting that this research is all about developing AI. The premise here is that an AI that can play multiple games would be more useful than an AI that can just play one game. The whole point of this project was to be able to pit different AI against one another in a tournament. This grammar was going to be used both to more easily facilitate the AI learning the games, but also to generate new games so the AI would be playing something never before encountered.
This is probably worth repeating: The earliest effort to formalize a language for describing games was only undertaken in service of an effort to teach games to computers.
Zillions of Games
I remember playing a program over 20 years ago now called Zillions of Games (http://www.zillions-of-games.com/). The copyright on the ZoG website says 1998. I remember using it to play Othello and many Chess variants, and (perhaps more importantly) explore a ton of other games that I’d never heard of before Zillions. They were probably also games that it would have been near-impossible at the time for me to hunt down in physical form.
Zillions of Games came bundled with ~250 games, each of which was described individually in a .zrf (presumably “Zillions Rules File”). If you owned the full unlocked copy of the game (this was the shareware era when game demos were near ubiquitous), you could import your own ZRFs, and there was (amazingly still is!) a community of folks who spent time implementing new games.
I have a very distinct memory of liking Zillions of Games enough that I wanted to learn how to develop games for it. But I was in college at the time, and distracted by many other things vying for my attention.
You can find some information about ZoG, and the language used to encode the games, on the website, but also on Wikipedia (https://en.wikipedia.org/wiki/Zillions_of_Games). The description language for ZoG is lisp-looking, (with parenthesis everywhere). I only call this out because it’s influenced future projects with this gaol. ZoG had lots of limitations. It was notably not suitable for card games or other games that required any hidden information, probably because ZRF had no concept of variables!
It’s worth noting that, while it’s not exactly the same thing, I do see a parallel between ZRF creation and other platform-specific game creation languages, like Game Maker Studio’s GML, or Godot’s GDScript. Zillions of Games was a Game Engine as well as a product that allowed the user to play the games made in that engine. The games just happened to be board games.
More recently, (in the last few years), I’ve been aware of a project called the Ludii General Game System (https://ludii.games/). This is (at least partially) the brain child of Cameron Browne, a game designer, computer scientist, and author, who is very well known in some abstract strategy game design circles. He wrote a book on connection games that I have on my shelf.
Ludii has some very interesting project goals, but more importantly, the project has now written description files for literally over 300 games. (There are over 2,000 games with descriptions for use in Zillions of Games, but that software is quite old now, and I think Ludii is far more interesting.)
You can download Ludii now, and play all of the games it comes bundled with, and even create your own .lud files and load them into the player. There is a language reference for Ludii (https://ludii.games/downloads/LudiiLanguageReference.pdf) that is 386 pages long!
To really dive into Ludii development, unfortunately, I don’t think the language reference is going to be enough. There is also a Ludii tutorials document, but I found it a bit disappointing in its brevity. As of this blog post, there are really only two pages that are particularly relevant to writing your own .lud files. This one on the “basics”: https://ludiitutorials.readthedocs.io/en/latest/lud_format_basics.html and another one on recreating the game Amazons in Ludii: https://ludiitutorials.readthedocs.io/en/latest/tutorial_amazons.html I also watched a nice introduction to Ludii on youtube. (https://www.youtube.com/watch?v=pTkO8h8RBBI)
I’m in the process of posting a few different places (in various BGG forums) to see if there are better tutorials that I’ve just been missing.
For the sake of putting everything I know about this subject into this post, it’s worth noting there is another competitor to Ludii that may have been around even before it, called GDL, or Game Description Language (https://en.wikipedia.org/wiki/Game_Description_Language) GDL looks like it was developed at Stanford, very likely in conjunction with some AI coursework. I’ve dug around some of the GDL related sites and there are broken links galore, but there’s lots of information about it online. Some of the earlier Ludii papers reference GDL, so I’m fairly certain it came first.
One more footnote is that there is another comparatively young project aiming to do some of this same kind of stuff in python called Zero Play (https://donkirkby.github.io/zero-play/).
So it seems to me that there are a few reasons someone might be interested in describing games (in a language tailor-made for that purpose):
- To improve and teach generalist AI to play multiple games.
- To generate new games programatically.
- To use a common codebase to facilitate the playing of games.
I am interested in all of the above. Although the implementation details of AI optimization and improvement are not in the circle of my particular venn diagram, access to generalized AI is of interest to me. (I thought about splitting #1 into multiple bullet points.) It’s worth noting that the last project mentioned above (Zero Play) is named after AlphaZero, (https://en.wikipedia.org/wiki/AlphaZero) a general game playing AI that was created by the same team that made AlphaGo. (AlphaGo being the Go-playing AI that famously beat one of the best human Go players in a series of very public games in 2016.)
The second bullet point is definitely one of the goals of the Ludii project, and one that Cameron Browne has extensive experience in. Games which have been created by computers are listed in a “family” on Board Game Geek (https://boardgamegeek.com/boardgamefamily/22566/misc-computer-generated-games/linkeditems/boardgamefamily), (containing at this time only three entries, two of which have Browne listed as designer). Probably the most well-known AI-created game is Yavalath (http://cambolbro.com/games/yavalath/), which Browne created using an earlier program (called LUDI) while he was working on his Ph.D. in 2007. While the earlier work by Barney Pell definitely indicated this was an objective, I didn’t find any evidence that it succeeded.
Finally, it is the facilitation of a general platform for game playing (& playtesting!) that I think a description language will be most valuable to me, personally. This is the primary reason I am interested in Ludii. Ludii’s platform (java application, but also online multiplayer) seems very stable, and has an increasingly tantilizing list of features. There is a category of simple games in particular (with simple rules) that seem to be a very nice fit for the platform. On their forums, the Ludii team have said that web-playability is on their roadmap, and that will lower the barrier to entry even farther.
I am going to try and implement some games in Ludii, and evaluate whether it’s a good platform for playtesting new games. It already includes features for analyzing games like 1st player advantage, and branching factor. These are metrics for their games that every game designer will probably find interesting.
After writing this post (and promoting it on BGG), Cameron Browne actually pointed me to some additional resources relevant to this discussion, (which led me to even more resources) and thought I’d drop some additional bullet points in here.
- Brown pointed me to an article by Jacques Pitrat from 1968 called “Realization of a General Game Playing Program”. In his words: “… doesn’t specify a GDL as such, but shows that the idea of GGP has been around for more than half a century!”(https://www.semanticscholar.org/paper/Realization-of-a-gener…) Alas, I haven’t yet found a way to access the paper.
- Jon Orwant wrote his Ph.D dissertation in 2000 about what he calls the EGGG (Extensible Graphical Game Generator): https://dspace.mit.edu/handle/1721.1/9164
- Stephen Travener’s program Ai Ai uses a description file type called MGL, for Modular Game Language (http://mrraow.com/index.php/aiai-home/mgl/). It’s worth noting that Stephen Travener is a person quite relevant to this discussion, as he has worked on both Zillions of Games and Ludii, as well as his impressive Ai Ai software, which is also capable of playing and analyzing hundreds of games.
- Browne pointed out that there are description languages for card games (I haven’t done any research into this yet.) and Video Games. Specifically, he pointed me to General Video Game Description Language (GVGDL), which I haven’t been able to find in a quick search, although there are plenty of hits for VGDL, and I haven’t really looked into that yet either.
- Finally (again), the Ludii project website has a history page that I hadn’t read until after posting this. It outlines the history of a few other projects that led to Ludii’s creation, including Browne’s previous project Ludi, which I at least mentioned earlier. Well worth a read if you’re interested in more on this topic. (https://ludii.games/history.php)
Special thanks to Zach, Tommy, and Rob from Space Mace for letting me help out on their awesome project.
Below is the release trailer. (Not to be confused with the announcement trailer that I’ve already posted!)
Status: (It’s out now!!!) pic.twitter.com/97iB453hbe
— Martin Grider (@livingtech) October 11, 2018
In part because I’ve only just found out that someone beat Threes! for the first time, I’m finally going to write a post about my game Slide Quest.
But it won’t (just) be about Slide Quest… (Feel free to skip to the list of my three favorite Threes!-inspired games below.)
Okay, first off, I’ve never publicly talked about Slide Quest before. There are several reasons for this, but namely I’ve been embarrassed by it. I actually never meant to release it. (This is hard to believe, I know, but in some past versions of iTunes Connect — apple’s publishing webapp — you had to set a release date for your app. If you started creating the app in there, but you didn’t know if you wanted to publish it, one technique was to just set the release date to some far off date in the future. I did this, but then that date passed, and the app was released. No fanfare, I didn’t even get notified, or if I did I was too busy with client work to notice.) Anyway, when I found out it was released, it was to a few pretty terrible reviews. (It was basically not much more than a prototype.) I decided I’d rather it was out there than not, but I felt dumb, and basically never promoted it in any way.
The point is, within a month, there were probably hundreds of games inspired by Threes!, both in the app store and elsewhere. For more about Threes! and clones, you should read the Polygon writeup, but also read the post by the developers of Threes!, where they also post all their correspondence (emails) during the game’s creation. That post is rather heart-breaking, but the email archive is actually a pretty amazing resource for aspiring game developers.
Anyway, I loved Threes!, and played the hell out of it at launch. I bought the tshirt. At some point I started thinking about an RPG with the same “swipe mechanics” as Threes!, and the thought kept me up at night. I too put together a prototype of that game in a weekend. That game was initially called RPGeez, but eventually I changed the title to Slide Quest.
There are several subtle differences (aside from the obvious aesthetic ones) between Threes! and 2048. In Threes! a swipe only moves each of the tiles on the board one space; in 2048, they move until they can’t move any farther. There are of course other differences, but this is the main thing.
With Slide Quest, the main mechanical difference is that there is a character on the board. That character is “you”, and you slide around the board with every swipe. You have a level, and you level up if you attack (combine with) a monster on the board that is the exact same level as you. You can attack and defeat lower level monsters without effect. Higher level monsters just block the board and lead to (eventual) game over. Like 2048, Slide Quest is definitely much “easier” than Threes!, but it does have one more interesting twist, in that every 33 levels, the algorithm for what level monsters spawn on the gameboard changes, getting more difficult.
Over the 3.3 years since Threes! was released, I’ve sometimes taken note when I see other games inspired by Threes!, mostly because I’m curious to see how they tweak the mechanics.
Stencilsmith, by Nicholas Sepi Jr. — This game is probably easiest to describe as Threes! meets Minecraft, though much simpler than that makes it sound. Essentially, there are pickaxes that need to combine with land to make materials, and the materials can then combine with pickaxes to make more powerful pickaxes. There are also swords, which need to combine with materials before they can then combine with enemies to take them off the board. You have three hearts (in the main game mode), and when you combine an enemy with something not a sword, it takes a heart.
SideSwype, by Radiangames} — This game combines Threes!-style swiping and match-3 mechanics. I really enjoyed it, and it’s got an elegant graphical style. Incidentally, it’s also by the developer of Slydris, which is an amazing game.
Puzzle Chips, by Curt Stein — Curt Stein created one of my early app store favorites called DropOut. In this poker-chip-themed take on the genre, each tile is a stack of chips. When the stack gets tall enough, it can be tapped to remove it from the board. So basically the numbers don’t really combine or increase, but as you play, chips that are worth more will spawn more frequently.
In a post back in 2014, I talk about small grid games, and said that 2048 was my favorite threes-inspired game. But in my memory of the time, I didn’t actually play that much of 2048, I was actually just really excited to surf the many forks of it that added different mechanics. Now when I try and view forks on github (it says there are 15,037), it just gives me the error “Too many forks to display.”
Please let me know (either here in the comments, or over on my twitter) if you have other Threes! inspired games that you like.
UPDATE (2019-06-13): Adding some screenshots and removed app store link as the game hasn’t been live for at least a while now.
Also worth noting that Twinfold by Kenny Sun does what I wanted to do with SlideQuest WAY better than I did. Basically just adds a ton of other elements, and is actually more of a “real” game than SlideQuest ever was, while basically being a similar progression-based high score game. Highly recommended.
Via a slack I’m on, I only just this morning became aware of the MegaProcessor, a 16-bit microprocessor with LEDs attached to all the gates and transistors, that is then blown up to the size of a room and mounted on walls so you can see it working.
Oh, and it plays Tetris.
Frankly, this thing is amazing, and I would love to see it in person one day. Here’s the computerphile video that let me know of its existence:
Elements of Tetris
Tetris is so simple, you might (mistakenly) think it’s the simplest possible version of itself. (The original gameboy Tetris, not whatever feature-laden version happens to have been released this year.) It’s fairly easy to make a list of the various “elements” that go into Tetris. (I’ve always called these mechanics, although someone online recently pointed out mechanisms might be more appropriate.)
– Blocks made out of 4-squares (tetrominos)
– A column-shaped gameboard
– Gravity, the tetrominos move from the top of the screen to the bottom, where they stick in place
– Line clear when a row of blocks is completely filled
– a score counter that increments when lines are cleared
Sure, there’s probably some other stuff in there, but at a very high level, I think these are the most interesting elements. The last few months I’ve spent a lot of time playing a few different games that I think basically fall into a new “branch” of the Tetris family tree. One where the main difference is that they’ve replaced the block-falling gravity with free-form block placement. Turns out, this makes for a bunch of interesting games!
I guess I probably saw Hex FRVR first, back in October, when it hit my “Tetris” google alert, and then shortly thereafter as my Twitter feed exploded with it a bit. I think there were probably just as many people impressed that the mobile web app (the game is fully playable on its website) functioned as well as the mobile app as there were folks commenting on the game itself. Although plenty of folks did comment on how easy it was to get sucked into it. I got pretty hooked, and was still playing it in November when I went to Practice.
Over thanksgiving, only a few weeks later, my brother Dan introduced me to 1010!, which evidently he and his girlfriend have been playing for a while now. I hadn’t seen it before, but I guess that’s not terribly surprising given that about 500 games come out every day on iOS. Looks like it first came out September 2014, for iOS anyway, and it’s been successful enough that they’ve released 1010! World, which is basically the same game broken up into finite levels and put on a map like many of the big puzzle games do nowadays. (Candy Crush etc.)
1010!, played on a square grid, does that mechanic swap I mentioned, bye-bye gravity, hello touch-and-drag, but there are some other pretty major differences too.
It’s played on a ten-by-ten sized game grid, and I’m assuming that’s where the name comes from. 1010! also does away with having a single available piece, and showing you the order of the upcoming ones. Instead you have three available pieces, and see nothing further until you play the last of them. In fact, most of the strategy in the game comes from effectively using the three you are given together to clear some of the board before the next three.
Always Be Clearing
But if 1010! were just giving you tetrominos, it would probably be too easy. I’m guessing I could play indefinitely unless something more was changed, which it is. (In fact, it’s worth noting that 1010! doesn’t include the J, L, Z, or N pieces at all.)
So to balance the game toward ending, it throws in blocks of the following (important) sizes: 1×5, and 3×3. Sure, you can lose from the other block sizes if you’re not careful, but mainly, it’s going to be one of these two that you will inevitably not be able to fit onto the gameboard, thus ending the game.
I think it’s this balance (when to throw you “hard” pieces, and what percent of the time to just give you the basics) that makes both 1010! and Hex FRVR good games. They are both tuned to let you play for a bit, but then stump you not that long after. Playing for a while feels like an accomplishment, the classic “high score high”. Whether the games give you essentially random pieces, or just the illusion of random pieces, I cannot say, but just as in Tetris, you can easily talk yourself into believing the game is not random. Maybe it’s giving you this piece just when it knows it’s impossible for you to play it.
Everything is a Remix
It’s no secret that a lot of my game ideas are also inspired by Tetris.
Right now I’m working on a port of my first game (playable on this site) to iOS. It’ll be called Action Go, and will play like the web counterpart, but look a whole lot better. The entire inspiration for that game was, “What if I removed line-clearing, and replaced it with the capture mechanism from the board game go?” I’m not planning on removing the web version, but the new one adds a lot of stuff, so I hope it’ll find a following on iOS and Apple TV when it comes out early 2016.
PS, It’s all been done
By the way, I have no idea if the Hex FRVR folks know about 1010!. But it’s a pretty fair assumption that they do. After I spent some time thinking about this, I realized I could whip out a triangle-based game with similar mechanics in very short order. A quick search later, and I’d found Tringles, which does exactly that. (Good thing I didn’t waste any time prototyping!)
It’s easy to see though, that there are nearly infinite ways you could take just a simple game and swap out one mechanic, (and adding a few more where it makes sense after that) to get a whole new game. Or hell, a whole new genre of games.
If anyone who works on 1010! read this, know that the app is crashing for me on my 6s+ like every 2 minutes. I don’t think it was doing this until the recent 9.2 update. Please fix it. I have an addiction to manage.
For the last couple of weeks, I’ve been citing an offhand comment some eyeo presenter made about the importance of experiencing “awe” regularly in your life. After getting over that slight discomfort I always feel when citing sources whose sources I absolutely don’t know, I’ve been finding it an easy justification for all kinds of actions and decisions I make.
So I did some googling. This interesting slate article by an “emotion scientist” suggests that the state of awe provokes thoughtful reflection and skepticism. This makes sense to me because I think one thing I find so appealing about “awe” are the big ideas. And big ideas give you perspective. If I’m contemplating the nature of the cosmos, that bug I’ve been working on for the last few hours seems rather less important. (Which I’d argue often helps to solve it, but that’s another blog post.)
This Atlantic article cites a Stanford study published in 2012 whose title says it all: “Awe Expands People’s Perception of Time, Alters Decision Making, and Enhances Well-Being” This huffpost piece cites a paper written in 2013 with another telling title: “Approaching Awe, A Moral, Spiritual And Aesthetic Emotion.”
This quest for awe is absolutely why I made it a priority to go to eyeo festival this year. It’s why I went to Northern Spark last night, and stayed up ridiculously late looking at art. The eyeo presenter that I quoted said it’s why we go to museums. Finding awe is often what drives my decisions around what to work on when I have spare time, and what to spend my recharge time doing in my evenings and off hours. Now I just need to figure out how to trigger it with the games I make.
It’s been a while since I’ve posted any Tetris stuff on here, and I ran into some interesting hardware implementations today that reminded me I hadn’t posted about L3D Tetris yet. So…
Last week at the bar after our monthly igdatc meeting, I was showing off the L3D, and took this vine of CubeTube user hape’s L3D Tetris. (Shortly thereafter, the official CubeTube youtube channel also posted a much better/longer video of it in action.)
Frankly, this existing was a load off, since I had already said I was going to write Tetris for the L3D. Now that I don’t have to, I’m focusing on some more original game designs. I should have one I’m calling Match-L3D playable later today. (Though I’ve been saying that for a few days, and I spent most of this morning cleaning up code I wrote last night when it was too late for me to have been realistically coding.)
My impression of actually playing it was basically that there are far more satisfying 3D tetris implementations, unfortunately. It’s just plain HARD, and can be really difficult to “line up” the pieces, especially the farther into the cube you’re looking. The L3D has a pretty serious problem with reflections off the plexiglass, and that didn’t really help with the playability either.
Over at the HackADay blog, they posted yesterday about user Alex’s Arduino Tetris on an LED Array. That one was pretty plain looking, (not to diminish Alex’s efforts, I’m sure he learned a lot putting the project together!) That post links to a previously posted project (shown above) called Breadboard Tetris, as well as another running on an oscilloscope. But their blog is actually a cornucopia of LED Tetris links! Many more are findable by searching their website, including Tetris wearables, like this LED tie, and a sweet looking arduino bracelet.
If you want to build your own LED Tetris, there is an instructable you can follow, (although comments imply it’s incomplete, so maybe you’ll have better luck with this other one). Anyway, hardware hacking is getting easier and easier all the time.
Many of these projects post their Tetris code, and it would be a fun exercise (though not one I’m about to undertake just now) analyziing how they all go about implementing the various challenges inherent in writing Tetris. (Piece rotation would probably be the most interesting to analyze, although 2D grid storage would also be worth comparing and contrasting.)
I’ll leave you with this custom LED Tetris project next to an inflatable dinosaur. It’s a tossup which one is a bigger waste of space. At least you can deflate the dino. ;)