RIP Mochi

I don't know if you heard, but Mochi Media is shutting down. I guess no one at Mochi wanted this to happen, but they were bought by a big company and now that big company wants to shut them down.

Specifically, that big company is shutting them down, and along with them, all the hosted games, all the preloader ads, all the high scores, and all the live updates that Mochi had been providing as a service. All gone.

I've been using Mochi for all my published Flash games. Fortunately, I'm not depending on MochiAds as an income source (I made very little money off of that) but I have been using MochiScores for the leaderboards in Flydrill and Space Lord.

Soon they'll be all gone. Flydrill will no longer hint at a more glorious past when it got more than a few plays a week, and more tragically, the Space Lord Hall of Fame, nexus of player-created shmup levels playable in Space Hero, will cease to exist. Now that is a shame.

You can still share levels in Space Lord, actually, if you click the button to share on Twitter after you beat the game. I don't think I've ever seen anyone do that though. :p

So what does this mean? End times for the Flash game renaissance. Here's to the end of an era.

What's next? I don't know, but it seems that every single game developer I know has been switching to Unity. It's living up to its name.

I might even have to make the switch soon.

:(

So now that I can't take advantage of free Mochi hosting, I've finally gotten around to putting Flydrill on deviantART. Now my dA portfolio actually reflects the games I've made. More or less.


Anyway, check it out. Maybe you can leave the first comment. ;)

Space Lord rising

I made a game.

It's called Space Lord. I've been working on it since March, on and off, and now it's finally out. Originally it was a game jam game I made last December for Ludum Dare 25, with Pat Kemp (knivel) and Teo Acosta, the same guys who made The Love Letter with me, plus another artist friend Jim Burner.

The theme was YOU ARE THE VILLAIN and once again, knivel came up with a great little concept that eventually turned into the final Space Lord that we all know and love.

Or something like that.

Space Lord

Play it! Don't give up right away, there's a bit of a twist. ;)

At the beginning of this year I decided to go for the #OneGameAMonth challenge. I was doing fine for the first few months, but it all broke down with Space Lord. After all the success of The Love Letter, I wanted to take all my other old game jam games and polish them up too. So I thought I'd start with Space Lord, since it seemed to be the most promising, and the closest to being really finished. Sure, it was. But it took me way more than a month to finish it, and I fought until the very end to keep to my one-game-a-month commitment, but ultimately, I failed. And it was very painful to finally reach that point.

For the first month or two, I was really getting into it, working on Space Lord whenever I could, staying up too late and getting sleep-deprived in return. I got pretty burned out after a month or two of that, and just wanted the project to be over. But I refused to give it up, or to release a game that I know I could improve upon, so I kept going. But I worked on it much more sporadically after that point. I went for long periods of time without working on any creative projects, and started feeling listless and stagnant, which made it even harder to get back into it. But whenever I did, I felt better. Making stuff makes me happy. That's just the way it works for me.

So, eventually, four months after I started, I finished. More than anything, this was a design challenge for me. I've gotten to the point where I can code these little Flixel games without too much trouble, but game design is still really hard. By that I mean the process of taking an interesting concept with a lot of rough edges and turning it into something actually fun and accessible to a decent number of people. It's even harder when you're the one coding everything, because you feel the pain of every potential design change that has you undoing a bunch of your hard work or creating a bunch more for yourself.

For Space Lord, one example was going from real-time to turn-based gameplay. I knew the game went way too fast for anyone to tell what was going on, but it still took a fair amount of willpower to actually choose to invest the effort into making it turn-based. This is another reason why it really helps to have good collaborators to work with - knivel didn't end up joining forces for the Space Lord redesign, but he was there to bounce ideas off of and help strengthen my resolve to do what I knew was right.

So, the game is on Kongregate. That was really disappointing, actually - it got only a couple hundred plays, a few comments, and a rating less than any of my other games on the site, even the really old ones. Then it sank without a trace. Ouch.

Then I put it on Newgrounds, without much optimism. It was received a bit better there, as is typical in comparing the two portals. But no momentum. I was prepared to give up on the portals and see if I could get some people to blog and tweet about it, as I think the game is quite interesting to write about, even if the players haven't been particularly excited. :p

But then it was featured on the front page of Newgrounds! And suddenly there are dozens of comments, and thousands of views. Yay? :) It's interesting what people are suggesting in the comments - there are actually people who want the game to be longer, and just want more - more space, more ships, powerups to place. Definitely a fair number of complaints about the AI. Yeah, I know, it's really simple. :p And some people who perhaps don't get it at all.

In case you're wondering, Space Lord is a level design puzzle game. Possibly the only one of its kind I've seen so far. You are the game designer. The AI player gives you a fun rating and trashes your game when it's not fun enough. It doesn't really hold your hand or structure your experience because I wanted it to feel more like the experience of actually designing a game. :p

And if you "beat" the game (if the "player" beats the game) then you can submit your design to the Hall of Fame, where other people can play it, as the player ship. More on that later. ;) But in any case, it's been fun seeing the designs that people come up with.

I might even say it's been worth it.

Of course it's been worth it! :) This is what I'm doing, polishing up my old game jam games, working on my game design skill, trying to eventually get up to the point where I can make games for education and social change and actually succeed.

I've already started polishing up my next one. Hopefully it will go a little quicker this time. ;)

A Minor Flydrill Update

Not too long after my last Flydrill update, almost two years ago, I kept tweaking the game but never released anything after that.

Until now. :o

Don't get excited, it's just a tiny update. ;) I added white outlines to the enemies so you can see them better, with a slightly darker background color. I also made the giant wall thinner in the beginning. Honestly I was just tired of having to drill for ten full seconds every time I started the game. That's why I went ahead and released this update.

Flydrill

I guess it's spring cleaning time for me, polishing up and releasing old stuff I've had sitting around on my hard drive for the past year or two... :)

On that note, I noticed that Google Reader will be shutting down in a few months! :( As disappointing as that is, I think it's a good opportunity to revisit my content-consumption habits and perhaps let go of my daily blog reading. Looking through all my feed subscriptions, it strikes me how few blogs are still active - really there are less than a dozen that I see updates from regularly. And I've gotten to the point where none of the stuff I read is really that valuable to me - the game design articles are not blowing my mind with new insights, the productivity articles are teaching lessons that I've already learned, and really, I think I'd get a lot more out of spending that time working on actual projects or reading books or even... playing games. I mean, it's been years since I've really sat down and just played a game, for serious. I think the last one must have been Portal. Yeah. The truth is out! :o

Well, I hope you enjoy the Flydrill update! :) May there be plenty more to come, soon.

