The game I worked on in collaboration with artist Shiho Pate, and with background music by Nathaniel Chambers, was lucky enough to win not only the Juror’s Prize for Best Game, but also 2nd Place in the Audience Choice Award at this years Global Game Jam at NYU.

I had a lot of fun making the game and am really proud of it. Check out more info here.

I just ‘ported’ Thawed, the first digital game I ever worked on, to an HTML page thanks to the awesome tool Twine.

Check it out here, or by clicking the image.

Recently, as requested by a few students and alums of the NYU Game Center, I created a sample project based off of a 2D platformer I made so that other students could work and learn from it. Beyond just creating and distributing the code, I wanted to make a brief Beginner’s Guide for anyone looking to start making games – specifically, 2D games using Flixel. This requires almost no programming knowledge really, rather just an interest to open up some code and poke around in it.

What is Flixel, you ask? Well the Flixel site answers it like this:

“Flixel is an open source game-making library that is completely free for personal or commercial use. Written entirely in Actionscript 3, and designed to be used with free development tools, Flixel is easy to learn, extend and customize.”

Basically, it’s a library of classes you include in your ActionScript3 project to make a lot of things easier for you. To get started, try to follow this guide to get setup with FlashDevelop or FlashBuilder (hint: you can get a free license of FlashBuilder from Adobe if you’re a student). Once installed, try to follow parts of this Hello, World guide here. However, with that one, about halfway down a ton of the images are currently missing due to some problems with FlashGameDojo.

Now, if you’re like most people, and find these tutorials a bit dryer than playing with some semblance of an actual game, then hopefully this will come in handy. Firstly, download this zip file of a 2DTutorial project I made with the latest version of Flixel (which is included in this zip). Unzip that file and put it wherever you’d like to keep your FlashBuilder projects. It contains all the code and media needed for the project.

Next up, open FlashBuilder. If you’re using FlashDevelop you should be able to follow along fairly well, so do not worry.

Firstly, go to File->Import.

Then select Flash Builder -> Flash Builder Project -> Next.

Then select Project Folder -> Browse -> Navigate to the unzipped 2DTutorial folder you downloaded above and select Open -> Select Finish.

Now you should see the Project in your Package Explorer. If you expand the folders, the “src” folder is where all the code is. In the Default Package, you’ll see all the classes I’ve created for you, and in the Org folder, you’ll see all the Flixel classes.

If you double click on Main, you’ll see the class come up. Now if you click on the Debug or Run icons (or go to Run->Run) the game should pop up in your browser or Flash Player (depending on the settings of the IDE). Voila!

However, there is one precaution we should take with the project still…

Firstly, right click on the project folder that says “2DTutorial” and select Properties. Make sure that in ActionScript Compiler, under Additional Compiler Arguments, we have “-locale en_US -defaults-css-url Default.css” This, along with the blank Default.css class included in the project, stop an annoying Default.css warning from coming up whenever you try to compile the project. Hopefully the project you imported has this taken care of.

If you are running FlashDevelop, you may have to point the classpath of the project to the src folder included in the folder you unzipped from me. Right-click on your project and go to Properties -> Classpath and direct it to the folder entitled “src” that came with the project I gave you.

Now that that’s good to go, let’s run the game and take a look at what we have.

Firstly, if you look closely, you’ll see a Flixel “Preloader” displaying the loading of the game for us. This is a simple built-in feature using the FlxPreloader class you’ll see in the code later.

Then we see a simple menu, made up of a Backdrop PNG and a button. We also control a cursor with our mouse and can select the button to start the game. Note: It’s always good practice to enforce clicking on the flash app to start the game, since it makes sure that the flash app has the user’s “focus.” If the user does not click in the app first, no inputs will be tracked.

After clicking, you’ll see what looks like a level from my game, Chip. You can control the character with the WAD or Arrow Keys, and shoot with the Spacebar. The Robot will chase you, and kill you if he gets to you. That’s all that’s here. It’s intentionally simple, but hopefully through looking at the code, you’ll understand enough fundamentals to start prototyping your own 2D games.

