Skip to content

Category archive for: Programming

HTML5 Fluxx: Starting

So I’ve been wanting to get back into coding for fun for quite a while now. I’ve had a few game ideas over the years, but none of them seem to work out. I tend to be overly ambitious and burn myself out pretty quickly. So, this time, I’ve decided that instead of trying to create a whole new concept from the ground up, I’m going to digitize one of my favorite existing games: Fluxx, the card game with ever-changing rules!

For those of you who haven’t heard of or played Fluxx, here’s how it goes: Fluxx is a game where the rules and win conditions are constantly in flux. Hence the name, obviously. The basic rules of the game are simple: draw one card, play one card. That’s your whole turn. There are several different types of cards you can play, however:

  • Keepers are played in front of you and are generally used to fulfill goals.
  • Creepers, an offshoot of the Keeper card type, are played the same way, but are played the second you pick them up, and don’t count as your “play” turn. They also prevent you from winning the game unless the current goal specifies otherwise.
  • Goal cards are played in the center of the table, and define how a player can go about winning the game.
  • New Rule cards are also played in the center of the table, and change the basic rules of the game. Some of them are simple, such as Draw 2–instead of drawing a single card at the beginning of your turn, you… draw 2 cards! Obviously. Some New Rules are much more complex, such as the Inflation card. With Inflation on the table, any time a numeral appears on a card, that numeral is increased by 1. So, if Draw 2 and Inflation are both on the table, you draw 3 cards at the beginning of your turn, rather than 2. However, if Draw 2 were named Draw Two, the Inflation rule wouldn’t apply since it uses the word two, not the numeral 2.
  • Actions are played to mix things up. You can do things like get rid of rules, replay something from the discard pile, or steal other players Keepers.

These are just the rules for the basic version of Fluxx. There are countless variations on the base game that incorporate all sorts of different themes and mechanics, but the base rules and core concept behind the game stay the same. You can check out all the variations over at Looney Labs, the site of the company that publishes Fluxx.

I have a lot of really fond memories of Fluxx, from when I was first introduced to it in high school by several of my friends on the speech team. I’ve played a ton of it since then, and would love to have a version I can play no matter where I am. That’s why I’m doing this in HTML5, so I can play it on any device wherever I am. I also really want to see this project through to the end, so I’ve decided I’m going to update this dev blog on a weekly basis to detail my progress (and publicly shame myself for lack thereof).

I first started this past Saturday by cramming all the details of each card in the base Fluxx game into this Google Spreadsheet. Every card has some basic bits to it: a name, a type, and how/when it is to be played. Some go a bit further than that, such as Action, New Rule, and Goal cards, by explaining the exact effect of the card on the playing field. So, I divided all this information up as best I could, into 6 columns: name, type, subtype, how, effect, and special. Most of the columns are self explanatory, but some need a bit of explanation. The name and type are obvious. The how column contains the text on the card that explains how to play the card. The subtype column is something I plan on using in the code for the rules. It’ll make altering the rules a slight less tedious task, once I get to that point in the code. Right now only a handful of New Rule cards have a value for subtype. The current valid values are draw, play, hand_limit, keeper_limit, and bonus. The effect column contains the text that describes the cards effect on the game. The special column contains any further card specific effects beyond the basic effect. So far there are the only values I’ve needed. I’m sure I’ll add to this data set later, but for now this basic info is what I’m using to generate the cards and the deck.

I started out trying to use the Phaser HTML5/Javascript game development library, but quickly found it to be ill-suited to a turn based game. It’s very good for a real time game, but I couldn’t quite wrap my head around exactly how it wanted sprites/graphics to be handled. I wanted to define the graphics, but not necessarily add them to the canvas/stage right away. For example, the Card object I made; I wanted to give it all the properties I thought it needed, including a dynamically generated graphic that displayed all said information. I could not, for the life of me, find a way to make a graphic dynamically, add text to it, and then add it to the canvas/stage at a later point. I did create quite a bit of the basic code while using this library, though, so it wasn’t a total loss. Phaser is definitely an interesting engine, and I greatly admire it’s creator, Richard Davey (aka photonstorm). He did a lot of great work with the Flixel Flash engine, creating one of the best plugins for it, Flixel Power Tools, both of which I used back when  I was a bit more into making grand ideas a reality. Anyway, I managed to convert my spreadsheet into a JSON file that can be loaded in to define the cards to be used for the game. I managed this by exporting the Google doc as a .csv file and running it through a CSV to JSON Converter I found. I feel like, as this goes on, I might be able to eventually allow for different versions of Fluxx to be playable in my… engine? Or whatever the hell I’m coding.