Oh, and I almost forgot - Happy Pi Day! :D

The Love Letter released!

I've been pretty quiet on the blog here lately.

But under the surface, my game development life has been roiling with barely constrained productivity and awesomeness! :D

In December, I participated in my first official game jam, the 72-hour jam for Ludum Dare 22. It was awesome. I teamed up with the artist, fledgling game designer, Flixel programmer, and all-around amazingly creative guy knivel, and I had the most intensely fun, productive weekend of programming and game development I'd had all year. No exaggeration.

The theme was ALONE, and after I suggested a game where you try to get away from all these people who keep bothering you, knivel basically came up with the entire concept of The Love Letter right then and there.

Oh, did I say "The Love Letter"? That's the game we made. Of course, we didn't have time to add a tutorial, or make it so you could actually win the game, but even then people seemed to like it, and told us to finish it, and voted us to first place in the "Theme" category of the game jam! Yay! :D

You can read more about our adventures here, in my Ludum Dare blog posts.

But anyway, that brings me to the point of this post, which is to kindly inform you that WE FINISHED THE LOVE LETTER AND IT'S VALENTINE'S DAY AND YOU SHOULD PLAY THE GAME NOW IT'S REALLY COOL!!!!!!!! :DDDD

The Love Letter

This project has marked a turning point for me in many ways. For one thing, the game has done much better in playtesting than any of my previous games. People like it, and it's easy to understand and get into. Kind of like Pillars in that way, except an actual game instead of just a little prototype. Of course, we still haven't had a full public release yet, but even so far it has had a very promising reception. (By the way, have you played it yet? You should.)

But more importantly, I discovered that I can enjoy being the programmer on a game, working with a designer, and that this can be just as much fun or even more so than simply trying to be the designer myself. What I realized is that when I fully trust the designer - knivel, in this case - to the extent that I feel like he would make the same design decisions that I would make except faster and better, and when we occasionally disagree it is an opportunity for us both to expand our own perspectives and make a better game together then we could on our own. It's hard to be the programmer and the designer at the same time. It takes time to mentally switch between roles. When I work alongside a designer whose creativity and design sense I really admire and trust, it frees me to focus on the groundwork of programming while he scopes out the game design possibility space from above.

It also really helps to work with an artist and designer who also knows programming and can hack in features without my help if necessary! :) Just like I can fix pixel art mistakes if I see them. After my experiences making games with knivel, I don't think I would choose to work with a code-illiterate designer unless I had a really good reason to. It's so nice to be able to explain to a designer what I'm doing, what problems I'm running into, or what awesome thing I just figured out, and have that designer actually understand me. It's all about that connection, like we are just parts of one unit, the team. Without that common understanding, it's easy for friction to come up in our interactions.

So there, I'm getting more picky. ;) But in a good way. :) I'm learning what works for me.

The Love Letter was also the first project where I got really into working on it, fitting it into every crack in my schedule I could find after the game jam ended and we started fixing up the game for the release I now have the pleasure of announcing. I'd bring my laptop on the bus and work on it there. I'd work on it while eating dinner. I'd keep working on it and stay up late. I was so into it, I didn't want to stop. And I couldn't wait to get back to it. :)

Finally! :p A year ago I remember being similarly obsessed with reading Harry Potter and the Methods of Rationality, and thinking to myself, "If I wanted to make games as much as I want to read the next chapter of Harry Potter and the Methods of Rationality, I'd be making a lot more games." And now I've gotten to that point. I know what it feels like. I can tap into this with my future projects too. Which is great to think about.

But I also need to get some sleep, if I want to stay motivated, not to mention... alive? So I think I'll wrap this up.

I also participated in the Global Game Jam for the first time this year, and made another little game with knivel and the same composer (and this time you can actually get to the end). It's not quite ready for prime time yet - we're planning to give it the same sort of treatment as The Love Letter, but I'll be sure to let you know when it's done. :) Now that we're finished (or are we?) with The Love Letter, I'll probably be getting back to this game pretty soon. After I get some sleep, of course. ;)

Oh, and also, I wrote about my first ever game jam, back in October, on the Fugazo blog. It was not nearly as successful as my latest adventures, but it was educational. Hehe. :)

Revising Flydrill

After a year and a half, I finally updated my game Flydrill. Yay.

You just added achievements!

Ever since releasing Flydrill in March of 2010, I've been dissatisfied with the game, and embarrassed to show it to people. It wasn't a bad game - in fact it has been my best so far, but there were just so many problems I saw in it, so many things I wanted to change.

In particular, I thought that they key ingredient the game lacked was logistical gameplay. Later on, I realized that this was just one of many shortcomings, and that the core of the game and the overall structure of it could stand to be improved as well.

So what I've done this past week is improve the core gameplay.

First of all, the arbitrary dream-logic rule that you could only drill to the right is gone, and now you can drill in all four directions. This opens up a lot more possibilities for burrowing and evading through tiles, slipping out of danger through narrow gaps which you can widen into caverns as in the screen shot above. It's also a lot less confusing for new players. Why can I sometimes drill and sometimes not? That question doesn't come up anymore.

Next, I got rid of the extra lives. Now it's one hit and you're dead. Why so cruel, you ask? One answer is that this is inherently a very hardcore game, requiring the coordinated use of many skills and actions, under significant time pressure. I'd originally tried to make it more casual, and weakened the game as a result. Now, I embrace its hardcore nature. Having a single life sharpens the focus of the entire experience. You stop paying attention and you die.

Getting rid of the extra lives also means that you can no longer feel the despair of being down to your last life, with no hope of recovery. The complacency associated with having two extra lives safely tucked into your back pocket is no longer an option. No false sense of security.

And it's much less confusing. Before, I noticed that many people would lose a life and not realize it, never learning the lesson that running into a swarmer is hazardous to your health. Now, there's no question. When you touch a swarmer, you know something bad happened. And because you've learned something, you decide to try again, armed with your new knowledge. Clarity is more important than coddling.