Now, I spent a solid amount of time commenting all the code in the project so I would not have to go over it all in detail here, but I will give a general summary of some basic concepts and what is happening.

First, let me say that I am NOT a programmer by any means. I am, what some would call, “bad” at programming. However, that’s sort of the beauty of working with something like Flixel. Despite my lack of expertise, I can easily create little games like this to tweak and learn from. So while you can use this as a jumping off point, some of the actual code in here might be considered poor practice by some.

The game starts with what’s called the application class, in this case Main.as. Here all that happens is we tell the game its dimensions, to use the preloader, and that as soon as it’s running it should just “switch states” over to the MenuState.as class.

A state is sort of hard to explain, but it’s basically the part of the application that’s running things at a given time. Each menu is it’s own state, and each level is usually it’s own state. States extend FlxState, which basically means, they inherit all of the functionality built into the FlxState class. As a result they can easily add other objects like Players and Enemies and Maps and create and update everything neatly. So, back to MenuState… MenuState is simple. It has the media embedded for the background, button and music of the game, and all it does is show the built in mouse cursor, start the music, and call a function when the player clicks on the button. This function, called PressNew() just tells the game to switch states to the PlayState.as class.

One important concept is how these classes are organized. You’ll notice all media and embeds occur right after the line “public class MenuState extends FlxState { “. This area is called the class declaration (I think) and so stuff like embedded media and variables you need to use throughout the class should go here.

The next key piece is the “Create” function, which is written after the line “override public function create():void”. Here is everything that the state does once and right away, as it’s “creating” itself. Again, everything in here runs exactly once whenever this state is switched to.

The last piece is the “Update” function, which is written after the line “override public function update():void”. Here we put anything that needs to be constantly checked (in actuality it’s around 20 times per second) while we’re in this state. In this MenuState though, all we need is the line super.udpdate(), which tells FlxState to run it’s update function, which covers all we need for this class. However, we’ll really see the update functions shine in the PlayState class, which is where the game goes next.

In the PlayState, we also have instances of our Player, an Enemy, and some ShockBullets, and you can see those are types we defined in our other classes. It might be easier to look through some of these classes first before jumping into the PlayState. Let’s start with the Player class…

First above we setup all the media and variables, and then the constructor is called. The constructor is the function that is basically the same as the “Create” function but for a FlxSprite, not a FlxState. In our PlayState, when we ask for a Player, we’ll end up writing something like player = new Player(100,200);. That last part is us calling the constructor and feeding in 100 for the X value and 200 for the Y value. This is the position we want the player to start. Note that in Flash, (0,0) represents the top left point of the screen, and as Y increases it’s actually moving down on the plane.

Another thing to note here is that this game uses SpriteSheet animation. This basically means we use an image file like this:

for all of the player’s animations. Then in the code when we load the graphic, we give it the individual size of a single sprite (not the dimensions of the entire SpriteSheet), in this case it’s 26×45. Then when we write addAnimation(“walking”, [0,1,2,3,4,5,6,7],10,true) we are telling Flash to play the 26×45 piece of the SpriteSheet all the way to the left (frame 0), then the one 26 pixels over to the right (frame 1) etc. at a speed of 10 frames per second. It’s fairly simple.

The player’s update function is where we hold the controls, and physics of the player. Anything that requires constant checking should go here.

For more details on the Player workings it’s probably easier to just read through the comments in the code. The Enemy is also fairly similar, but has some different logic and doesn’t take any input from the user (again, I recommend reading through the code).

The last piece to touch on here is the PlayState.

Here we “add” a bunch of things to the state, including a Player, an Enemy, a Camera, an array of ShockBullets, a TileMap, and a Backdrop. This happens in the Create function of the PlayState.

In the Update function, we do things like check for collision, keep the player in the bounds of the level, fire off bullets, and call “callback” functions. A callback function is basically yet another function included in the class, traditionally in the bottom. You can see in the update function when the player presses Space I call the function spawnShockBullet(); This line of code actually redirects the program to the spawnShockBullet() function at the bottom of the class, runs that logic, then the program jumps back up to the update function and continues onto the next line.

That’s basically all of the general concepts. Any further finer workings are hopefully explained via the comments of the code. If you have additional trouble you could try asking me in the comments here, but I’d recommend these fine resources over that:

FlashGameDojo

Flixel Forums

Flixel Snippets

Photonstorm’s Site

Also, here are some tutorials that really helped me getting started (and are all honestly probably better than this one I just wrote):

No Idea What I’m Doing

EZ Platformer

Making a Platform Game With AS and Flixel

Building a Retro Platformer in Flixel

Again, I hope this helps some of you to get in there quick and get your feet wet. It’s okay if you don’t understand anything. Just play around with variables and mess with stuff, switch out the music and graphics, and add some more logic until the game starts to feel like your own!

However, given that piece of advice I decided to dive in. Below is a quick overview of the process that ensued before I ended up with this game Chip that I recently “released.”

After installing FlashBuilder (as I work on a Mac this was my only option), I started with the Flixel Hello World tutorial. This great resource talks you through setting up your Flixel Project for the first time, which can be overly intimidating due to small annoyances such as the need for a blank Default.css file and the additional compiler arguments you need to go with it in order to get the Flixel Preloader to run. (This may be fixed in a new version, but I still use flixel 2.34).

After that, I had no concrete idea for a game, but figured a 2D platformer would be a good learning exercise given the resources available to me. I read through and followed along with these two tutorials:

http://chipacabra.blogspot.com/2010/12/project-jumper-part-1.html

http://www.zoklet.net/bbs/showthread.php?t=140683

Both were fantastic, but again, may be slightly out of date now with newer versions of Flixel. At this point I, like Chipacabra, had no idea what I was doing. I didn’t understand the code I was frankensteining together, but slowly I would play around with variables, parameters, graphics, etc, until it started to feel like mine.

Eventually I tweaked the enemy A.I. enough to the point where I had this weird robotic, slow enemy that trailed the player around. Some more tuning of the physics enabled this sort of fun “Make your avatar avoid the enemy for as long as possible” type play, that soon became, “lead the enemy to a certain spot without letting him catch you.”

The rest was months and months of learning what my code was actually doing, learning how to use the Deadly Alien Map Editor to create levels, and all of that other miscellaneous knowledge that the Flixel forums provided me with.

Unfortunately a bit of game design and polish fell by the wayside, and this first passion project of mine lapsed into an idle state on my computer while I moved onto other prototypes and full time design jobs, a trend that seems all too common among other indie developers.

Almost a year and a half passed since I stopped working on the game. A few weeks ago, however, I got bored. After a bit of research into potential release avenues, I decided I didn’t care about (or expect to make any) money, and thought I’d just put it up somewhere public just for my own sanity’s sake. So while unpolished and full of unexplored potential, the game that came to be known as Chip is a relatively complete experience, and you can play it here:

I think the system of the game is fairly interesting: blue gives you points, but speeds you out of control, while red slows you down, but takes away a big chunk of life. It definitely needs something further – some overarching goal or strategy on top of this. Yet as a 2-day work, it’s not a terrible arcade-style game. Anyways, enjoy!

Click the picture to play!

by Bennett Foddy

Girp is simply one of the most interesting physics games I’ve ever played. The controls and use of the keyboard are innovative and personally inspiring. I played this game side-by-side with a friend who had never seen it before this week, and we both laughed and gasped as we finally were able to reach that next letter, which seemed utterly impossible only seconds before. A game that’s both rewarding, silly, and will cause you to exert a tremendous amount of force onto your keyboard is well worth this spot at the top of my list.

Johann Sebastian Joust

by Doug Wilson

JS Joust is the best digital, physical game I’ve ever played. Its sense of ritual and culture has only been rivaled this year by my brief expedition to a Belgian-Style Ping Pong club in San Francisco. Players move in an almost musical, spiritual fashion, as they must balance the momentum of their precious Playstation Move controllers in tune with Bach’s classical music, while trying to disrupt the balance of those of their peers. A pure joy to play and to watch.

Frozen Synapse

by Mode 7

This is a tactics-heavy strategy game where players position troops and use careful timing to arrange their every move and stance. It’s greatest innovation is the ability to exert as much control over your opponent’s troops, creating test scenarios you can preview by inputting what you believe they will do. The result is an almost immediate sense of high-level play and yomi few other games accomplish. My only complaint is that there are simply too many factors at stake, and the crunchiness of the game sort of gets lost underneath that loose feeling. Still a must play.

Triple Town

by Spryfox

Originally for the kindle, and then for Facebook, Triple Town very quickly became my favorite match-three game in a long time. I clocked more hours on Triple Town on Facebook than any other game on the platform this year, and I play a lot of Facebook games for work and research (and some for fun, I suppose). The grid size, frequency of items, and pacing are tuned to perfection, and it’s simply one of the most rewarding puzzle games I’ve ever played. Only in Chess have I thought as many steps ahead in a turn-based game as I have in Triple Town. For about a month after Triple Town came out, it came up almost universally in every conversation I had with a game designer in NY. That about says it all.

Dark Souls

by From Software

Dark Souls is one of the more perfect console games I’ve played. The minimalist atmosphere, the stress-inducing sound-design, and the near mastery of the mechanics initiated in Demon’s Souls result in one amazing experience. It’s so unique, odd and demanding, and I feel so driven to master it, that I’ve probably spent as much time on the Dark Souls Wiki as I have actually playing the game. The open world and bonfire systems open up the game to the point where deciding whether to take one more step forward, or retreat back, is meaningful every time. Turning Humanity into a resource was the near perfect way to remedy some issues I had with the Soul/Human system of the previous game, and the PVP retains all the innovation, joy, and stress as its predecessor. I really, really love this game.

SpellTower

by Zach Gage

Zach is one of my favorite iOS game designers. Bit Pilot and Unify are both excellent games, but he really out-does himself in a genre many of us brush off with SpellTower. The sleek design, the ingenious Boggle-Tetris mechanics, and the wonderful fact that it’s a word game less about knowing obscure words and more about strategic use of the words you do know, make this my favorite mobile game of the year.

Super Street Fighter 4: Arcade Edition

by Capcom

While many people in the community will tell you that Super was the more balanced iteration of the game, I personally loved what Capcom did with Arcade Edition. They knew they had something special, something millions of people would watch online, attend tournaments for, and just get “hype” about, and they played right into that excitement with AE. Many refer to switching to the new characters, Yun and Yang, as a turn to the dark side, but they really do liven up the game. High-powered, offensive, and fast-acting characters may not be as finely balanced as some of the characters in previous iterations, but the personality of the game as a whole is simply more exciting with them included. Even though, AE 2012 ironically released this year, it’s too early for me to see where it’s going, but I do know that I’m excited to find out.

Other games I loved from this year as well and that you should certainly try to play:

Way, Hokra, Where is My Heart, Portal 2, and many others I’m currently forgetting.

Click through the picture to give my latest demo a whirl! (I’ll host this stuff on this site directly in the future, once I finish building this site completely)

A big game I co-designed, The Escort Quest, recently won the audience and judge’s vote for Best Game of the DC Games Festival. Grant and I are super thankful to everyone at the festival and everyone who helped with this game along the way. Most of all I’d like to thank Grant for putting the game on in DC when I couldn’t make it because of work, and our original and always helpful class collaborators, Andrew and Eszter, as well as the professor in the class the game was originally conceived in, Kevin Cancienne.

With each passing month, social games are growing. Growing in userbase, growing in revenue, but possibly most of all, growing in ambiguity. The term “social game” is pretty vague. Most board games involve far more social interaction than games on Google+ or Facebook! However, since sites like those have become the most pervasive locations for online social interaction, “social game” has come to mean any game played on a social network. With everyone and their mom, kid brother, and next door neighboor on Facebook these days, just who is the “social gamer?”

Statistics and stories from the last few years demographically place the average social gamer as an aged 43 female. (See this Gigaom piece that references a PopCap survey.). However, this assessment is far from set in stone, and new data, research, and surveys are constantly reexamining the social game audience. One is a RockYou survey (shown below) that attempts to frame the social gamer as a younger, more male, and more achievement-oriented player; three things that go against what almost anyone whose studied the demographics before would tell you. What is unfortunate about both studies is that they establish a fairly static precedent of the current social game audience. Now, being aware what a specific community of players is currently attracted to is not at all a negative. Marketing depends on it. However, in that strategy lies the the unpleasant feeling that social games are already being designed specifically for the historic demographic of the social gamers, when instead they could be branching out into untapped demographics.

Another perspective comes from a Tim Rogers piece entitled “who killed videogames? (a ghost story)” on insertcredit.com. His essay discusses the mathematical average of a ghost player that companies talk up, but only exists as a fusion of those who actually purchase in game items and those who enjoy the game for free. Percentage wise, 90-95% are the latter who will never spend anything, and 5-10% who will spend an average of 60$. The average of all the money thus far made by social games divided by the amount of people who play them comes out to $1.70. The person who actually spends $1.70, of course, is Rogers’ ghost.

The numbers behind the mysterious ghost player here are potentially dangerous and misleading. The math, as Rogers points out, is riddled with extremes, outliers, “five-digit numbers,” and “sprawling oceans of zeros.” It’s important for social game companies to understand the reality behind where the money comes from and why. It is also critical to understand why some players actually pay to play, and why some just pick the game up once or twice to get their feet wet. For instance, take this image from a great VentureBeat piece on whales in social games:

While whales make up only 4% of the spending user, they make up for 60% of the revenue! The minnows, the 79% of spending users, actually only make up 8% of the revenue. Why is this extreme so prevalent amongst social games right now? If only 4% of social gamers are becoming invested enough in social games to regularly pay for the experience, than what can be done better as social game designers to ensure that more of the minnows are willing to invest on the experience? Perhaps we should stop banking on that extreme 4%, stop trying to come up with some miracle data that claims we’re actually appealing to all gamers, and instead make more interesting games that can allow a larger percent of the players to become more immersed in the system for longer durations. Would we rather have 3% of a million users fully invested in our games, or 20% of 200,000?

It’s shocking at first to hear that a goal social game companies aim to get only 3% of their playerbase spending. Regardless, this notion of a tiny percent should serve as a massive red flag to social games developers.  It’s as Tim Rogers says: “[Players] are coming for the cute characters, and staying for the cruel mathematics.” Well maybe cruel math is good enough to get us 3% of players spending a decent chunk of change, but why should social game developers be satisfied with that? What if instead of cruel math, we had compelling, beautiful systems? We’d probably get a lot higher percentage of players paying a more reasonable amount, and we’d all be better off for it.

Well, how do we do this? Tim Rogers himself recently penned a piece for Kotaku setting up some simple mechanical steps in the right direction. However, I’m going to take a step back, and look at a piece I personally find more relevant: Richard Bartle’s “Hearts, Clubs, Diamonds, Spades: Players Who Suit MUDS,” which examines the four archetypes of players he observed in the Multi-User Dungeons of yore and how to balance a game to suit the needs of each. The RockYou survey also tried to split social gamers into four archetypes, with some of the characteristics seeming to descend directly from Bartle. Furthermore, MUD grinding and socializing are in many ways the philosophical ancestors to the social game mechanics of today, so it feels all the more relevant to look back to that genre.

In Bartle’s classification there are Achievers, who he describes as players who “give themselves game related goals and vigorously set out to achieve them.” There are Explorers, who try to find out as much as they can about the world and its systems. There are Socializers, who make the most of communicating in the game and see it as a context for social interaction. Finally, there are the Killers, who prefer to impose directly upon other players. Whether hurting or helping (mostly hurting in modern gaming history), its multiplayer game action that drives the Killer. In many ways, we can say that the current experiences in Facebook games are balanced towards Achievers and Socializers, with tendencies towards interacting with players and acting upon the world. A few years ago, with Mafia Wars being amongst the top games on Facebook, Killers could be said to have held more of a presence, but it seems much less so today; a notion we’ll consider again later. Anyways, take a glance at this nifty abstract graph Bartle setup:

What social games need is for the scales to tilt a bit in favor of accomadating players acting upon other players (“killers”), and people acting with the world (“explorers”). Bartle suggests some ways to balance aMUD for specific scenarios and most of his general themes are highly relevant to social games. It’s sort of tricky to tilt the graph to the upper-left and bottom-right simultaneously, so for now let’s approach these adjustments one at a time.

For titling to the upper-left I’ve selected some relevant suggestions from Bartle:
• Add more player-on-player commands
• Make communication facilities easy and intuitive
• Increase the connectivity between rooms
• Add more communication facilities
• Raise the rewards for achievement
• Have an extensive level/class system
• Make commands be applicable wherever they might reasonably have meaning
• Have large puzzles, that take over an hour to complete
• Have many commands relating to fights

For tilting towards the bottom-right, I’ve created this subset:
• Make building facilities easy and intuitive
• Maximise the size of the world (ie. add breadth)
• Produce cryptic hints when players appear stuck
• Maximise the effects of commands (ie. add depth)
• Produce amusing responses for amusing commands
• Have lots of small puzzles that can be solved easily
• Allow builders to add completely new commands — [ an aside from me: USER GENERATED CONTENT !!!]

Now some of these, in Bartle’s initial piece, were suggested as opposites, but out of the ones I’ve selected to display here, none are mutually exclusive and should be exempt from the contemplation of the social game designer. Themes clearly arise: allow for more meaningful social interaction (as Rogers points out, right now Skype is a much more meaningful more social experience than Sims Social). LittleBig Planet uses real-time multiplayer, puzzles that require teamwork, and user-generated content to create a brilliant, meaningful, social community around a game that is incredibly simple and casual at heart. Add more depth and breathing room to the systems of a game, while at the same time keeping the commands intuitive and easy to learn. Inputs should be simple and have somewhat predictable initial responses, but the system should be complex enough to allow the players to learn and discover new things as they go. Triple Town, a game on Kindle (and now Facebook too) does a brilliant job with this. There needs to be a balance of smaller goals with larger ones. Nathan Drake, of the Uncharted series, can see the temple with the stolen idol in it miles away, but first he needs to kill the badguy with a gun two feet in front of him. There’s no reason for social games not to employ that same dichotomy of tasks.

Focusing the balance more towards Killers may be the trickiest of all the changes I’m recommending. Bartle often discussed how they were a group that never gained much popularity and tended to isolate themselves. Non-killer players simply did not want to play with them, and in many ways the same is true today. There were a plethora of examples from players in Empires & Allies who wanted the player vs. player mechanics removed. Segregating servers for killers to play on their own (much like how World of Warcraft has with PVP or PVE servers) is a possible solution, but there ought to be a more subtle and effective one out there. We need to rethink how we harness the killing mechanics in this space. Empires & Allies had a very nifty solution to this, which was the ability for a player to pay some in game currency or use some item to enter a temporary neutral state where they could not be attacked. Then if they forgot to renew their neutrality, they might be punished in the same way they might be punished if they let their crops wither in Farmville. To me personally, this seemed like a step in the right direction.

The most important theme to derive from all of these suggestions, however, is that social games need to allow for meaningful decisions to be made.

As a designer at Guerillapps, currently working on Trash Tycoon, I’m not going to claim this game has all the answers, but I do believe we are taking worthwhile steps forwards, and keeping all of this in mind as we progress. In Trash Tycoon you can decide to sell, store or upcycle various objects. You can sell trash to a landfill, or invest in more dumpsters to store it for future recycling. These choices are inherently interesting and meaningful. The players are not hand-held through any of them, but are given enough information to make an educated, or at the least an experimental, decision. We’ve employed real-time, synchronous multiplayer with in-game chat. We have short term goals that take five minutes, and ones that you’ll have at the same time that might take a day or two. We’re building up our achievement and end-game systems constantly, working to make them meaningful and interesting. We’re working on minigames that will provide an outlet for a more micro-level of strategy and fun within the context of our overall structure. All the while, we’re keeping a close eye on our own insights and metrics to see who we have playing, and not only what we can do to make them happier, but what we can do to attract other types of players as well.

Sources:
Bartle
Tim Rogers on Insert Credit
RockYou survey 
Venturebeat