I decided to see if falling back to an old favorite of mine, Flash, would be a good fit. At first, it felt like it might be. It’s more traditionally object oriented than Javascript, which is nice, but the way I develop Flash/AS3 code is super strict thanks to FlashDevelop defaulting to strict debugging. It got a bit annoying having to worry about assigning a type to everything, and making sure displaying objects would work properly. So I started looking for reasons to not build the game in Flash. It was fairly easy. The game would only work on desktop, and all the good libraries for Flash are out of date because it’s dying a slow, sad death. Plus all the strictness that I’m no longer used to would have probably driven me mad every time I went to test it. And then I remembered the few times I had tried to do anything with network communication in Flash and decided I wanted nothing to do with it. This is going to be a learning experience for me, so I’d like to learn something useful, and Flash is no longer useful the same way it was 3-5 years ago. I thought for about a millisecond that doing an AIR/Flex version would be fine, but it wouldn’t. Trying to make a card game in Flex sounds like a headache, and then the game would be a download, not browser based. Not what I wanted at all.

So I thought for a few days and remembered that a coworker had done a version of Frogger using HTML5 and some Javascript library I couldn’t remember the name of. I asked him about it, and he mentioned EaselJS. I took a look at it, and it seemed perfect. It’s basically AS3 for the HTML5 Canvas element via Javascript. Once I got it set up, I fell right back into it. I got to a point where I was able to construct a deck of cards using the JSON file created from my spreadsheet, shuffle it, and display the top card in the deck. Basically, just a little proof of concept to build confidence. Once I did that, I realized that if I really want this to work, I’ll have to really think out the design of the code.

I want the game to be turn-based multiplayer, so I’ll need some sort of server in place to track the state of the game and accept data from each player. This scared me. I’ve never been good at backend development. I did some Googling and discovered SmartFoxServer, which, at least initially, looked like a viable option. However, this thing has a few too many features. I just need some basic server functionality; I don’t need a whole suite of tools to manage tons of instances of the game. At least, not yet. I did some more searching, and came across this thread on reddit talking about HTML5 multiplayer. The majority seems to be suggesting Socket.IO to handle the multiplayer server end of things, so I’m currently investigating how to utilize it in this manner. I have node.js installed, but I’m getting an error when I try to install Socket.IO. Apparently, I need to install Visual Studio 2008 for some stupid compiler bullshit. I guess I’ll have to do that to move forward.

So, I guess I’m making progress? I’d really like to get to a point where the server controls dealing cards from the deck to players. Just have to figure out how to set up the players, and how to connect them all together.


So, recently, I’ve been playing around with the Laravel framework in my spare time. It’s been a good opportunity for me to not only brush up on my (ancient) PHP skills, but to learn more about the commonly used model, view, controller pattern. I’ve always considered myself an amateur programmer, but Laravel makes me feel like a fucking genius. It’s really been a revelation to see what I can accomplish with a more robust (and well explained) tool set.

There are quite a few things I like about Laravel:

  1. It’s got great, built-in ORM

    Laravel’s Eloquent ORM completely eliminates the need to write SQL queries. I’m not a DBA; why the fuck should I have to construct a robust SQL query? Eloquent makes it incredibly easy to do that.

  2. The built in templating engine is incredibly robust

    The only other template engine I’ve worked with before is Smarty, and it felt somewhat limiting. Blade seems to have a bit more in the way of logic. Plus, the ability to define default templates and simply focus on the content that will be appearing on an individual view is super liberating. I don’t have to worry about including the header, menu, footer, sidebar, etc. each time I make a new view. I just define a layout that has the necessary components, and off I go. Plus I can have multiple sections that all get displayed where I want them depending on what layout I’m using.

  3. Migrations make me crazy happy

    I just moved my Laravel practice project to a new machine. I was up and coding again in minutes, with the same data set, thanks to migrations. Migrations let you rebuild your database in a flash, with all the base data you need to start working. All it takes is a few commands with Laravel’s Artisan command line tool, and you’re back in business.

I’m sure I’ll keep finding things I’m enjoying about Laravel. I’m hoping to use it for a website/app idea I got not too long ago. I’ll probably post updates about that whole thing here.