Finally, having a single life makes it much easier for me to balance the game. I've increased the frequency of invincibility halos and decreased the frequency of portals, so that the experience alternates between frantically dashing through clouds of enemies long enough to find a halo and racing to get the most out of your halo while it lasts, maybe taking out an enemy or two just because you can. Halos are not rare experiences anymore. This alternating rhythm is now the core of the game. If you had more than one life, it wouldn't work as well because the game would drag on and on, and the extreme focus of the halo-less portions would be dulled by a false sense of security.

Along those lines, I've also greatly improved the pacing of the game. In Flydrill's very first release, the game started out very slow, and to many players, boring. In response, I crudely ramped up the pace, throwing everything at the player right away. This was not optimal. But I figured that overwhelming the player was at least better than boring them. Now, however, I think I've succeeded in making the game interesting from the very beginning, while also gradually introducing new enemies to the experience to keep it feeling fresh.

The first thing I did was increase the speed of the swarmers. Back when the game gave you multiple lives, the swarmers would start out really slow, and very gradually get faster as you progressed, slowing down whenever you lost a life. Like Pac-Man CE. However, with three lives, this meant that the swarmers started out so slow as to be totally harmless, and eventually got ridiculously fast, neither of which were fun situations.

So I made them speed up much more quickly. To compensate, I made them slow down every time a swarmer dies, whether by colliding with another enemy or with your halo of death. This creates a nice feedback loop - the swarmers get fast, but once they reach the point where they're so fast that they're running into each other, they slow down. And it means that if you can dodge the swarmers long enough, they'll slow down so you can escape safely. But as soon as you travel out of range, they'll have gotten fast enough to catch up with you again and the cycle repeats. This alternating cycle nests nicely with the larger cycle of halo having and not-having, and makes the core gameplay much more enjoyable.

The next pacing improvement I made was to space out the introduction of enemies. Now that the game was interesting just with swarmers, I could wait to introduce the other enemies, without fear of boring the player in the beginning of the game. Puffers come in shortly after swarmers, teaching you to watch where you're going as you dash madly away from danger, and then later the gunners, teaching you to use walls for cover instead of hanging around in the open, and then finally the diggers, teaching you that sometimes a cozy little burrow can be the worst possible place to hide.

Lastly, I made big solid walls appear every so often, to provide some milestones in your rightward journey, and throw in some opportunities for serious drilling. At first I'd assumed that these walls would be very dangerous places, where you are stuck frantically drilling as your enemies nip at your heels, so to speak. But as it turned out, with the four-way drilling now available, these walls became safe havens that I'd look forward to - places where I could burrow safely, feeling through the gaps in the tiles that my enemies could not fit into, where I could be pretty sure to find a halo or two in the safety of the solid wall. Unless a digger stopped by for a visit. But that made it all the more exciting. :)

And the portals, those bubble things that change the background color and clear all enemies from the screen, now have a more pronounced effect on what type of enemy you are likely to find. The colors have stronger associations - red for gunners, green for diggers, and blue for puffers - and the difficulty does not go down so much when you enter a portal. So it's not always something you want to go for, especially if you see a green portal in a nice, safe blue zone. You have to make a choice. And that makes it more interesting.

Also the portals now have big halos around them to make them easier to hit. New players often have trouble with the timing-sensitive flapping controls, and hitting a portal shouldn't be a challenge in itself. But the portals also don't appear as early to tempt these new players either, since the color changes and corresponding enemy distribution changes would totally throw off the gradual pacing I have set up.

The last change was to add a persistent high-score display, inspired by iPhone game Bit Pilot, to replace the now-useless extra lives in the upper-left corner. This game is entirely about pushing your score a bit further than last time, and I decided that I'd give this goal the attention it deserved by making your best score constantly visible as you play.

The other last change, the last last change, was to add achievement notifications.

"Achievements?" you gasp, "How crude!"

Yeah, that's what I thought at first too. But wait, there's more to this than you might at first think. I didn't go with the typical trophy-style achievements, where there is a list of things to achieve, and then you achieve them, and you are told that your achievements have been "unlocked" and now you can see them shining magnificently in your list. I mean, that would require a whole new interface to design and implement! No way!

Instead, I went with the second option.
From Chris Hecker's Achievements Considered Harmful?:

For interesting tasks,

1. Tangible, expected, contingent rewards reduce free-choice intrinsic motivation, and
2. Verbal, unexpected, informational feedback, increases free-choice and self-reported intrinsic motivation.

There's no list. When you do something cool, like travel 1000mm, or kill 10 enemies, or hold a halo for 20 seconds, the game tells you. When you do something even more cool, like travel 2000mm, or even 3000mm, or kill 20 enemies, or hold a halo for 40 seconds, the game tells you again. And that's it.

Short of adding coins everywhere, it's one of the few things I can do to make the player actually feel good about what they're doing in the game, instead of just making them frantic and terrified or temporarily relieved at having escaped with their single life for a few precious seconds of respite inside the safety of a wall.

The only shortcoming is that this feedback is not entirely unexpected, since the pattern is pretty easy to pick up on, and it tells you every time. I might experiment with the game only telling you the first time you do something, making its announcements much more rare and precious. But for now I think the system works pretty well.

And I didn't even have to design a new interface for it. That's the best part. ;)

The changes I'm considering next are more drastic, like adding baby fliers to guide for upgrade points and adding upgrades to spend those points on. Logistical gameplay. But I'm not sure how it will all turn out.

For the moment, I'm just glad that Flydrill is finally, at its core, a solid game. I'm not embarrassed to tell people about it anymore. :)

So try it out and tell me - what do you think?

Flydrill and Logistical Gameplay

Want to know why I haven't written a blog post in two months?

I've been making a game.

It's called Flydrill.

Explore an infinite dream world. Survive an endless nightmare. How far can you fly?

On the 23rd of October, in 2008, I had a dream where I was this little abstract flying thing like the flier from Flywrench. I was in a maze of square tiles, and I could drill to the right. Little swarming dots chased after me. When I woke up, I decided to turn it into a real game.

And so, more than a year later, I did - with a bit of help from some helpful people, an exceedingly helpful game engine, and some "inspiration" from Canabalt, Left 4 Dead, and Pac-Man Championship Edition. Though I've only ever played one of those games. I'll let you guess which one.

But I'm not here to go on and on about how I made this game. I've already done that, in this thread on the Flixel forums. And I'll probably be posting another blog post, soon, about how to get Flixel and Mochi Live Updates and the Newgrounds API all working nicely together. But this isn't it.

Every time I release a game, I discover new blind spots in my understanding of game design. This latest game is no exception. The feedback I've gotten on Newgrounds and Kongregate has led me to some interesting new hypotheses about the basic principles of Flash game design.

Here they are.

...but first, a screen shot!

I've become convinced that Logistical gameplay is the single most important factor in predicting a Flash game's eventual success or failure. Of secondary importance is the Tactical gameplay. Flydrill is the first game I've made where the Tactical gameplay is really solid - in fact, I think it's better than most Flash games in this regard - but it has no Logistical gameplay to speak of. And the player response shows it - great reviews, but a mediocre overall rating.

If my hypothesis is correct, then adding Logistical gameplay to Flydrill should make it a very successful game in terms of portal ratings and popularity.

So, what is "Logistical gameplay" anyway?

I first came across this term in the book 21st Century Game Design by Chris Bateman. Corresponding to the four personality types in the Keirsey Temperament Sorter, he identifies four categories of gameplay skills: Strategic, Diplomatic, Logistical, and Tactical. My own analysis is based on the research in the book. Read it if you want to learn more.

According to Wikipedia, "Logistics is the management of the flow of goods, information and other resources, including energy and people, between the point of origin and the point of consumption in order to meet the requirements of consumers."

What does this mean for games? When it comes to Flash games, at least, Logistical gameplay often means lots of upgrades and items and achievements to serve as the requirements for in-game resources, and various ways to convert player time and skill into these in-game resources, whether experience points or virtual cash.

But logistics isn't just about grinding for an achievement. All gameplay revolves around choices.

Logistical gameplay (read more) revolves around choosing how to allocate your resources - which upgrades to invest in, how much to spend, how much to save, and how to manage your time and effort effectively for the greatest payoff. The pleasure of Logistical gameplay is not in simply doing something, but in doing it well - optimizing it to perfection. This is why achievements are so important. They give the player a reason to excel, which creates Logistical gameplay.

There are many Flash games that focus on Logistical gameplay. But the best example that I've found is a little game called Toss the Turtle. Actually, it's not little at all, it's big - packed with items and upgrades to buy, achievements to earn, and tons of variables to tweak and improve on the way to the perfect turtle toss. You can see this formula repeated in many top-rated games, from Learn to Fly to Infectonator : World Dominator. Why? Logistics. Each of these games is heavily Logistical, with a bit of Tactics thrown in.

But what is Tactics?

Tactical gameplay (read more) is about the choices you make from moment to moment in the midst of action. This can be anything from dodging bullets to matching gems - in general, reading the situation of the moment and responding in the most appropriate way.

In Toss the Turtle, the Tactical gameplay consists of choosing when to shoot your turtle for extra height, and using the arrow keys to slightly adjust the turtle's trajectory. It's not much, but it gives players some non-Logistical skills to work on between trips to the upgrade shop.

But the purest example of Tactical gameplay that I've seen so far is the ingeniously simple Particles. All you do is avoid the bouncing balls for as long as you can - no upgrades, no story, no fancy graphics. But the gameplay it creates is very effective, and very Tactical - reading and responding to constantly shifting patterns of safety and danger.

There are other types of gameplay that tend to be less critical for success in the Flash game market - namely, Strategy and Diplomacy. But these can be very important for long-term success, because these are the deeper skills valued by hardcore players.

Strategic gameplay (read more) is about imagining solutions to complex problems, and this skill is most often catered to in Flash by puzzle games. Fantastic Contraption is the perfect example of this. Its commercial success may have something to do with the fact that it is based on Strategic rather than Logistical or Tactical gameplay - as I mentioned earlier, Strategic gameplay tends to be favored by more dedicated players, who are perhaps more willing to pay for the experience.

But also important to mention is that Fantastic Contraption also supports Logistical gameplay, because each puzzle is predefined, and the solution can be discovered by trial and error - in other words, Logistical optimization - if no ingenious Strategic insights come to mind. This means that all the players who prefer Logistical gameplay will still get some enjoyment of the game, rating it highly and sharing it with their friends, even if they don't like it enough to pay for it.

Diplomatic gameplay (read more) is about understanding and reconciling differences while preserving individuality, a skill that is rarely catered to by Flash games. We just don't know how to make Diplomatic games - not yet, at least. But there is one genre that begins to approach Diplomatic gameplay - in a very rough and rudimentary way, but still, it's Diplomatic more than anything else. Can you guess what it is?

No? I'm talking about spot-the-difference games. The gameplay in these games is not Strategic, Logistical, or Tactical. It's about finding the discrepancies between two different points of view, and resolving these differences. Diplomacy, abstracted. Difference games often support interesting artwork or involved storylines - see Dream or 4 Differences for example - which can provide players with a sort of imagined Diplomacy of conflicts to resolve and different characters to empathize with, even if it has nothing to do with the actual gameplay.

So that's some interesting background information. But why would I say that Logistical gameplay is the single most important factor in predicting a Flash game's eventual success or failure?

On page 91 of 21st Century Game Design, I came across a table citing this study on the distribution of the Myers-Briggs personality types across the general US population.

Here's what I found:

• 50% of the US population prefers Logistical skills (SJ)
• 25% of the US population prefers Tactical skills (SP)
• 15% of the US population prefers Diplomatic skills (NF)
• 10% of the US population prefers Strategic skills (NT)

No wonder Logistics is so essential!

If you make a game that focuses exclusively on Logistical and Tactical gameplay, you will automatically capture 75% of your potential market. If you focus exclusively on Tactical gameplay, as I did with Flydrill, you will capture only 25% of players. Oops.

Hmm, that explains a lot.

Tower defense games effectively combine Logistics and Tactics into a single package, which helps explain their popularity and continued success. Puzzle games combine Logistics and Strategy. And the only reason we don't see more Diplomatic games is that no one knows how to make them. Difference games are the closest we've come.

So there you have it. If you want to make a Flash game that appeals to the majority of players, you must be sure to include some excellent Logistical gameplay. How to do that, of course, is the subject for another blog post. ;)

Until next time...

awesome score yay! :D

Where to Start with AS3, FlashDevelop and Flixel

the free tools of the trade...

I've been working with Flash for a few years now. But I didn't switch over to programming with ActionScript 3.0 until earlier this summer. And I have to say, I've found AS3 to be so much easier to work with than AS2. I'm glad I switched.

Here's where to start if you want to make Flash games with AS3. If you do it this way, it's all free, and you don't need any prior experience with programming, or Flash.

If you forget everything else I'm about to tell you, just remember these two words:

1. FlashDevelop
   
   (it turns code into programs)
   
   
   

2. Flixel
   
   (it helps you make game code)
   
   

These two things, together, make up the path of least resistance for free Flash game development. You are not going to find an easier way to do it anywhere else. Believe me. I've tried.

So, where do you start?

Step 1: FlashDevelop

so shiny...

Start with the Making Games in ActionScript 3 using FlashDevelop tutorials! They'll tell you everything you need to download, how to install it and get it all set up, and walk you through all the basics of a typical Flash game.

Here they are:

• MGAS3FD 1: The Setup
• MGAS3FD 2: The Beginning
• MGAS3FD 3: Getting on with it
• MGAS3FD 4: More embedding
• MGAS3FD 5: Enter the frame
• MGAS3FD 6: Click it like it’s hot

They are very gentle, but I can imagine that someone who has never done any programming before may get confused somewhere along the way.

This tutorial will assume some basic familiarity with object oriented programming, a graphical tool of your choice and general computer literacy.

If you have any questions, you are welcome to post them here - I'll do my best to help. :)

But first, I'd recommend having a look through the Understanding Classes in AS3 tutorials!

If you’re stuck in an ActionScript 2 rut, or you’re new to ActionScript 3 and it’s blowing your mind, this should help ease you in a bit better.

Here they are:

• Understanding Classes in AS3 Part 1
• Understanding Classes in AS3 Part 2
• Understanding Classes in AS3 Part 3
• Understanding Classes in AS3 Part 4

If you already feel comfortable with classes and objects, you can skip these. They're optional. But they're worth reading if you haven't done much object-oriented programming before.

All right.

Have you gone through the Making Games in AS3 tutorials? Have you gotten FlashDevelop all set up, and maybe made a simple program or two?

If not, then go back and do it!

If yes, then you're ready to move on to the next step! :D

Step 2: Flixel

so pixelicious...

Don't bother making games from scratch. Make them with Flixel.

flixel is a completely free collection of ActionScript 3 files that helps organize, automate, and optimize Flash games; an object-oriented framework that lets anyone create original and complex games with thousands of objects on screen in just a few hours.

Oh yes.

It's the same game engine that was used to make Canabalt.

Start by downloading the latest version of Flixel, then follow these instructions to get a something showing up on the screen. If it works, download this example game and follow these quick instructions to run it:

• Running Mode in FlashDevelop

If you can get the example game to work, you can move on to these two step-by-step tutorials on how to build a game from scratch using Flixel:

• Making a simple brick breaker game with Flash and Flixel
• Making a platform game with Actionscript and Flixel

Then you can try this more in-depth tutorial on how to make a spaceship shooting game from scratch using Flixel:

• Flixel 2 Tutorial
• Flixel 2 Tutorial Extended
• Flixel 2 Tutorial Extended, Part 2

Follow along, and by the end of it you should have three little action games and the knowledge to start building your own games with Flixel!

To help you in your journey, there is the Flixel documentation, the Flixel wiki, and the help forum where you can ask questions and find answers. Also, the Flash Game Dojo. And of course, Google is always helpful.

If you get tired of using Flixel, for some strange reason, and you want to build your own game engine, you can give this tutorial a try. For experts only!

Update:
Flixel has changed a lot since I first wrote this post, so I recommend you check out this more recent guide on How to Learn Flixel if you're just getting started now.

Lastly, here are a few tools that may come in handy.

Unless you're making games for blind people (which is awesome) you'll probably need some way to make graphics and animations for your games. I'd highly recommend using the free image editor Paint.NET for this purpose. It's great for pixel art, and easy to use despite having a lot of nice features in it.

Similarly, you'll probably want to have sounds in your game. For general sound recording and editing, try the free sound editor Audacity. Again, it's easy to use and is capable enough for recording and modifying sounds. I use it mostly to clean up recordings or save sounds into different formats and file sizes.

If you're not interested in recording your own sound effects, you can generate them, with the amazing free tool called sfxr. Just click a button to get a randomized game sound, or change the settings manually to get the sound you want. It's perfect for games.

The creator of sfxr has also released a free tool for making game music, called musagi. I haven't tried it yet but I hear it's pretty good.

There are quite a lot of nice, free tools out there if you know where to look. Here's one list that you might find useful.

That's all I have for you! Now go make some awesome games with FlashDevelop and Flixel. And let me know how it goes. I'm here if you have any questions. :)

Good luck!

The Coming Revolution in Flash Games

This will be our manifesto. Daniel Cook of Lost Garden has just posted the first installment of his epic Flash Love Letter, an attempt to provide an answer for why Flash game development, despite its amazing potential, fails to produce awesome, world-changing games. And of course, a plan to get Flash games back on track.

"I think that you, Flash game developers, are some of the most talented and inspirational people working today in game development. Your passion for building games burns so incredibly brightly. Your ability to quickly make and distribute games is second to none. You hold immense potential to transform the future of games."

The first part is about making money with Flash games. A popular subject these days. When developers can't make a living making Flash games, there's going to be a lot fewer people making games, and a lot fewer good games out there. So, why don't Flash games make much money, and how can we change that?

"There is one obvious fact: the entire flash ecosystem is driven by low quality advertising. Piddling amounts of ad money flows into the developer's pocket through a variety of obfuscated middlemen."

Daniel Cook is definitely in favor of just asking players for money, instead of getting them to click on ads. It's easier than you'd think! And it pays a lot better than ads. You might even be able to make a living off of it.

"When game developers ask for money, they are usually pleasantly surprised. Their customers give them money; in some cases, substantial amounts."

"Many Flash developers insist on giving away everything for free. Stop devaluing your work and start creating a premium offer."

"We live in a capitalist society so people understand the concept of buying something. Don't ask for a donation. Don't ask players to 'give you what they feel like giving.' People will think you are a charity case and in my experience your revenues will drop by 90% or more. Give the offer a specific price, be it $10 or 200 gold in your favorite virtual currency."

So how do you actually get the money? On the subject of payment providers and portals, Daniel Cook has some advice, and some excellently developer-centric opinions...

"A payment provider should be a reliable commodity service, not a major business partner."

"The ideal payment service is one with low margins, low switching costs, no branding and APIs that let you cheaply and easily tie into generic, developer controlled login and storage services."

"The market is highly fragmented (30,000 portals!) and no portal owns more than 5% of the players. At this point in the market, developers have the ability to walk away from the greedy minority. Suggest reasonable terms where portal keep their existing ad revenue and you keep all in game revenue. If they balk, leave the bastards to rot."

Oh snap! Take that, portals! ;)

The most important takeaway from Part 1 is this:

"If you make a great game played for hours on end by millions of people, you deserve to be paid. Stop worrying about how people 'might' react. Ask a fair price for the value that you provide."

Can't wait for Part 2. :D

Ten Ways to Monetize Your Flash Game

I'd love to be able to make Flash games for a living. But the way things are right now, only the biggest success stories are able to sustain themselves on Flash alone. The rest of us must approach Flash game development as a hobby, on the side of school or work.

Part of the problem is that while Flash games are amazingly popular, there are very limited opportunities to actually make money from them. The vast majority of Flash games make money through ads or sponsorships or both. Originally, sponsorship was the main way for developers to make money, through sites such as Armor Games. Then in-game advertising became widespread, with the emergence of easy-to-use services like MochiAds. But so far, few games have succeeded in taking the next step - taking money from the actual players.

Lately I've been doing a lot of research into how games can make money, particularly Flash games. I've come across some very intriguing new monetization models, including some that have been successful in other games but have not yet been widely applied to Flash. I'd like to share what I've found, and hopefully inspire you to try some of these new strategies in your own games.

Before we get started though, this guy has one piece of advice for you: decide on your monetization model before you make the game! When you know how you're going to make money, you can design your game from the ground up to support your decision. It's a lot harder to tweak an existing game. Just think of monetization as just another component of your design, along with interface, progression, gameplay, graphics, and so on.

As this guy says, again,

"New monetization models open up new design possibilities."

You should be excited. This is exciting. New ways to make money equals new stuff to design.

Let's get started.

1. Advertising model

This is the most common way to monetize a Flash game. You can put ads in the loading screen of your game with services such as MochiAds or CPMStar, or just stick the game in a web page and put Google AdSense around it. You get money based on how many times these ads are viewed, so the more people playing your game, the better.

With ads embedded in the loading screen, you'll get money whenever your game is viewed, no matter what site it's on. If you have your own web page ads, these will only give you money when people play the game on your site, though they usually pay more per view.

2. Sponsorship model

Another common way to make money is to have your game sponsored. This means that a game portal, such as Kongregate, will pay you to put their logo in your game along with a link to their site. This helps bring more visitors to the portal site, which means that they get to make more money from their own web page ads.

Sponsorships are a good way to get a lot of money upfront, but you can only sell one sponsorship per game, and often your sponsor will not let you put your own ads in the game. This arrangement is called an "exclusive" sponsorship, because you can only have one sponsor. But other options are gaining in popularity, such as the primary sponsorship, where you still have one primary sponsor, but you are also allowed to sell restricted licenses to other websites.

3. Licensing model

This brings us to the next monetization model, licensing. Here, a game portal will pay you to make a special version of your game with their logo in it, and maybe connect up with their high score system. They will then host this special version on their site, but you are free to use a different version when putting your game on other websites. It's site-locked and non-exclusive. That means that you can sell separate licenses to a bunch of different websites, and make money from each one.

Individual licenses bring in less money than a typical sponsorship, but they are much more flexible, and they add up. You can combine them with advertising, with primary sponsorships, or both. You can also combine them with hosting a version on your own website.

4. Portal model

How can game portals afford to spend so much money sponsoring and licensing games? They must make even more money somehow, and that somehow is through web page ads. Some say that the best way to make money is to make your own website and host your game there. Lock the game to your site so no one else can steal it, and put some AdSense around it. Then spread the word about your game and hope it becomes popular.

If you don't have enough games of your own to keep people on your site, you can easily add other games with the MochiAds Publisher service. There are a number of tutorials out there explaining how to build your own portal. Here's one of them. This may help too. You can then sponsor your own games, by putting your logo in them with a link to your site. It may take more work, but the payoff can be greater than simply getting a sponsorship with an existing portal.

5. Premium model

Now here's where things get interesting. The methods we've discussed are all very indirect - your money comes from advertisers or portals. But now let's talk about taking money directly from your players.

The premium model means that you make a free game, and then you sell some extra, premium content to players who want more. This approach is slowly catching on, from an early, well-documented experiment with Drunken Masters, to the more recent success of Fantastic Contraption, making over a hundred thousand dollars in premium content sales. If you can make a game that's as good as Fantastic Contraption, and it makes sense to charge for extra features like a level editor, then selling premium content directly to players can be much more lucrative than advertising or licensing alone.

Just keep in mind that there is a very delicate balance between how much of the game you make available for free, and how much you reserve for paying players. If you are charging money for an experience that people could get for free somewhere else, then you will not be successful. But if the premium content doesn't feel valuable and 'premium' enough, few people will choose to buy it. This article suggests that you make the most popular parts free, so more people will try it out and like it, and only charge for specialized, niche content that very dedicated players will want. Advertising will pay for the free players.

And don't be afraid to charge a lot. Make the extra content worth it. Drunken Masters charged $1.50 for its premium content. Fantastic Contraption charged $10. Which do you think made more money? The hard part is getting players to pay at all. The difference between paying a dollar and paying ten is very little, once you've got your credit card out. Make your game worth ten, and ask for as much as you can.

6. Subscription model

So you've gotten your players to pay for premium content. But they're only paying you once. Wouldn't you rather have them pay you again and again and again? That's what subscriptions are all about - recurring revenue. Make premium content and special features only available to players who pay every month.

But hardly any Flash games are meant to be played for more than a month. If you want to get into subscriptions and really make some money, you need a different kind of Flash game, one that players can invest in, with their time and money, and feel like they are accomplishing something worthwhile. By far the easiest way to create this sort of feeling is to build a community around the game. Social bonds connect a game to reality, and can make a mediocre experience much more compelling.

This doesn't necessarily mean multiplayer, but if you want community, there has to be some way for players to interact with each other, whether that is by sharing custom-made levels or racing in real time. And there must be some form of persistent, saved data from the game that players can build up over time. Achievements and high scores are simple examples of this. But for the subscription model, you will need something more significant, such as a virtual world, customizable characters, or an in-game economy. You provide this larger context where the gameplay means something, and you charge money every month for players to get in.

But how much do you charge? If you set the price too high, some players might just give up and play something else. If you set the price too low, you could be leaving a lot of money on the table. But there's an alternative! Make the basic game free, the same way you would when selling premium content, and then have several "stackable" levels of subscription that players can buy. Maybe if players buy the first level subscription, they get access to some special clubhouse but they also get twice as many coins from playing the game as a free player would. Then players who pay twice as much and buy the second level of subscription get four times as many coins, and so on. Let players spend as much or as little as they want!

7. Micropayment model

This philosophy reaches its extreme in the micropayment or microtransaction model, where the game is largely free to play, but players can also spend real money in the game to buy special items. The way it usually works is that there are at least two different currencies in the game world: one earned by playing the game, and one that players get by putting in real money. Some items can be bought solely with currency earned in the game, and some can only be bought by spending real money currency.

You must be very careful when designing for this monetization model, or else free players will feel cheated when their skill and effort is thwarted by someone who simply paid to get ahead. For this reason, micropayment games often sell only decorative items for real money, and require players to earn the items that give them an advantage over other players. This works if there is a strong social component to the game. But in a cooperative game, players like it when someone else pays for a powerful item, because it will help them out too! Take a look at this article if you want a more detailed discussion of the design considerations involved.

If you're going to make a micropayment-based game you're going to need some sort of payment system, so players can spend money in the game. Fortunately, there are a number of payment providers all ready to be plugged into your virtual economy. Gambit is one example. But if you're looking for something even easier to integrate, a bunch of new virtual currencies have popped up for Flash recently. If you don't mind sharing your currency with other games, one of these might be the right choice for you.

8. Rental model

This model is crazy. It's a variation on the micropayment model, but adapted for a highly skill-based competitive style of game, such as the first-person shooter Combat Arms. In the rental model, you earn points and use them to buy items, but as the name implies, these items only last for a limited amount of time before they expire and you have to buy another one. Because players always return to the same baseline of power as their items expire, these rental items can provide significant gameplay enhancements without making the game feel too unfair.

You could allow players to pay real money for these items directly, but to make the game feel more fair you can instead let players spend real money on enhancements that help them earn points faster. That way everyone still has to play and earn their way through the game, but players who pay won't have to work quite as hard. And of course this can be combined with a more typical micropayment approach, selling purely cosmetic items for real money.

The advantage of the rental model is that players will keep buying the same items over and over again, so you can produce a smaller set of items than you would if players were buying a different item everyday like they might in a typical micropayment game. It also makes it feasible to charge lower prices for a given item, since each player will buy it more than once. Overall, the rental model may prove to be the most appropriate for a multiplayer game too small to justify a subscription or a huge number of items to sell.

9. Ransom model

If integrating a real money currency system and creating a bunch of items for your game seems like too much work, you could always just hold your game for ransom. In this model, you set the amount of money that you want to get from the game, and then you don't release your game until you've received that amount in donations. Once you release the game, though, it's free for everyone. And if you want to be nice, you could refund everyone for their donation if your ransom isn't met. This is called a threshold pledge.

The nice thing about this is that you don't really have to do any extra work. Just start making a free game and get donations for it. There's a nice little site called Kickstarter that takes care of all the details for you. Of course, you have to have enough of a reputation that you can get a bunch of people to pay you to release your game in the first place. It probably won't make you rich, but if you can attract enough support it could be perfect for small projects.

10. Patronage model

Last but not least, we have the patronage model. Like the ransom model, it is based on donations. But here, people are encouraged to donate larger amounts in exchange for exclusive and personalized recognition. A recent example of this is the donation system Daniel Benmergui set up with the release of his artistic game Today I Die. If you donate a certain amount, you get your name in the credits of his next game. If you donate one hundred dollars, you'll get a poster of one of his games with the characters replaced by whoever you want. And the first person to donate a thousand dollars gets to choose the characters and a new ending for a custom version of the game. Judging by the donation page, the game has brought in at least two thousand dollars in donations so far.

The key here is to make the people who donate, the patrons, feel special. People will pay more because they've gotten something unique and personalized. This approach requires that you give a lot of attention to your fans, and that you can attract enough of them, first of all. If you want to be an artist, and you are prepared to cultivate one thousand true fans, patronage may be the best option for you.

Want to learn more about making money from Flash games? Have a look at some of these other articles on the subject. Let me know if you have anything to add!

Update:
The ultimate treatise on Flash game monetization has arrived, in the form of Daniel Cook's Flash Love Letters! Make sure to read both Part 1 and Part 2. Oh, and don't miss the music video, either! ;)

If you like those, check out Cash Cow Part 1 and Part 2, an excellent set of articles on how you might put the Flash Love Letters into practice.

Forging a New Deal for Flash

I just wrote a comment on my blog that was longer than the original blog post! :p I thought it deserved a blog post of its own, so here it is.

I have been involved in a lot of discussion about Flash micropayment systems lately. It's exciting. A lot of things are happening at once, with the announcement of so many new payment systems for Flash games in such a short amount of time.

I was delighted to see that Daniel James, CEO of Three Rings, the creator of Puzzle Pirates and Whirled, somehow found my blog and took the time to respond to my latest post, in which I somewhat dogmatically urged developers to Demand More Money.

Comment by Daniel James:

"I feel that you're ignoring the considerable costs involved in operating a platform. If all you are doing is a payment system for credit card/paypal, then I agree entirely that a high revenue share to the developer is appropriate.

I'm not sure what Mochi is exactly offering, but stored value, brand and cross-game network adds a lot of value, and some costs. They are probably sharing some of their revenue back to portals, which I think is good news in general.

On Whirled we offer a lower-yet revenue share; a three way split between developer, affiliate (sometimes the developer, sometimes a player, sometimes a portal) and us... and we give 10% to charity! Maybe we'll have to change that in the price war you talk of, but in the end I don't think the revenue share percentage is the thing, it's getting players to pay.

That will require a complex platform that rewards everyone in the ecosystem -- which means money has to be split.

Bear in mind also that a lot of the payment methods most popular with the younger (e.g. Flash) audience take ~50% of the transaction (Mobile, pre-paid cards, etc.) So if you don't want to cut off these potential significant sources, you're going to have to drop the developer %."

Thanks, first of all, for the detailed reply! It's an honor.

I will admit that I'm not aware of the costs of operating a Flash micropayment system, but I'm assuming something fairly light, basically aggregating various payment providers such as PayPal or Super Rewards.

I have heard that mobile and prepaid cards do take a significant cut, as you mention. So maybe exceptions will have to be made for those, or they could be somehow subsidized by profits from the other providers or advertising. I wouldn't use those expensive methods as the baseline though.

I think it is inevitable that developer cuts will increase, and most likely stabilize to similar amounts across all the competing Flash virtual currencies. With ten different competing systems, I don't see how it could not. I can't imagine how all of these systems could coexist, in the long run, given the trend in the in-game advertising space with GameJacket dropping out recently, leaving MochiAds as by far the dominant player. Though perhaps it would be a good exercise in creativity to try to visualize such a situation. ;)

I don't see Whirled as on the same playing field as the others, really. You have your own little island, distinct from the general Flash games space. I wouldn't imagine that the revenue split would be the biggest item of consideration for developers on your platform. And who would be so heartless as to resent your 10% set aside for charity? :)

Kongregate's system might also be less affected, though I think Nonoba is spreading itself too thin between trying to reinforce its portal's brand and also become some sort of universal Flash currency. What I'm mainly talking about are the systems vying to be *the* universal Flash currency, like Andrograde, GamerSafe, Heyzap, and MochiCoins. The trend seems to be toward expansion and dominance. Because as you know, the more universal it is, the easier it is to get players to buy in and the more money you can make.

And this brings us to what I thought was your strongest point. Thank you for bringing it up. As you imply, the big issue now is not the percentage you get from the pie, but the size of that pie. Right now the pie is very small, and I would agree that there is more to be gained in growing that pie than there is in fighting over shares (like startup equity?). This will of course require cooperation from portals and developers, and plenty of resources for the payment providers, to make the whole deal enticing to players in the first place.

But I think we're already headed that way. The momentum is there. But I don't see enough momentum toward ensuring a good deal for developers. I see developers just jumping onto this new trend without in any way trying to steer it based on their own judgment.

Maybe it's just too early. Maybe once these systems are out and in use developers will start to respond, and critique. But I don't want to wait until it's too late. I want to at least start the discussion now, before the portals and providers set the tone of the conversation on their own terms.

We need developers talking about this. Not just providers telling everyone how great they are and portals complaining about their revenue share. We need developers complaining too. Because it is really the developers who will have the most influence in whether microtransactions succeed or fail in the Flash games space. Good games will carry a platform, just like in the console space. That is my opinion, at least.

And we also need players talking. I'm sure that they will complain mightily once this really gets going, but why not get them in the discussion now? The players will make this whole new movement possible.

The main objection I've heard is that players don't know what they want, if it's new, like this. They only know what they've already experienced. I suppose the same could be said of developers. Or even portals. In this sort of situation the best response is usually to prototype and test, build something to demonstrate and learn, to bootstrap some concrete understanding based on real products and real responses. How do we do that here?

Is it simply a matter of taking an experimental attitude to this whole deal for the first few months? Should payment providers pay some high-profile developers to experiment with their system and try to come up with something that works? How do we get the players involved in a way that will be constructive?

Any ideas? I'm very curious what you think. All of you. Let me know.

Developers, Demand More Money!

It seems that everyone and their mother is releasing a Flash virtual currency these days, from Nonoba's early entry into the arena, Kongregate's Kreds, and Andrograde's simple system, to the new and still-in-beta GamerSafe and MochiCoins. And let's not forget Whirled, OpenBAR, or CarrotPay. And oh, looks like another one just popped up today, Heyzap.

I've been finding it interesting to watch the discussions that have unfolded around the initial introduction of these systems. Developer reactions are suprisingly positive, despite the poor revenue splits that have been quoted so far. Reading the latest thread on MochiCoins, I ended up writing a response urging developers to demand more from these payment systems, which I've copied below.

Post by simianlogic:

"This all seems like much ado about nothing--Mochi has consistently done what's best for the developers. The ad-based rev share for publishers comes out of Mochi's 50%--nevermind that 50% for us is a great rev share to begin with."

I think this is a dangerous assumption. A 50% split may be fine for ads, but when it comes to players directly paying developers I think that a payment provider taking anything close to 50% is ridiculous. Remember Dan Hoelck's article on MochiLand about his experiences selling premium content with Drunken Masters? He described the difficulties with PayPal's taking a 24% cut of all his transactions. If 24% was too high, how would you describe a 50% cut?

If Mochi does not seriously increase the fraction of revenue flowing to developers using this system, then MochiCoins will never be a serious way to monetize Flash games. Right now it is commonly acknowledged that developing Flash games is not a feasible way to make a living. Sponsorships and MochiAds make it easy to make a little extra spending money on the side of a real job, but only the most successful and prolific developers could ever hope to make a living on such revenue alone.

The promise of micropayments is that selling directly to players could make Flash games profitable enough to live on. But if Mochi continues on the precedent it has set with MochiAds, it will do nothing to further this dream.

Given that the FGL team has recently announced its competing GamerSafe system, and accounting for earlier efforts by Nonoba and Kongregate, I can only hope that a price war will cause these Flash payment systems to undercut each other to a level that can support truly self-sustaining Flash game development. But if you are serious about putting microtransactions in your game, take a look at Gambit or Super Rewards, and drop one middleman from the loop.

Mochi is great, I like what they've done, I'm wearing a Mochi t-shirt right now, in fact, but that is no reason to cut them any slack when it comes to setting expectations for as big of a new wave as MochiCoins is sure to be. ;)

As developers, we've got to know what's a good deal and what's not, and be ready to ask for what we're worth, not simply take what we're given, however shiny it may be. You want this dream? Then start making it happen now.