Tom from Creamysoft

Credit Card "Security"

2010-05-28T17:58:00.001-04:00

I've run into a bit of a problem with Amazon.com, and I thought I'd share what has happened in case someone can help me understand it better.

About a month ago, I placed an order with them. That's nothing new. I've been an Amazon.com customer for more than 10 years. About a week later, my stuff arrived, and everything was peachy...or so I thought.

Last Sunday, I got an email from them saying that another customer complained that the charges for my order ended up on their credit card. By the time I got that email, I had 3 other ones saying that my order had been refunded (my order ended up in 3 shipments, each charged separately). Those refund emails included the last 4 digits of the card I used to pay, which were wrong. Instead of AABC, I typed CCAB.

But being a responsible credit-card-accepting vendor, Amazon.com requires more than just a card number. They also require a billing address and the 3-digit security code on the back of the card. I entered my address and the 3-digit code from my card when I placed the order. Since I messed up the card number, the billing address and security code did not match the card number I entered, but the charge went through anyway! The card number happened to match someone else's card and whatever computer system verified the payment information didn't check the address or security code.

The email I first got from them said that they could charge a card stored in my account already and that I could authorize payment if I told them the last 4 digits of one of them. I'm not sure what cards I still have stored in my account, so I thought I'd log in to see, but my account has been disabled, so I can't check. I emailed them back saying they could charge my card AABC if it's in there, but if not, they could call me, and I gave them my phone number. I also asked how this could have happened.

I got an email back a couple days later blaming Visa for the mistake. They said that they just pass all the card info the customer enters to Visa, and Visa accepts or rejects the charge.

They also told me to call customer support and tell them I need to pay for this order over the phone. I called support, gave them the order number, and told them I need to pay for it, but the guy told me he can't access my order because my account is locked. He told me to wait 24-48 hours and try logging in again to change the payment for that order. Based on previous experience with entering incorrect payment info on an Amazon order [1], I didn't think I could change the payment info on a completed order in their web interface, and I suspected he didn't understand that the order was already completed. I told him that, but he just repeated what he told me, so I told him I'd try it. It's been 48 hours now, and my account is still locked.

Getting the run-around with support techs who don't know what's going on and don't seem to communicate with each other is frustrating, but nothing new.

What's new for me is that I bought almost $300 of stuff from Amazon.com using another person's credit card. I would have thought that in 2010, using a stranger's credit card would have been a lot harder than that.

--------------------------------------------

[1] If you buy mp3's from Amazon, you authorize payment and then can download the songs immediately. However, Amazon waits to charge your card, probably to let you buy multiple songs and group them all into one transaction. So if you accidentally use an expired debit card to authorize the payment, you get an email an hour or so later saying that your card was rejected, long after you've already downloaded the songs. Because the order was completed with items delivered, you can't change the payment info for the order. I emailed support about that, and they had no way for me to pay for it over the phone either. I had to go find all the songs and buy them all again with a new card.

Sad Games

2010-02-10T17:20:00.001-05:00

Every once in a while, I download several game demos or take advantage of a Steam weekend sale, and try a bunch of games. This gives me a chance to keep up on what others are doing and learn from their example, both things I should and shouldn't do. There probably isn't any game developer that would say that good game design is not important, but actions speak louder than words, and many of the games I play have some glaring design problems.

Of course, much of the field of game design is simply opinion, so just because I think a game has a "glaring design problem" doesn't mean it really has a problem or that it won't sell. Even if I'm pickier than the average potential customer, there are players out there like me, and incorporating the following guidelines would probably help.

1. Only make interactive those parts of the story that should be interactive.

Use short cut scenes for the rest. Cut scenes do serve an important purpose. They define the setting, flesh out characters, explain story elements that would be difficult to convey with gameplay, they provide rest after intense play sequences, etc. Those are good things, as long as they're kept short, because the player isn't playing a game to watch cut scenes.

That said, it is possible to go too far the other direction: making some parts of the game interactive when they shouldn't be. The original Assassin's Creed is the best example of this flaw I can think of. In between sessions on the table, you actually have to control your character to get off the table, walk into his bedroom, and press the "use" key on his bed. The game seriously won't continue until you do that. If you take too long, say, because you think there's a reason you're actually controlling the character, so you start to explore the lab, the man just keeps saying stuff like, "Go to your room to rest."

After going to bed, the screen turns black, and then you're waking up. Your guy stands up by the bed and then waits for you to take over. The guy in the lab starts telling you to get on the table. Yep, that's right. You have to walk all the way in there and press the "use" key to get on the table.

There is one part I remember where you can talk to the guy's female assistant and get some info, but all that boring walking for that little story element? Not worth it. The player should only be doing interesting things. Less interesting things should not even be in the game, but if they really are necessary for some reason, they should only be briefly covered in a cut scene.

This is the reason I never even tried WoW. Whenever I saw my brothers playing, they were doing one of two things: running or waiting. They were running from one part of the world to the next, just running, running, running, and more running. I was playing a different game on my computer, and whenever I looked at my brother's screen, he was still running. If they weren't running, then they were waiting for people to join their group for a raid. That was years ago, and I know the game has changed a lot, but for me, grinding in general is a problem. More on this below.

2. The coolest and/or most critical parts of the game should not be in the cut scenes.

I first learned this design principle from Warcraft III. There's a character who turns evil and becomes a Death Knight or something. At one point in the cut scene, he charges out through a crowd of soldiers, and he 1-hit kills a bunch of guys in his way—BAM, BAM, BAM, they fall with every stroke of his arm, and he road away untouched. It was awesome. I haven't touched the game in several years, and that's all I remember about the cut scenes. Then in the game, you have him as your Death Knight hero. Can you do that with him? Nope. He stands there and hacks at the same enemy soldier over and over again like an impotent 2 year-old. Disappointing. But it sure was an awesome cut scene!

Assassin's Creed made this error too. I played about three missions into the game, and each one went as follows. You work your way through town, and you finally get to the target's lair. The only way in is through the front door (when do assassins use the front door?). As soon as you enter the doorway, you're ripped out the game experience and thrown into a cut scene. You proceed to watch your guy call out his target (when do assassins do that?), talk smack, the target tries to recruit you to his team, and then talks smack back when you refuse. And then after stirring up a beehive of angry bees and plopping you in the middle of it, the game gives you control of your guy again. Every time that happened, I could hear the designers laughing at the ridiculous situation they got me into during that cut scene. If I could have controlled my guy, I certainly would have done things differently.[1]

Let the player do the cool stuff and make the critical decisions.

3. Read Raph Koster's Theory of Fun, and apply it.

In that book, I think Raph hits the nail on the head. Games are fun because they tap into our natural desire to learn and master new skills. Games can tap into other natural desires, like curiosity, when we play to find out what happens in the story, find out what gadget X does, or to find out what's on the other side of that mountain. Movies and books also tap into that curiosity, but only games can do the former.[2]

My #1 reason for uninstalling a game I didn't finish (which is most of them) is that I just get bored. I've never been hooked by a game's story, and I'm rarely intrigued enough by the gadgets and abilities to play just to find out what they do (not because I'm smarter or more refined and crap—it's just me, my preference). The main reason I play is to do something new. Games which aren't continually requiring the player to improve their skills, learn new skills, and apply their skills in new ways miss out on this most compelling reason to play a game at all. Again, there are other reasons players might play a game, but the skill angle is unique to games.

There are many popular games that have this problem. Those other reasons players play games might still be sufficient for them to have fun, finish the game, and recommend it to their friends. But I submit that those players would have loved the game even more if it kept up the skill learning.

Requiring the player to continually learn and improve his skills doesn't mean the game needs to be really hard. It just means that the gameplay needs to keep evolving. Games are hard when the incremental steps that are required of the player are far apart. Games are boring when those steps disappear or even almost disappear.

FPS games frequently have this problem. You encounter harder, stronger enemies, and you get bigger, stronger guns to kill them with, but the core gameplay of "run, aim, fire, and keep firing until everyone's dead" stays the same. Usually a shooter will incorporate some new mechanics which set it apart from other games in the genre, but then the game still needs to evolve and stay fresh throughout. Usually, if the new features of the game are compelling enough, I'll play for an hour or so, but by then I've gotten a handle on them, and nothing new happens, so I'm done. Or I'll play for an hour and never get past the same old stuff and conclude the new stuff isn't worth my time to even try.

The FPS genre is one of my favorites to play, but I have only finished 2 FPS single player games: Far Cry (the original) and The Chronicles of Riddick: Assault on Dark Athena. I finished the former because the game kept giving me new situations to solve and requiring me to push my skills to new levels. I played Dark Athena a few weeks ago, and while I had other issues with it (the melee combat and ridiculously gross dialogue by Jaylor, to name two), it let me do some awesome stuff, like drive a mech and control the drones (the Alpha Drone was particularly cool). Even while not controlling those things, the weapons had different uses and required different play-styles, and that kept the game fresh (I'm a sci-fi fan too, and that never hurts).

The defining core mechanics of other mainstream genres, e.g. RTS and RPG, are also done to death, and I don't play through those single-player games either.[3] In the case of the latter, grinding isn't fun because it's the same thing over and over again. I've never played an RPG that didn't include grinding as part of the game. It might be part of the genre's definition though—the slot machine effect: you're dumping minute after minute of your life into the game, hoping the next monster will drop something good. I have no use for that as a player, and I wouldn't enjoy making a game like that either.

It's hard to make a game that continually stays fresh. I don't know if we've succeeded at it, because by the time I was done with Now Boarding, I couldn't bear loading another airplane. I can't objectively judge the final product. As employees take over the mundane tasks of grouping passengers and loading, docking, and undocking airplanes, the gameplay does evolve. The different maps offer different routing problems to solve. But it's only $15, so it doesn't need to last for weeks before players grok it.[4]

An RPG that is a long quest would be a ton of work to make it feel epic and stay interesting from a skill perspective. Maybe development costs would be prohibitive, but anything developers can do to require new and different skills whenever they can would improve the game.

4. Give the player clear short-term goals.

Clear means that the player understands what he is supposed to do and can reasonably figure out how to do it from what he's learned about the game world to that point.

Short-term means that the goal won't take too many steps to accomplish. Finishing missions is a natural hook for players, so let them do it—and keep doing it. Don't go too far and make the goals too short and small (unless you're developing a game like Achievement Unlocked). I like to finish what I'm doing before I quit playing, and I don't want to be locked in for hours. It's nice when the game can be enjoyed in small bites. I can always eat more bites in one sitting if I want to.

Not knowing what to do or how to do it is probably my #2 reason for uninstalling games. Most games are pretty good about this, but occasionally I run into a situation where I'm stuck. I go over past dialogue (if it's available), I retrace my steps and look for things I missed, but once I exhaust my resources in the game and/or my patience, I'm done. Alt-F4. And if Alt-F4 doesn't instantly close the game, then I instantly uninstall it when I finally get out. If Alt-F4 works and the game was otherwise compelling, I might google for a walk-through or something.

The most extreme example of not giving the player enough information is Silent Hunter 3. It's so bad I had to find walkthroughs just to explain the main menu. The reason is it's hardly even a game, but rather just a simulation tool. Usually a single player game has some kind of guided experience, i.e. you click on "Play" or "Career" or "Campaign" or something like that, and then you play through the game, and it gets increasingly difficult. In SH3, the "Career" option doesn't let you play anything (I never learned what it was for. I created a new profile with my name, but I couldn't select it or anything). The single player game is actually just a list of scenarios, each with several load-out options. All are available from the start, so there's no way to be sure you're playing the "right one" when you first play. After reading through a walkthrough to find out how the missions work, I played through the missions, which were quite fun (well, excpept the Gibraltar mission which was ridiculously long and tedious...I don't think I have the patience to be a real U-boat captain).

Aquaria also lost me for this reason. Where do I go? What do I do? How do I unlock that door? I have no idea. It's a beautiful game visually, but I hardly got to see any of it. Other artsy games like The Path and Blueberry Garden don't give the player clear goals either (well, The Path seemed to: "Stay on the path." I did, and it was short and boring, and I got 0's for all my scores. It lied to me. :) ). It's great that other people like those kinds of games. I just can't get into them. Exploration and experimentation are not reasons I play video games. I do a lot of that in the real world. But again, that's just me. If you make a game that encourages and rewards exploration and experimentation, why not add some goals in there too? You don't need to give the goals time pressure or anything that would hamper the explorer's experience, but then people like me would like your game too.

Conclusion

These are just four major things I've picked up over the years. All games have more specific issues that could have been done better and which are useful to talk about, but I wanted this post to be generally useful. Most games could be improved in these areas, and if thought is given to these from the beginning of a project, they probably wouldn't require any more work.

I think it's sad when a game really stinks. A game represents a lot of time and creative effort, the expenditure of real human life value. Usually, the difference in work between a crappy game and a good game is a relatively few small changes.[5] But when those changes are left undone, all that effort is wasted.

-------------------------------------------------------------

[1] About the same time I played Assassin's Creed, I also played Hitman: Blood Money. That is an assassin game done right, and I played every level until I got the "Silent Assassin" rating. Assassin's Creed should have been called Pompous Brawler's Creed.

[2] There are other reasons people play games too. MMORPG's tap into our social natures, and games can also stimulate our OCD tendencies, e.g. when I have to finish a collection or find all the hidden packages or whatever. Some players also play games to escape reality, and that's sad.

[3] Multiplayer games have the inherent ability to push players and keep their skills evolving, but they are difficult and expensive to make. Multiplayer is the reason I like FPS games so much. I've played a lot of Counter-Strike, Team Fortress Classic, Team Fortress 2, Combat Arms, and Left 4 Dead. The most successful games have been multiplayer ones, but they're more of a "cash dragon" than a "cash cow"—if you can manage to slay the dragon, you'll make a lot of money.

[4] Grok is the term Raph Koster uses to describe when a player has mastered the skills of a game. This is the point at which I usually quit playing.

[5] The key term is "relatively". If you think about a game project, there's a lot of art and a lot of code that went into it. As an example, it wouldn't have been much more work to make the "Career" mode in SH3 take the player through each scenario with the recommended load-out. In the final stages of Now Boarding development and now Clockwords development, little changes that require very little work end up making a big difference in the overall player experience.

Flash, Flash, Flash....

2010-02-05T11:04:00.000-05:00

...Why you gotta be like that?

I was tempted to call this post my "Flash 'Dear John' Letter" in reference to Danc's Flash Love Letters, but since we're not actually dumping Flash (at least not yet), it wouldn't be accurate, just catchy.

So what is this post about then? My gripes with Flash. Many people have love-hate relationships with tools and products they use. We're finishing up our second premium Flash game right now, and while I love the good things about Flash more than ever, I'm increasingly frustrated by it. I hope that by joining with other Flash game developers in airing our grievances, Adobe might take notice and make some changes for us. If they don't, we won't be the only developers switching to Unity.

The Good

We use Flash for two reasons:

Wide Reach – Almost all internet-connected computers can run our games.
Rapid Development – Games come together quickly.

We like these things about Flash development:

Tight integration between assets and code.
AS3. I have to admit, I enjoy writing AS3 code. I have several years of C/C++ experience and a few more of C# experience, but I'm having a lot of fun with AS3. Yeah, it's missing some language features, and it can be quirky, but it's fun.

The Bad

These are things that are really hampering large-scale Flash game projects for us.

1. Two necessary tools that don't work together very well.

Flash CS4 doesn't cut it for software development—it's terrible. It's great for creating visual assets, laying out interfaces, and exporting compressed sound. Those things are necessary for game development, and Flex Builder can't do them, so Flash CS4 is a necessary tool (if there are alternatives that really work, I haven't found them).

Flex Builder is vastly superior to Flash CS4 for compiling and debugging code. Flex Builder 3 is the only Flash profiler, so it's necessary for game development, IMO. I know not all Flash game developers use it, but most don't create large programs that need it. Garbage-collected languages need memory profiling at the very least. That's about all I use the profiler for. The performance profiler just tells me what I already know: all the execution time is spent rendering the game.

In theory, CS4 could export a .swc that FB imports, and I could load the symbols and do my thing with them. But there are bugs.[1] The only way I've found for objects exported from CS4 to always work as expected when imported into FB is to export a .swf from CS4 and load it dynamically in my FB AS project.[2]
This integration is clunky and tedious to setup and maintain.

Solution: Fix the bugs, remove the hoops we have jump through. Make FB and the Flash IDE work together seamlessly.

2. All asset data is contained in the .fla's.

We have a couple hundred MB of bitmaps and wave files in our game. All that data is imported into .fla's. The visual things are laid out and composed into symbols which I can use in code. The sounds and music are compressed and processed by Flash, which does a great job.

This leads to two problems:

Tim and I (and our other contractors) all work at different locations, and our SVN repository is on the internet. We already have hundreds of megabytes to check in and update, and then the .fla's double it. While most check-ins and updates don't touch nearly that much of the project, sometimes they do, so I postpone my check-in until I'm done for the day so I can start it and walk away. If Tim needs something sooner, then I have to do it during the day and interrupt my work.
Whenever a file on the disk changes, we have to open the .fla it's in and update it manually. This is stupid. That's the nicest word that accurately describes this "feature" of the Flash IDE.

Solution: Store references to files, not the file data itself in the .fla. Unity does this.

3. Flex Builder caches source files.

Ironically, FB has a similar problem as CS4. I can't stand the FB code editor or the Flash IDE's code editor, so I use an external one (gVim FTW!). Other people probably like it just fine—that's not the problem. Code editor preferences are personal, to each their own. The problem is that when I change the files on the disk, FB doesn't notice, so it doesn't recompile them when I build the project. This is true of the .swf's that I export and embed in the project and the .as files themselves.

There are 2 work-arounds for this problem:

Open the .as file in FB, because then it will say "Hey, the file changed, do you want to reload it?"
Project -> Clean -> OK. Then it recompiles everything, which takes a lot longer. I have to clean the project whenever I re-export from CS4. If I just change code files, I have to estimate which work-around will be faster.

Solution: Don't copy all the source files, just use the ones I'm editing. It's trivial to detect when files change.

4. Both tools are bloated and slow.

It doesn't take a very complex scene for CS4 to start lagging, and I have a nice machine. While our projects might be big by Flash standards, they are small by the rest of the software world's standards. 8 years ago, working at Acclaim, I could build our much larger project (a AAA-sized title) on my totally garbage Win95 computer just as fast as my core i7 machine builds my much smaller Flash project today.

What gets me though is how the CPU on my computer is hardly doing anything while CS4 is exporting or FB is compiling. What the heck is the program doing? CS4 has just 1 file to read (as already covered), and it's even slower than FB. I have all my big music wave files in 1 .fla, and even exporting it doesn't use any CPU to process all that data. Yet it takes minutes to export, and during that whole time, CS4 is completely unresponsive. FB doesn't go unresponsive when compiling, but it still takes a long time and doesn't utilize the CPU at all. No CPU utilization means the process is spending most of its time waiting. That is very poor software design. All other compilers I've ever used are much faster.

Another result of this issue is that our game assets need to be split up into many .fla's to keep compile times reasonable. That adds additional headache for managing what is where, which compounds with issues #1 and #2 above, since more .swf's have to be dynamically loaded, and then assets need to be loaded from the right .swf's, and when changes are made, the right .fla needs to be manually updated.

5. The Flash Player is slow.

It uses a software vector renderer, which is never going to be fast compared with the hardware bitmap renderers that most games use. For small, simple games and ad banners, it's great. For large, complex, fullscreen games, it stinks. AIR does perform better fullscreen than the Flash Player does, but it's still nothing compared to hardware acceleration.

In our latest game, Clockwords, we've made almost everything bitmap-based to bypass the slow vector renderer, and that keeps our game working on slower machines. But this comes with another source of headaches: we need low-res versions of our art for the web game, and high-res versions for the AIR game. That means we need another set of .fla's and another set of art. If Adobe hadn't introduced conditional compilation, then this would have been way too retarded to accomplish. With conditional compilation, it's just retarded, but still possible.

Solution: Make real hardware acceleration a higher priority. There are opensource and proprietary products that can run .swf's in a hardware accelerated environment, so this is not an unsolvable problem. It just hasn't been a priority for Adobe. Don't worry about models, animations, shaders, or any of that stuff. Stick with 2D, it's OK. Just write code to transform vector shapes into triangle strips, and you're just about there. ;)

Conclusion

Flash has historically been targeted at small project sizes, like ad banners and short form games. Adobe is spending lots of time and resources on Flex, which is targeted at RIAs. Long form Flash games require the software dev tools of the Flex world and the visual tools of the Flash world (with improved support for large projects). We are stuck in the middle without good tool support on either side.

While we're reaping the benefits of wide reach, the poor tool support is greatly increasing our development burden. We're sore from hitting our heads against the ceiling Adobe has placed over the Flash platform.

Musings

It would be nice if Adobe addressed these issues, because then we could keep doing what we're doing. We've invested a lot of time and money into Flash development, and the libraries and community support are great. Companies like MochiMedia, FGL, and the countless Flash portals make game development and distribution much easier than other platforms.

I think Unity is positioned to grab some significant market share. All it needs to take off is content, and indie developers are already flocking to it now that it's free for indies (or at least poor ones). When there is sufficient content for the Unity browser plugin, users will install it, and portals will support it. We're not really that interested in making the jump to 3D, but we're definitely interested in hardware acceleration...and a sane art pipeline...and just 1 slick tool. As Unity gets more developer support, it will get wider reach, and so the #1 reason to use Flash will be reduced.

We're kicking around ideas for our next project after Clockwords, and we're pretty sure we want to do a bigger one. Unless the Flash scene changes significantly, taking on Flash's limitations and headaches to get its reach probably won't be worth it.

[1] The primary bug was that timeline script didn't always execute. Some animations need some script, and so I need the script to work.

[2] You can see how I do it in our Global Game Jam 2010 submission. The source is in the .zip file you can download from there. The com.gabob.ggj2010.assets.Assets.as file contains a list of all assets exported from the GameAssets.fla. That way, I can write my code against the Assets.as file to let the compiler make sure all my references are spelled right.

http://globalgamejam.org/2010/squeek-sneek

Global Game Jam 2010

2010-02-01T10:37:00.002-05:00

As many of you probably know, this past weekend was the Global Game Jam! We decided to do it, and we hooked up with the group at Newport, Wales, so we could start and end earlier than our own time zone. We partnered up with a great artist named Scott Thompson in Wales, and we made a game in 2 days.

Post-mortem

Making a game in 2 days requires some different skills and thinking than making a game at a "normal" pace does. I had to set aside some of my OCD tendencies and make some last-minute, dirty hacks to get a couple things working.

Perhaps the most useful thing was the necessity to limit the scope of the project. It's really easy to say, "Oh! Let's add this!" We say that a lot when we're working normally. When prototyping, it's important to really stick with what's essential for the core gameplay. The reason is because until you have the core done, you don't even know if it's going to be fun. While we've always prototyped our ideas before making full games out of them, we tend to let our prototypes bloat a bit, and we've thrown some out, so we could have saved the time if we stuck with the core features.

With a 2-day limit, it's also a good idea to stick with what you know, just for practical purposes. Some might disagree with that because it can limit creativity, but it just depends on how complete you want your game to be after 2 days.

Game Overview

The theme for this year was "deception", and the GMT constraint was "a sink, a wink, a rink" (in no particular order). We made a game where you play as a mouse looking for cheese in a big kitchen. You have to sneak around, avoiding being seen by the humans in the kitchen. Cheese can be hidden in one of a dozen places, and you have to find it and get it back to the drop zone near where you start. Each time you collect one piece of cheese, another piece and a mouse trap spawns on the map. Running into a trap kills you instantly, game over.

To make things more interesting though, you can only see traps, cheese, and obstacles a couple feet in front of yourself. Also, some of the kitchen appliances can be used to distract the humans and make them look at them. Click on objects that glow green to start them up. Some take longer to activate than others (e.g. filling a sink to over-flowing takes longer than knocking over a garbage can). Gray squares can only be traversed when you don't have the cheese, so you have fewer sneaking options when you're carrying it.

You can play the game here:
http://gabob.com/GGJ2010/GameFlash.html

This is the GGJ page for our game where you can download the source and stuff:
http://globalgamejam.org/2010/squeek-sneek

Conclusion

I'm not sure (at least at this point) if we'll do it again, because of the sleep deprivation and time away from families, but it was fun. Maybe in a year, we're be ready. In the meantime, we'll definitely keep our prototypes more focused.

Choosing a Business Partner

2009-11-30T16:27:00.000-05:00

Over the course of about 3 weeks from the end of October to about half-way through November, we passed a nasty cold through our family. During that time, I didn't shave at all, so when I was feeling better I thought I'd cut off most of the beard I grew and leave a goatee. When one of my sons saw me the next morning, he said, "Whoa, Dad, you and Tim both like games, and you both have goatees. You guys are practically the same!"

I thought that was funny. We also have noses and two eyes, but other than facial hair configuration (I've since shaved it all off), common human features, a desire to make fun games, and a common vision for our company, our similarities don't extend much past those things.

That's what I want to write about today. The success of a start-up business depends heavily on one's choice of business partner(s). Gabob is my second attempt at a serious business venture with partners. The first never got off the ground because of my choice of partners, and this one is working quite well because I chose wisely. However, it wasn't until after Tim and I started working together that I realized that I chose wisely and why.

There are two critical factors to consider, IMO. First is determination. How determined is your prospective partner to "make it happen"? Is he/she as determined as you are? Will he/she see the project through to the end? If not, then it doesn't matter how smart or talented he/she is: that person is not a good choice. That was part of the problem with my first business attempt. We'd talk a lot and plan a lot, but when the meeting was adjourned, I was the only one who got working. I was the only one who had anything to show at the next meeting. After a couple meetings like that, I just didn't schedule the next one. None of them did either....[1]

Without determination, no start-up will succeed. The second factor, of which my son inadvertently reminded me, is to pick someone different than you. The primary reason is this: there are a lot of things that need to be done in a start-up, and if you both like doing and are good at doing the same things, then deciding who will do the rest will be drudgery at best and a source of conflict at worst.

Because Tim and I are so different, we don't compete for tasks. We do game design and make business decisions together, but when it's time to work (which is most of the time), I do my thing, and he does his. I write code and keep the books, and he does most everything else. I'm good at focusing on one thing, and he's good at juggling several things at once. I'm good at planning projects and organizing data and assets, and he's good at managing our contractors and negotiating with portals. We each see things the other doesn't. I mean, my skillset is so specialized (I write code) that if I partnered with someone like me, we'd be doomed. [2]

The ironic thing is Tim and I met at a company where we both worked as programmers. The difference is that I was doing what I was born to do, and Tim kinda just fell into it before he found what he was born to do. He has now found it [3], and our business is benefiting from having two very different, complementary co-founders.

Notes

[1] There were many other reasons the project was doomed to fail, but I didn't see the other reasons then. I bailed on the project because I was the only one working on it. The project was way too big for the team we had. That's another thing we've done better with Gabob. We also had a hard time agreeing on what product to make. There were strong opinions on certain issues that were at odds with each other.

[2] Seeing things differently and having different tastes has the potential to cause conflict. If a person is too stubborn to listen to another viewpoint or change his/her own thinking, then that person will not reap the benefits of partnering with someone who is different and will likely cause the relationship to end. I'm more interested in doing the right thing for our business than doing the thing that was my idea, and so is Tim. In the past 2.5 years we've worked together, we've only had a couple discussions that caused one or both of us to take some deep breaths (at least that's all I know about...maybe he has to exercise more patience with me than I am aware of :) ). But each time, one or both of us let go of one or more of our own ideas in order to accept one or more ideas from the other.

Usually our final decision is a combination of our ideas and is better than either of us came up with on our own. I can think of multiple times when he has persuaded me and when I have persuaded him. There have also been a couple of times when he accepted something I proposed without questioning it, and that made me a little nervous. I count on him to see the holes in my thinking, and when he doesn't see any holes, I know it's not because there aren't any—it's because he doesn't see them either. In those cases I can't help but wonder what kind of "surprise" will come up later.

[3] Tim is a hustler. By that, I mean that he is really good at getting other people excited about what we're doing. Whether it's contractors, publishers, portals, or fans, he gets people on board. While we wouldn't have a product if I didn't code it, we wouldn't make any money if he didn't sell it. Both are necessary for a business to work, and I'm glad he can do and enjoy what I can't, because that frees me up to do what I enjoy.

AS3 Memory Management

2009-11-09T10:18:00.000-05:00

After developing in C++ for several years, I must admit I found the idea of garbage collection in higher-level languages like Java, C#, and ActionScript to be alluring. Making sure every "new" was matched by a "delete" was tedious but absolutely necessary. Like any serious C++ programmer, I developed patterns and habits for making sure the code I wrote was clean as I wrote it, because tracking down memory leaks after they've crept in is even more tedious than thinking about "delete" whenever I typed "new".

My first experience with a "garbage collected" language was C# (.NET). After getting deep into development of a new product, I quickly discovered that the garbage collector was really not so magical, and not even really that smart (at least not for a highly memory-intensive application). I learned that I had to think just as much about making sure memory was collected as expected and when needed as I did when writing C++.

When I first started with AS3, I figured I probably could trust the garbage collector this time (different language, different application, smaller scale), but as Now Boarding (our first AS3 project) neared completion, it became apparent that memory was again not so magically taken care of. Really, I shouldn't have been so surprised, but I was somewhat disappointed, because my understanding of the garbage collector was that I shouldn't have had one of the problems I ended up facing in NB.

I'm writing this post as a practical guide to AS3 memory management. You can read the technical specs and algorithms which the garbage collector uses elsewhere. This guide is based on my many hours of experience with the memory profiler in Flex Builder 3 and is about what actually happens and what you can do to fix/avoid memory problems in AS3.

Now that the background is over, let's set the stage:

Why does memory management matter in AS3?

There are probably many smaller-scale games and applications out there in which the author thought basically nothing about memory management. Sometimes that works. For the larger-scale games we've made and are making, poor memory management manifests itself in a critically bad way: poor performance. As the pool of allocated objects grows and grows, it takes the garbage collector longer and longer to process the references, and it has to run more frequently. Each collection pass is a noticeable pause in the game which happens every few seconds. The game also generally runs more and more slowly. Eventually, the game becomes unplayable.

How does that happen?

The short answer is that the game is maintaining references to the objects that are no longer being used, and those references make the garbage collector (GC for short) think the objects are still being used. The GC only frees memory allocated to an object if the object has nothing referencing it (or a group of objects that reference each other have nothing else referencing any of them). If the game would only null out all references to an object, the GC would reclaim the memory, and the pool of objects would not keep growing.

Unfortunately, it's not quite that simple. I tried to treat it like that, and it didn't work as I expected. In NB, each game mode is an object that contain everything for that game mode. The game mode object itself is the root of the whole object hierarchy. I figured that if I just set the 1 reference to the game mode object to null, then the GC would recognize that the whole hierarchy was orphaned. Nope! Every game mode was staying in memory after the next one was loaded, so going in and out of the game made the memory go up every time until the game was unplayable.

In practice (maybe this is in the spec, I don't know, but I missed it if it was), there seems to be a limit on just how big an orphaned group of objects can be before the GC just gives up and assumes the whole group is still being used. That brings us to my first tip:

TIP #1: Explicitly null out your object references. If you have an object hierarchy that you want to be collected, null out the references each object has to the other objects in that hierarchy explicitly.

Don't asume that the GC will recognize the whole thing is orphaned.

Along with nulling references, event listeners are also extremely "sticky" when it comes to making sure objects "stick" around. In my experience, using weak references doesn't matter. If one object (Object A) subscribes one of its methods to an event on another object (Object B), then Object A and Object B will never be collected, and any objects they reference will also never be collected.

TIP #2: For every call to addEventListener, make sure you call removeEventListener.

To fix the memory leak between game modes in NB, I had to make sure every single event listener was removed. Each one that "leaked" caused the objects involved to stay in memory. I give every object that references another object a destroy method that I make sure is called. In that destroy method, I set all references to null (after calling destroy on all children that have a "destroy" method, of course), and I make sure all event listeners are removed. Yes, that's obssessive-compulsive, but it entirely solves all memory leaks (well, unless you really are keeping references around...).

This is where the memory profiler in Flex Builder becomes indispensable. Particularly useful, IMO, is the "Live Objects" view. Running under the profiler, I can load a new game mode and see the object associated with the old game mode disappear (or not disappear, and then I can drill down and see what is still referencing that old game mode object).

TIP #3: Use the Flex Builder memory profiler. It's only in the $699 version, but it has a 61-day trial, which is plenty of time to use it to fix your game. Then just reinstall Windows when it comes time to work on your next game. ;) If you're a serious AS3 developer, then the $699 price tag shouldn't deter you. Get the tools you need!

Object Pooling

When an object isn't collected when the game is no longer using it, that's a memory leak, and if you have enough, then the game's memory usage will grow and grow until the game doesn't work any more. That's a memory management issue AS3 developers need to be aware of.

Another potential problem that can frequently come up in various types of games is creating lots of objects while the game is running. If the objects are leaking (i.e. not being collected), then the game's memory usage will grow as the player plays the game, leading to slow down and eventual crash (follow tips #1 and #2 to fix that). If the objects aren't leaking (i.e. the memory is being reclaimed), but if the number or size of objects being created is large enough, then another problem happens: frequent pauses.

When the GC runs, it causes a noticeable pause in the game, as it collects all those properly orphaned objects. If you watch the memory usage graph in the profiler, it will look like a saw blade. Memory rises as those objects are created, then it drops back down suddenly every time the GC runs. The more the GC has to collect when it runs, the longer it takes, and the greater the pause in the game (and the more jagged the saw blade).

If you have saw blade action in your memory usage graph, then you would most likely benefit from object pooling. That's a fancy term that essentially means reusing your objects so that they never have to be collected. Then your memory usage graph stays nice and flat, and the GC can basically just go to sleep while your game runs, never interrupting your code or the player's fun.

Once I saw the saw blade thing going on in NB, I tried to retrofit some object pooling into the game. While I was able to drastically reduce the jaggedness of the graph, I couldn't pool everything (ran into some weird issues with one MovieClip), and so NB retains some saw blade action to this day. I wrote some classes to facilitate object pooling which I used from the start in Clockwords, so CW doesn't have any saw blade action going on. Its memory graph is a perfectly horizontal line, even though letters, explosions, hit animations, and bugs are continually being created and destroyed. Then when the game is over, the memory usage drops back down as all objects in the old game mode are collected properly.

TIP #4: Pool objects that need to be created and destroyed frequently.

Object pooling is really simple. I posted the class I wrote (along with a few helper classes which it uses, such as my linked list class) here. There's no license or copyright or anything in the code, and you can do whatever you want to it or with it.

To use the gaObjectPool object, just create one and pass in the Class type you want to pool and a block size, which is just how many instances of Class the pool will instantiate if a caller wants an instance of Class, but there are no more left in the pool. You can use 1 if you want (you can even make that a default value, since you have the code ;) ).

So once you create a gaObjectPool instance for the type you want to pool, stash the reference to that object wherever you need it. Then when you want an instance of that type, call getObj, and cast the return value to your type. Use the object as you please.

When you're done with the object, call the destroy method on it (you have one right?). I find it useful as a design pattern to give all objects I pool a destroy method which resets all member variables to a known, default state, as if the object were just constructed. That way when subsequent callers of getObj get the same instance back, they don't have to worry about what might be lingering in the reused object. After calling destroy on the object you want to reuse, pass it in to the gaObjectPool.returnObj method. That'll put the object back in its internal linked list so that the instance can be returned by a later call to getObj.

Last word of warning: don't return the same object instance to the pool more than once at a time. That'll cause the object pool to hand it out more than once to different callers who then both try to use it for different things.

A quick note on gaList: it's a multi-purpose linked list class, which you probably noticed pools its node objects. Linked lists are preferrable to Arrays when the contents of the list changes frequently. In practice, most of my collections change frequently, so I use gaList for most of them. For example, a queue (first in, first out) is a type of list that is perfectly suited to a linked list implementation. To make a queue with gaList, use "add" to add objects to the end of the queue, then "removeHead" to remove and return the first item in the queue. If you don't want to remove the head of the queue, then just use "getFirst" to peek at it.

Conclusion

If you're making a decent-sized game, you will probably run into some memory issues during the course of development (or...gasp...after release). The issues might not be serious enough to refactor your code to retrofit these tips, but you should understand the potential pitfalls of AS3 memory management and know how to prevent them or at least fix them if they end up causing problems for you.

Better Burgers

2009-10-27T20:27:00.001-04:00

Last Saturday I went to a steak house in downtown Charleston, WV. We picked it because it was close to the convention center we were at and not fast food, i.e. we didn't pick it because it was a steak house. Their sign said they have the best salad bar in the state or city or something. I thought that sounded good. The way their menu is priced, the hamburger and fries with a salad bar addition was only $0.84 more than the salad bar by itself, so I thought, "Hey, I'll add a hambuger and fries to my salad bar for 84 cents!" Yes, kids, math is a useful skill.

So to make a long story short, I'm writing this post as a public service, to advance a cause that I think needs advancing: Better Burgers. A burger is a sandwich, so all sandwich principles I've written about before apply here. However, burgers are so common and so commonly screwed up that they deserve a post dedicated to them.

Chances are, if you're reading this, you've probably had a burger at some point in your life. Here in the US, they are a common part of our diet, and are commonly massacred on weekends and at outdoor gatherings across the nation. I would say that most Americans think they know how to make a hamburger and that most Americans have, at some point, "made" a hamburger. I've had burgers in dozens of settings, by dozens of home cooks, and dozens of restaurants, and the worst burgers generally make at least one of three common Burger Blunders. These Blunders are not equal though, so I will present them in "worst to less-worse" order.

But first, a couple items of clarification.

What is a burger?

A burger is a sandwich which features a ground-beef patty. Most often, the burger is served on a round bun designed specifically for a hamburger. But really, the critical feature is the ground-beef patty.

Why is a burger delicious?

This can be summarized as follows: juicy beefiness.

There are lots of toppings and accompaniments that can be added, but if they over power the juicy beefiness, then the sandwich may as well not be a burger. It might still be a very good sandwich, but not a good burger.

Ok, let's start with the Blunders....

Blunder #1: Dry Meat

Not surprisingly, the worst way to screw up a burger (and which 99% of all burgers I've ever had totally screwed up) is to have dry meat. There is no juicy beefiness when the patty is dry. What makes a burger delicious is destroyed. Gone. Lost. Forever. Americans already have little respect for the animals that give theirs lives for their fleeting moments of gluttonous pleasure, but to over-cook their flesh and ruin it is the second greatest disrespect we can give to those animals. (BTW, the greatest disrespect is to throw it away without eating it).

As mentioned, over-cooking is the way to dry out a burger. Now, that doesn't mean you can't cook it "well-done", it just means you can't cook it too much. Well-done does not mean "over-cooked". Over-cooked is "poorly-done" or "sadly-done" or "incompetently done". I ordered my burger at that restaurant "medium", and it had pink in the middle, but it was still crumbly and dry. Burger King's patties are fully cooked with no pink, but they're still juicy. There's more to moist meat than just how "done" it is.

Moisture in a hamburger comes from 2 sources: fat and water. Meat naturally has both of those, and both are destroyed by cooking. Heat turns the fat to liquid, and then it runs off. Heat causes muscle fibers to contract, squeezing out water, which then runs off and evaporates. If too much fat and water are lost this way, then the meat ends up dry.

Let's talk first about fat. You can't add fat to the outside of the patty and expect the meat to soak it up. The fat has to already be there in the meat, before you start to cook. If you really have to stick with lean ground beef for health reasons, then you'll just have to focus on retaining water and cooking the patty properly. But if you can afford to eat something more delicious, use ground beef with about 33% fat. That'll give you more flavor and more margin for error when you cook it.

Now let's say a word about water. Again, your goal isn't to add water, but to retain more of what it has. Mother Nature and the laws of chemistry has actually made this really easy, and it also helps avoid Burger Blunder #2. The solution is salt. When salt diffuses into the muscle fibers, it causes the proteins to unwind a little bit (or something like that), and then they hold onto their water better. You can still destroy the meat by over-cooking, but the meat will be juicier at higher temperatures that if it wasn't salted.

Salting the meat can be accomplished in two ways. First, you can mix it in with the raw ground beef before you make patties. This has the added benefit of helping the patties stick together better. I use anywhere from 1/2 to to 3/4 Tablespoon of kosher salt per pound of ground beef. Start low and add only little bits at a time, because you can't take salt out once you put it in. Since the salt affects flavor too, you don't want to add too much, but some salt is better than no salt for the texture of the meat. Half a Tablespoon is not enough to make the meat taste salty (e.g. like sausage does), but it's enough to enhance flavor and texture. I usually use more if I don't have a seasoning mix or something else planned for the top of the patty. Mix the salt in, make the patties, and let them sit for at least 30 minutes before cooking. The salt needs time to get into the muscle fibers.

Second, you can lay out the patties on wax paper or a cookie sheet or something and sprinkle salt on them. Let them sit, salted, for at least 45 minutes before cooking to give the salt time to penetrate the meat. This will work just fine for pre-formed patties, but thaw them first. If the patties are thick, salt both sides. (Incidentally, this works great for steak, chicken, pork chops, and whatever cut of meat you have.)

With enough fat in the patty and some salt diffused into the muscle fibers, your juicy beefiness can only be ruined now by over-cooking. The correct cooking temperature depends on how done you want the middle. Hotter temperatures are required for less done middles. The trick is to get the middle done how you want and the outside browned how you want at the same time. If the temperature is too hot, then the outside will burn before the middle is done. If the temperature is too low, then when the middle is done, the outside isn't browned properly yet. Chances are, you cook your hamburgers too hot, because that's how most backyard-barbecuers I've seen do it ("Kill that meat, and desecrate that animal's memory" is the motto of most home cooks).

A better, but more difficult technique is to cook the meat at a hotter temperature and take it off before the middle is done how you want, because the heat from the patty will continue to move into the middle and finish the cooking off the heat. This produces noticeably better results.

Blunder #2: Unseasoned Meat

What's worse than a dry hamburger patty? A dry, tasteless hamburger patty. You know what's worse than a dry, tasteless hamburger patty? A thick, dry, tasteless hamburger patty. Unfortunately, that describes most restaurant and homemade burgers.

Salt is the most important seasoning for meat. It improves texture and juiciness as already described. But it does even more! Salt is a flavor enhancer. It helps your taste buds taste better. It brings the flavors out of food so you can experience them. Of course, if you put too much salt on food, the salt masks the flavors. That's bad. Don't over-salt your food. Don't turn your hambuger patty into a sausage patty (but a sausage patty is generally preferable over what some people serve as hamburgers).

If a hamburger patty is salted such that it enhances moisture, then the salt has permeated the patty. If cooked properly, it will be juicy and flavorful throughout, and it doesn't matter how thick the patty is (but how thick it is definitely affects how to cook it properly).

This is what makes Fuddrucker's such a sad burger joint. They have amazing buns, great toppings, good meat, and their burgers are quite juicy. But they don't season their meat! You have to have a lot of toppings to compensate for no flavor in the patty. They do so many things right (all the hard things, in fact), and that's why it's sad. They're so close!

Blunder #3: Mismatched Bun

If you've avoided Blunders #1 and #2, then you have a great hambuger patty. What are you going to serve it on? Your hamburger can still go wrong. If you're like most Americans, then the answer is: "Put it on a bun that's twice as big around as the patty." WRONG! I want a hamburger, not a bun with "I think there might be meat in there."

If you're making your own patties, then refer to your buns (no, not those buns....the ones in the plastic bag on the counter) when you make your patties. Here's the trick: make the patty bigger than the bun! Why? Because the patty is going to shrink when you cook it. The more you cook it, the smaller it gets. And remember, it's shrinking because it's losing juiciness, so don't over-do it!

It's ok to use pre-formed patties. Once they're thawed, salted, and rested for 45 minutes, cook them gently and only just enough. That'll help them stay as big as possible. I've cooked pre-formed patties plenty of times, and they do always end up smaller than the bun, but only a little bit smaller. They're still ok. However, most people over-cook the patty, and then they end up much smaller than the bun.

I remember when I was a kid, one hotdog company came out with "bun length hotdogs." It made so much sense to my little-boy brain. When I see a hotdog that is shorter than the standard hotdog bun or when I take a bite out of a hamburger and just get bun, I can't help but think, "How can this still happen in 2009? We put a man on the moon, but we can't make the bun and the meat match?"

Conclusion

Don't use lean ground beef. Salt the meat in advance, both for juiciness and for flavor. Cook it only just enough. Put it on a bun that matches its diameter. Now all you have to do is not mess up the toppings, but that's the easy part.

Home cooks have been destroying meat since the beginning of cooking, and hamburgers are definitely not the only victim of this mindless desecration. What makes hamburgers unique though is the frequency with which restaurants screw them up. Ordering a burger in the US should not be such a gamble. In 2009, with modern science, technology, and the information available on the internet, all hamburgers served should be juicy and delicious.

Now Boarding Post-Mortem

2009-10-14T17:10:00.000-04:00

I wrote a post-mortem of Now Boarding for MochiLand, and it was published today. If you're interested, check it out. If you have any questions, let me know.

Mochi + Flash Portals, Part 2

2009-10-08T12:07:00.000-04:00

This is the second of a two-part series about Mochi and Flash portals. I decided to write these posts after reading an interesting discussion on fncgamesblog.com. In that discussion, the original poster complained about MochiCoins and MochiLeaderboards. So Part 1 was about micro-transactions, and now this will address his (and other publisher's) issues with Mochi's services: loss of traffic.

I can see where they're coming from. They earn their money from advertising, and ads pay according to traffic. Less traffic means less money. No one wants less money. So they conclude that any service or practice that "steals traffic" should be done away with. They think Mochi is trying to steal their traffic by letting players share their scores on Facebook and also to create a MochiCoins account to access premium game features, both of which require the players to leave the portal's site.

I hope that accurately reflects their view of the issue, because my counter argument has nothing to do with the validity of their fear that Mochi's services are causing players to leave the portals and not go back. Mochi's services might be "stealing traffic," and if they are, then they are decreasing revenue from those players.

Download portals forbid services like that and go even further. They forbid developers from putting links to their own site anywhere in the game. Of course, players can always open a browser and search for the game or developer to find community features, additional content, or otherwise communicate directly with the developer. But the portal doesn't let the developer make that process as easy as it could be with current technology.

In this post I want to respond to the issue of portals and traffic in general, not just Flash portals.

Middlemen

A middleman is anyone who collects a product from one party (the source) and delivers it to another (the customer). The middleman doesn't create any products, but he provides a service. The value of the service varies according to the difficulty of the customer's obtaining the product from the source himself. A middleman's customer may be another middleman.

The more middlemen involved in delivering a product from the original producer to the end consumer, the higher the price for the end consumer. The higher the costs the middlemen incur to deliver the product, the higher their fees, and so the higher the price for the consumer. The British East India Company had a fleet of ships to physically transport goods from the East to Europe. Its costs were huge, but its mark-up of the goods was larger still. It created nothing, but provided a valuable service for the end consumers in Europe and made a lot of money as a result.

What do portals contribute?

Developers (the source) make the games and players (the end consumers) play the games. Portals act as middlemen. The cost to deliver the actual bits that make up a game is approximately zero. Unlike middlemen in the physical world, middlemen on the internet do not create value through delivery.

The amount of information on the internet is vast, and it's increasing every second. Because the internet has solved the problem of delivery, it has created a new problem: information overload. The problem is no longer how to get product X, but how to find product X among the vast cloud of information at our fingertips. For the internet to be useful at all, we need a way to filter the information. Information needs to be organized, searched, indexed, and not just delivered.

From the player's perspective, portals find games, organize them, and make them easy to find and enjoy. From the developer's perspective, portals sift through all the many users on the internet and find just the ones that are looking for games. Portals connect the source with the end consumer, a valuable and necessary service.[1]

Threats to portals

Like all middlemen, portals can only stay in business if their customers would rather pay them [2] than do the work of obtaining the product from the source directly. If the player can easily find and communicate with the developer directly, then the portal is not needed for anything.

This explains why Flash portals pay developers to rebrand the game with their own logo. This explains why download portals require developers to remove all external links. The portals have an interest in building a wall between developers and players with one gate that they control.

The Costs

Whether through advertising or direct sales, the money in the game industry ultimately comes from players. The happier players are, the more they pay, the more they recruit their friends, and the bigger and faster the market grows.

What is best for the player?

Developers get a larger cut so they are more likely to be able to keep making games and to take more time to make better games.
Easily find other games by the same developer. If they like one, they are likely to appreciate the others.
Establish a relationship with the developer to make his desires known, so that the developer can satisfy them more effectively.

The current policies of game portals stifle those. Building a wall and keeping the gate gets them a bigger piece of the pie, but it's limiting the size of the pie and the rate of growth.

What does this have to do with MochiLeaderboards and stealing traffic?

Portals are obsessed with traffic. They are scrambling to quash threats like Mochi's services that facilitate direct developer-player exchange. Yes, those services are breaking holes in the wall portals have built. If players can establish a relationship with a developer directly, then that player doesn't have to go back to the portal to play or buy the developer's other games. The developer makes more money, and the player gets more and better games.

The portals think they've lost something if that happens. They haven't for 2 reasons.

First, because the developer and player both benefit from direct exchange, the market grows. That means over time, more and better games on the portal's site and more players to play and buy them.

Second, especially in the casual and Flash markets, players consume games much faster than developers can make them. The player can play through the developer's other games, give them some feedback, and sign up to be notified when new content is released. A week later, the developer hasn't released anything new, and the player is ready to play another game. So where does he go? To a portal. And why does he go to a portal? Because it will help him filter the vast amount of information on the internet to find new games he might like.

Conclusion

The real value a portal provides is not delivery, but filtering information[3]. Efforts to solidify its position to deliver (i.e. building a wall to separate developers from players) hurts the market as a whole, which hurts the portal too in the long run. Rather than being obsessed with traffic and delivery and trying to suppress technology that reduces need for their service[4], portals should be obsessed with helping players find the best games. A player doesn't go to portal X because it's the only way he knows to play games. He goes because he thinks it will help him find the best games to play.

For proof of what I'm talking about, visit this portal. Almost every link takes the user away from the site. They recognize that they are in the information filtering business, and by focusing on making that service the best, they are the most popular portal on the internet.[5]

- NOTES -

[1] There are portals that develop games, and developers that have created portals for their games. However, the work done to create a game and the work done to connect games with players are separate endeavors and are usually performed by different entities. So I treat them separately.

[2] In the case of Flash portals, players don't pay anything directly. But advertisers do, and the reason they do is because the players buy the goods advertised. It's indirect, but the money eventually comes from the players. If that weren't the case, then companies wouldn't pay Flash portals to show their ads.

[3] There are many portals that offer additional services (such as DRM and payment processing, highscore APIs, etc.), and offering additional services is one way for a portal to set itself apart from other portals.

[4] The music and film industries are fighting the same battle to suppress technology. How is a portal's requirement to remove external links from a game progress? It's not. It's short-sighted and self-defeating. It's not good for the player, developer, nor even the portal.

[5] All the biggest sites focus on filtering information. Facebook shows you only information about your friends and what they think is interesting. Digg helps you find things that are popular. Amazon has thousands of products in their store, but everytime I log in, I see a handful of items that are personalized for me....and it works, because every time I look over the list I think, "Ooooooh.....I want that!" Netflix has a recommendation system too. Ebay and craigslist help you quickly find information about good deals on things you want.

Mochi + Flash Portals, Part 1

2009-09-28T10:24:00.002-04:00

Over on the Flash Games Blog, bobjoe6641 posted some interesting comments about Mochi's leaderboards and coins services. He's a not a fan, to put it simply (and maybe lightly). The comments were also interesting, with a couple developers weighing in to offer another perspective. I commented too, and if you read all the comments, then you know some of what I think on that subject. But because it's such an important issue, I wanted to restate my thoughts here with some extra discussion.

The author identified 3 parties in the flash game industry: developers, portals, and players. He complained that MochiCoins is "good for developers but horrible for players and publishers." The unstated premise of that argument is that the 3 parties have incompatible or competing interests. If what was good for one were good for all, then something that is good for me (a developer) would be good for him (a publisher). To start, I disagree with that premise, but the balance of power is shifting from portals to developers.

Healthy Developers

If you consider a dairy farmer as an analogy, it's clear that what's best for the cow will ultimately be best for the farmer and the customers. Cows want food, water, space, and some salt. If they have enough of all of those, they are very hardy and stay healthy. Healthy cows produce more and better milk and do so over a longer period of time and with fewer veterinary costs. If the farmer thinks that his own interests can be served without serving the interests of the cow, then he places himself in opposition to the cow. He sees the cow's desire for food as being competition with his own desires. His myopic view of his business will result in resentment and, if he starves the cow, failure.

There are, of course, many differences between dairies and flash games, but the fundamental principle remains: portals and customers are better off in the long run if developers are healthy.

Short Form Games

In his blog, Danc explained the difference between short form and long form games in his Flash Love Letter Part 2. Understanding the difference is necessary to understand how the market is changing.

Short form games are games with very little content that occupy players for only a short time. Players aren't going to pay for a few minutes of fun, especially not when it can be had all over the internet for free. In order for players to spend more than a few minutes playing these games, he has to play many of them, and in order to play many of them, they need to be aggregated into collections for his immediate perusal.

Portals create value for players by aggregating many short form games. When a player is playing game after game in a single sitting, it's the portal keeping the player engaged. When the player bookmarks the site and comes back later to play some more (and different) games, it's the portal bringing him back. By collecting the games and keeping players engaged for longer periods of time, portals are able to monetize their efforts by selling ad space.

Even though they take real time to develop, neither players nor portals value any single short form game very much, because short form games create little value for players by themselves. That's why there's never been any reason for portals to share their ad revenue: they can do without any single short form game. Short form games need to be aggregated to create value for players. The developers that have made the most money from ads have been the ones who (like Nitrome) have created their own portal.

Most portals understand that they would have nothing to aggregate if developers didn't keep making these games, so they do share some revenue in the form of sponsorships, site licenses, and rev sharing. That money is usually little more than a bonus, and most developers don't get more than a negligible amount, if any. The recent decline in ad money has reduced portal income and, therefore, developer income from this source.

Short form games need portals to aggregate them, and so portals are the ones creating most of the value for the players, and so it's natural for the portals to collect most of the money.

There will always be students, hobbyists, and even businesses that make and giveaway their short form games. Those games will need to be aggregated. There will always be players who want to play them. While ad revenue is declining in the current economy, I'm sure the number of games and players will continue to increase. The short form game industry isn't going to disappear, and it won't be affected by MochiCoins or any other microtransaction or payment model.

Long Form Games

Long form games engage the player for a much longer period of time. When a player bookmarks a site to go back and play a specific game, then it's the game that is engaging the player, not the portal. The developer is creating more value in this situation.

Players are used to spending money on games they want to spend real time with, and they do buy Flash games if they think the value for their money is high enough. We're paying our bills by selling our first long form Flash game, Now Boarding (but not by much of a margin....if portals wanted any more from us, we'd be in trouble).

Microtransactions

Portals have been making a lot of money aggregating content produced by other people. That business model has worked because developers haven't been making games that create much value for players. Short form games are cheap and fun to make, and will always be made. However, long form games cannot be supported by the traditional, portal-dominated ad model. They cost a lot more to produce, and developers need to make more money from them just to survive.

MochiCoins and other services are providing a way for developers to collect money from willing players directly. The original poster on Flash Games Blog and other portal managers in the comments weren't happy about the cut they were being offered. They even cited other industries where the distributor gets a bigger cut, as if that matters at all in this case (the primary reason in the other industries is because the free market has supported it due to higher distribution costs....which don't exist online, so competition is going to bring the online cut down).

In the case of long form games, the developer is creating more value for the player than the portal is, so it's fair for the developer to get a greater percentage of revenue than the portal. What percentage is fair for everyone will eventually settle out from competition, but whatever the portal's cut ends up being, it will likely be much less than their cut of ad revenue in the short form market.

Payment models that collect money from players will support long form Flash games. Developers need to get most of that money in order to keep making more long form games. New players that weren't interested in short form games will go to portals looking for long form games.

It'll be a new, bigger pie that developers and portals will share, and there will be better games for players. Everybody wins!

In part 2, I'll address the other part of their concerns about stealing traffic.

Sandwich Principles

2009-09-21T15:18:00.000-04:00

Sandwiches have always been one of my favorite foods. The idea of all food groups coming together in one food entity is interesting and appealing to me. I’ve had countless sandwich experiences over the years, both of my own making and those of others. Based on those experiences and experiments I have conducted, I have discovered the following true principles of sandwich making.

Moisture

A dry sandwich is a complete and utter failure. PBJ’s are the most common culprit for violating this principle, but meat sandwiches can do it sometimes, so care must still be taken. Moisture can come from a number of sources: condiments, veggies, sauces, and some meats. A good sandwich fills the mouth with every bite, and that moisture is essential for chewing and swallowing. Note: mayonnaise, olive oil, and other fats might not technically be “moist”, but they count if they provide the necessary lubrication.

Stacking Order

The order you put things on a sandwich matters more as the sandwich gets bigger. Even though it all gets mixed together in your mouth eventually, it doesn’t start that way. A classic example is mustard and salty meat. Usually, the salty meat should go on top of the mustard so they enter the mouth together. The acidity of the mustard tempers the saltiness of the meat, and the strong flavors of the meat tempers the power of the mustard. When put next to each other on the sandwich, they enter the mouth together and right from the start of chewing they are synergizing. If you put the mustard on the top half, then when you take a bite, you get strong, salty meat in one part of your mouth, and strong, acidic mustard in another. Only after several chews do the two mix properly.

Surface Area for Sauces

Sauces have a tendency to run out of a sandwich. I’m sure you’ve all eaten a sandwich or hotdog during which some sauce squirted or dripped out when you took a bite. LAME! A good sandwich needs moisture, but that moisture is not doing its job when it’s on your shirt.

No matter how thin a sauce is, at least some if it will stick to whatever surface it touches. The key to keeping the sauce on the sandwich is to provide enough surface area. Even thick sauces like mayonnaise will squirt when surface area is insufficient (or if there's too much sauce).

Shredded lettuce is the easiest way to add surface area for sauces. For that matter, all veggies add surface area and nooks and crannies for sauce. Don’t use lettuce leaves. In addition to not having much surface area, they also violate another sandwich principle (discussed below).

The format of the meat you use also makes a difference. Shredded beef (like in the pot roast sandwiches) has a lot more surface area than the sliced deli meats. These sandwiches hold in the gravy because the beef had surface area!

Keep the Contents in the Sandwich

This is the classic sandwich problem and is a more general problem than the sauce problem discussed above. This is also my kids’ least favorite sandwich issue (more tears have been shed at our dinner table over falling-apart sandwiches than any other thing). When you buy bite into a sandwich, the filling should not fall out the back side or even get pushed out like a hernia.

Many restaurants serve their sandwiches with a toothpick stuck down the middle. While effective, the toothpicks are hard to eat around, and eventually you have to take it out altogether, leaving you alone with the physics catostrophe assembled in the kitchen. While I have learned various techniques for eating those sandwiches which keep me from joining my children in tears, there are things the artist can do to create a sandwich that is easier to eat.

Shredded lettuce, cheese, and meat not only increase sauce surface area, but they also greatly reduce slippage.
Put slices of meat, cheese, and lettuce directly against the bread and put those lubricating sauces in the middle.
Hollow out the roll/loaf you’re using (this helps in 3 ways, discussed more below)
Put less stuff on the sandwich. It’s sad when you have to make cuts, but sometimes you just have to.

Hollow out the Bread

In addition to the 3 ways this helps keep sandwich contents in the sandwich, this also reduces the amount of bread that is diluting the flavors in your sandwich already. This is where good bread really shines. In the sandwiches I made at our recent family reunion, the bread provided a crispy, chewy shell with a taste I could still discern amidst all the other ingredients. It was delicious. If you use store-bought french bread, hollow it out for sure, because otherwise you’re going to be chewing a whole lot of sub-par bread. Just pull out the knife and get that bread out of the way.

Here are the 3 ways hollowing out the bread keeps the fillings in the sandwich:

The sandwich ends up thinner, so it’s easier to fit in your mouth. The way the jaw is hinged, it pushes forward and up, and your mouth blocks the filling from getting squished into your mouth, so the only place it has to go is out the back of the sandwich. A shorter sandwich lessens this pushing action.
Cut a loaf of bread in half and open it up. Lay them there on the table cut side up. What do you see? Two flat surfaces. Slap some mayo on there, and you have 2 slippery slides to build your sandwich on. Hollow them out and suddenly you have gravity on your side.
Hollowed out, the bread forms a shell that nearly (or completely) encases the fillings. It is much easier to hold the sandwich such that your hands can keep the bread barrier in place so the fillings don’t come out.

That last one was the reason I typically make 4 smaller loaves instead of 2 larger ones when I make bread. The easiest part of a loaf of bread to eat as a sandwich is the end, because it has a complete barrier all around the edge. Twice the loaves means twice the ends. Middle pieces lose that protection. Ideally, the sandwich loaves would be small enough so that only wholes or halves are needed to serve everyone.

Our reunion was actually the first time I tried hollowing out the bread, and those sandwiches were by far the easiest to eat of all the big sandwiches I’ve ever made. I didn’t hear any single child cry this time.

Balance Taste and Texture

This is a general cooking principle, and it’s often ignored by the ordinary home chef. By “taste” I’m talking about the 4 types of taste buds we have: sour, sweet, salty, bitter. By “texture” I’m talking about mouth sensations like crispy, crunchy, chewy, soft, creamy, oily, astringent (think: cranberry juice), meaty, spicy. Foods that have more than 1-2 types of taste are perceived as being fuller and deeper, and to have more developed flavor. Foods that have a variety of textures are just plain funner to chew.

Mayonnaise is so good because it tastes a little sweet, a little salty, and a little sour with a creamy/oily texture that compliments salty meat so well. For many, mayo is all a sandwich needs.

Cured meats and cheeses and many kinds of veggies (like lettuce and green pepper) have some bitter flavor in them—not enough to really notice in the sandwich, but enough to excite some of those taste buds and make the overall sandwich experience fuller.

Bread, tomatoes, some kinds of vinegar, mayonnaise, onions, and bell peppers all impart some sweet flavors. Again, they’re not enough to make the sandwich taste sweet, but they fill out the flavor.

Sour comes from mayo, mustard, pepperoncinis, pickled jalapenos, vinegar, pickles, and some kinds of cheese; and even fermented sausages like salami and pepperoni have a slight tang to them.

Salty is easy: meat, cheese, mayo, pickles, olives—even salt itself is sometimes warranted.

Whatever kind of sandwich you want to make, make sure you have all those taste bases covered. Your palate will vary from others, and you might prefer a different balance between the 4 tastes than someone else, but you need some of each to enjoy a full flavor.

The same goes for texture. Variety is fun. With bread, meat, veggies, cheese, and sauce, a sandwich already has a lot going for it, but there are still twists and turns you can take.

Making Money in Indie Games?

2009-09-21T15:02:00.001-04:00

Over on Gamasutra, Jeff Ward asked this question: "Is there money to be made in indie games?" He discussed a few platforms, a couple revenue models, and concluded, basically, that it doesn't look like it with those platforms/models. Acknowledging that he's probably missing something, he ends by asking if it's really so bleak, if maybe there are other models that could work. This is my response....

Money

A good question to start with is: Why do you want to be an indie developer? The next question is: How bad do you want it? What sacrifices are you willing to make?

Jeff used the figure $40,000 per developer in his calculations. $40,000 is NOT much, like he said, especially for someone like me who has 6 kids. But in reality, you can get by on a LOT less than that. We have a monthly budget of $100 for household items, including formula, a few food items, shampoo, etc. We buy dry beans, wheat, oatmeal, cooking oil, rice, honey, sugar, and salt in bulk. Raise a big garden in the summer and can a bunch, and that will supply veggies year-round. People lived for thousands of years before grocery stores and on-demand fresh food were "invented". We moved to the country and bought a home on several acres of land for a fraction of what our suburban home costed us. We have high-speed internet, and that's all we need to make games.

We don't have health insurance yet, and that's not something we can do without forever, but if it means getting your indie studio started, are you willing to make the cut?

How bad do you want it?

I'm tired of eating beans and oatmeal. Having grown up in the suburbs, I miss having things around to go out and do. Jeff's post demonstrated why cutting costs is so important: it can be really hard to bring in money. The less money you need, the more quickly you can become independent.

Opportunity

It is my opinion that there has never existed a greater time to be an indie developer than right now. Tomorrow will be better, but so far today is the best yet. Everyday, the tools we need are getting better and cheaper; the distribution channels are getting better and cheaper; the market is evolving and becoming more and more conducive to indie development.

There are 2 trends in particular, driven by the internet, that are beginning to emerge in society at large that are making the biggest difference for us. First, big corporations are a liability. They can't move quickly. They can't react quickly. They can't innovate. Some can better than others, sure, but most can't. We indies can't compete with big corporations in the market they are designed to dominate. But we can go where they can't. Because of the internet, we can tap into and find markets that are new or previously hidden.

The second trend is the death of the middleman. Retail stores are more and more irrelevant. Are they still a significant source of revenue for big companies? Of course. But they're on the way out. We indies don't need them. The rising generation doesn't care if their fun comes from the store down the road or the store they type in. It's the same. Actually, it's not the same. The store online is easier and faster.

Publishers are becoming irrelevant. They're a long way from actual death, but they're past their prime. They're becoming obsolete. Publishers used to be important for 2 things: manufacturing (which we don't need anymore) and advertising (which doesn't work anymore). The only thing they have left to offer developers is money, and if you take it, you're suddenly not so independent any more.

One middleman that is relatively healthy right now is the internet portal. The internet enables global competition that keeps any single portal from being very big, from a market perspective. A single portal may have millions of players a month and may make millions of dollars a month, but it's just a single player in a huge playing field, no more than small fraction of the market share. Portals talk big and demand big cuts, but they're nobodies. As entrepreneurs develop new technologies to make filtering the noise of the internet easier, portals will die too.*

Console makers are middlemen, but they're also platforms, so they're a little different. They are big corporations designed for working with big corporation developers. They'll keep making new consoles every few years, and they'll continue to sell, but we'll never need them, just like we don't need them now. We have open platforms with cheaper tools, no middlemen, and zero distribution costs. Console makers will make their platforms more indie friendly once they realize what they're losing with their current policies.

A New Paradigm

Jeff Ward is right that the revenue models that are industry standard don't work so well for indies. There are many great games that don't become hits, only because they didn't get the chance. The right person needs to see it at the right time and pass it on to the right people for the word to spread to the right places for people at large to hear about it. As technology improves, more games will have that chance. Eventually, every good idea will find an audience. We're not there yet, but it's coming.

Flash portals are currently the best tool we've found for getting our game in front of people. People go to portals and play many games. There are thousands of new game out every month. Many portals have ratings that allow good games to float to the top. Good flash games spread virally, as web masters copy them from other portals. It's working great for us. We sell a downloadable premium version via upsell ads in the flash game. We use Adobe AIR for the download version, so it's exactly the same code base and assets as the browser version. Cheap to make, cheap to distribute. We continue to make more than we need to pay the bills a year after release. We recently got raises. We have 9 months of salary in the bank. We've paid contractors for music and story for our next game. It's building. Pretty soon we won't have to eat beans every night. We haven't had a huge hit, only modest sales. Our next game won't have to be a huge hit either for us to continue doing what we love and maybe even get health insurance.

I'm sure there are other models that work, and I'm sure even more will be discovered soon. The Industrial Revolution brought us the "bigger is better" mindset. The Information Revolution is changing that. We have more opportunity than ever before, and it's only getting better. We just need to think in new ways, to look at the world through new glasses.

How bad do you want it?

* I don't mean portals will actually go out of business. They'll just be forced to charge a reasonable fee for the eyeballs they attract. Their inflated egos will die. They'll recognize that they are actually small fish in a huge sea. (Any relation between that metaphor and any existing portal is purely coincidental. I don't mean to single out any one portal in particular.)

Just Do It

2009-09-21T15:01:00.003-04:00

I just finished reading Tadhg Kelly's post entitled Make Your Own Games on his Gamasutra blog. I think it's an interesting article that rings true with me personally. Tadgh used a music analogy to illustrate his point: if you really want to be a creative director in the industry, your best bet is to start a band rather than work in an orchestra. In addition to correcting some musical errors (yes, we love the internet), the commentors raised some other points that compel me to write a response.

There are 3 issues I want to discuss: creativity in an indie studio vs. a large company, the value of large-company experience, and opportunity within the game industry at large.

Creativity

In any game development project, there needs to be clear, centralized creative direction. In an orchestra, individual musicians have to keep within their well-defined boundaries. Individual varition of tempo or pitch will ruin the music. That's necessary in a development team as well. Game rules and behavior need to be consistent. Art needs to be consistent. Whether the creative direction comes from an individual (like Will Wright) or a committee (like Valve), all developers must conform to the vision laid out by the designer(s).

Because of the cost of developing AAA titles, game companies are understandably selective of which creative opinions they fund. These companies tend to stick with designers that are well-known and proven. Tadhg made the point that landing a position as the creative director for one of these companies is not likely to ever happen to you. Most people would probably agree with that.

While it is possible for exceptional talent to rise to the top, most people are not exceptional. But that said, you don't have to be exceptional to design an awesome game. You only have to be exceptional to design an awesome game funded by an existing large company.

You can be the creative director of a game development team NOW by starting your own.

Large-Company Experience

It is a common belief among many in the industry that working a job as a developer with a large studio is a necessary prerequisite to starting your own studio. I agree that it's possible to learn skills as an employee working within the necessary “orchestral” constraints of a large company that will help you if you decide to go out on your own. However, I don't see that as necessary.

I have two reasons. First, you can learn those same skills on your own. Being an employee requires mostly technical skills to execute the vision of another person. Technical skills can be self-taught and are generally applicable to whatever game you might be working on. I would argue that the only thing you can only learn as an employee is how it feels to be an employee. There's nothing wrong with liking it. You just can't know what it feels like until you've done it. Perhaps getting a job to learn THAT is a push you need to get out on your own.

Second, independent game development requires skills that can't be learned as an employee. You can't swim by reading a book, and you can't experience the exhiliration of shipping a title that is your own creative brain child unless you do it. When you're working on something that you are truly passionate about, you can learn new things at an incredible rate and accomplish things you always thought were impossible.

Of course, you can be a passionate employee and be amazingly productive and thoroughly love your job. That's awesome if you do that. My post is targeted at those who want to do more than their current job allows. You don't have to get a job in the industry before setting out on your own. If you're short on cash, the economically wise strategy might involve a day job of some kind, but the really valuable learning that will help you make your dreams come true will be happening in your own project, not at work.

Opportunity

I think the most disturbing thing I read in the comments was a sentiment expressed by B N: “In my opinion your friend is just born at the worst possible time to be a game developer. Too late to easily get famous for creating just about anything, and too early to be able to easily be creative on their own.” Others agreed with him. Since they sounded sincere, I want to say a few words on the subject.

B N argued that in the beginning of game development, creativity was easy, because all ideas were new, but making games was technically hard, because tools and technology were so bad. It was from this era that our current big name, famous developers arose. Therefore, it was easy to “get famous for creating just about anything.” All you had to do was manage to create something.

In the mid-'80s, I was first introduced to computer gaming by my dad, who bought a Commodore 64. One day, he brought home a huge box of floppy disks from a friend at work. These disks contained games (turns out they were pirated games, but we had no idea what that meant back then). There were at least 100 games in that box. I tried pretty much all of them. I only liked a few.

It is true that we have relatively few famous game designers and that they did arise from these early years of video gaming. But they didn't do it without competition. Many developers were technically able to create games, but only a few were really good at game design. These designers have continued to make games, and their games keep pace with technology and continue to be better than most games available today. If their success was only due to lack of competition, then better designers would have arisen and replaced them already in the extremely cometitive industry we have today. Will Wright is still making games, and they're still good games, and they continue to get better.

B N observed that improvements in technology continue to lower the bar of entry. Since the bar continues to get lower and since it's not low enough yet to make game development “easy,” the rising generations will have an advantage over us, since they'll have better tools. Therefore, we, the current generation, are at a disadvantage.

Imagine a world where the cost of video game development is zero. Basically, there would be a tool which would turn your imagination into a video game you could play and distribute instantly, and it was free for everyone. That would be the ultimate game designer's dream, right?

Now imagine being a gamer looking for a new game to play. All games are technically perfect, differing only in game, visual, and sound design. Why would you choose one over another? It's more fun and engaging than another. You like the artistic expression better. Whatever it is you prefer in a game, someone had to do a better job of designing than the rest for you to prefer his or her game.

One fundamental truth has been proven in the game industry time and time again: game design matters more than technology. Game design will never be easy. Since tools are cheaper and more powerful than ever before, it's the best time to be a game developer there ever was. We have an advantage over the rising generations, because we're more experienced with game design. Those who take the torch from Will Wright and Miyamoto won't be those who were just lucky enough to be born later than us. They will be game designers that have honed their craft and sharpened their skills through years of experience gained by actually designing games, not by implementing the visions of other designers.

Technology has already reached the point where aspiring game designers can use existing tools to create, market, sell, and otherwise make a living off of your own video games. The only thing stopping you is fear. That fear is fueled by people who say you have to have a job first, or it's a bad time to be a game developer, or it's a bad time to start a business, or anything else. The best time to follow your dream and get to work on your own project is right now.

Flash CS4 and Large Projects

2009-09-21T15:00:00.003-04:00

Over on Jobe Makar's blog, he posted about a bug with Flash CS3 and CS4 which prevents the Flash IDE from being able to compile large projects. Adobe spent a lot of time and effort working with him to resolve the issue, and for them it's fixed, but unfortunately the problem is not completely gone.

Background

Here at Gabob, we've had a long history with this bug (the "invisible ceiling"), which has existed since at least Flash 8, when we first started using Flash in the Spring of 2007. After running into it with our first non-game project, we decided to reevaluate our company's direction and go a different route (which was good).

In July of 2008 we hit the ceiling again during the final stages of development for our first big Flash game, Now Boarding. After scouring the internet and finding nothing, we called Adobe, and their official answer was to split the project into more than one swf.

After a week of completely restructuring our project, I split it into 3 swfs, and we were able to move forward from there. Because the game's original design was not particularly suited to splitting the code up, one of the swfs had most of the game's code in it. But I had removed enough code and assets for it to build.

Following the split, we finished the game, shipped it, added a bunch more content for our 1.1 release, shipped that, and then wanted to add some more later.

By now it was January 2009 (after Adobe's 11/17 CS4 update), and we finally decided to buy CS4. I bought it, downloaded it, downloaded the updates, installed everything, and I couldn't build the big swf of the 3 Now Boarding swfs. I could still build it in CS3, so I just continued using CS3 for NB work.

We added more content, then CS3 stopped building it. This time, I scoured the internet again and finally found other people with this problem. Using the java heap trick, CS3 and CS4 both built the game. We added more content, a new map, some new little features, some bug fixes, etc. and then we hit the ceiling again. This was using Flash CS4 with the 11/17 update.

Experiments with Flex

All the posts and blogs I could find on the internet about this issue were about the Flash authoring tool. Flex didn't seem to have this problem, or at least no one had run into it that I could find. I figured if I could put all the code into one swf and use Flex Builder to compile it, then I might not have to deal with this problem ever again.

So I downloaded FB3, started up the trial, made a couple test projects to test how I could use Flash CS4 for all the library symbols we had created and keep all the code in a FB3 ActionScript project. I won't go into all the gory details, but the plan was roughly to decouple all library symbols from .as files by renaming all exported symbols in the fla's (I just appended "MC" to the symbol's class name) and then change all the .as files to instantiate the corresponding *MC object and add it as a child. The fla's would be compiled into swc's which FB3 would import and compile into the code project.

After 2 days of tedious code restructuring, I had a final, single swf built by FB3 that had all kinds of problems. I ended up solving most of them, but some inexplicable problems remained. I then spent another day getting rid of the swcs and just loading the swfs built from the fla's dynamically using the Loader object. Loaded dynamically like that, everything worked correctly.

Our game is still 3 swfs, but ALL code is in one, and that one is built by FB3. One of the original 3 swfs contained only trivial symbols (no timeline code, not even multiple frames, just music, sounds, and images), and those worked fine as a swc, so that one is combined with the FB3 AS project as one swf.

Conclusion

While the journey has been extremely painful, I am very happy with how things are working now. Here are some benefits:

- FB3's compiler is so much faster. Since they contain no code, I don't have to rebuild the fla's very often, so now instead of waiting 2 minutes for Flash to compile in order to try out the changes I just made, it only takes a few seconds (literally just a few seconds).

- FB3 is designed for coding. Flash CS4 is not. I still use gvim for most of my work, but FB3 has nice refactoring tools and a profiler (but the profiler does work on any swf, not just FB projects, so I benefited from it even before this last restructuring).

Remaining Issues

1. There is definitely a problem with library symbols imported from swcs. The symbols that don't work when in a swc but DO work when loaded from an external swf have animations and timeline code. Some of them work, some of them don't. Symbols with no animations or timeline code work fine in a swc.

2. Flash CS4 is targeted (I assume) at movie-makers and developers of small games and other small interactive projects. Flex Builder 3 is targeted at developers of RIA's. Both cost $699 (the profiler is in the pro FB version, and that's essential for large projects). The majority (I assume) of developers who target the Flash player only need one of them and just buy the one they need. Developers of large games need both, so we have to spend twice as much. It'd be nice to have both CS4 and FB3 licensed together in a cheaper package. As it stands, CS4 and FB3 together are only $100 less than Unity Pro, which by many (but not all) standards is better for larger-scale game development...and which now has a Windows IDE.

Money is OK

2009-09-21T14:57:00.001-04:00

There’s a general sentiment among many indie game developers that making money is at least a little bit evil. I suppose it’s probably a lot like other “starving artist” mindsets in other media and industries, but whatever the context, I find that idea interesting. Since this blog is about video games, I’ll stick to those here.

In some ways for some people the indie game movement is a rebellion of sorts against the corporate empires that dominate the game industry. We see the games that these companies produce year after year, the money they spend on development, and we are not particularly enthused with what happens when game companies have share holders to please. Those shareholders and various executives usually seem to care more about return on investment and are busy counting the dollars that flow into their accounts.

Indie developers often seem to conclude that in order to stay true to their own ideas and self expression, they can’t go that route, i.e. sell out for money. By that I’m talking about making changes to their games to make them more like what is popular just to grab some dollars.

I agree that doing anything just for the money is greedy. I’m sure there are plenty of high-rolling executives and shareholders that aren’t just in it for the money, but the games that so many of the big corporations release indicate a lot of them are. They’re afraid to take risks because they’re afraid to lose money, and they’re afraid to lose money because ultimately they value the money more than pushing the industry ahead. I do think that’s selfish.

However, I would argue that those indie developers who are unwilling to create products that are popular and thereby make more money are just as selfish. In fact, I would say that their situation is more dangerous because it’s more subtle and is considered by them to be the moral highground.

So how is not making money selfish?

There’s no magic involved when it comes to making money. If you offer a product, service, or idea to another person that they value more than the money you’re asking, then they will give you that money for it. If millions of people buy your game, then you have created a game that millions of people value. You have served them, made their life at least a little bit better in some way. If very few people buy your game, then very few people value what you’ve done, and so you have served very few people.

If your goal is to create your vision and express yourself, then whether your game sells or not, you’ve created your dream. You value it, and you profit from it in non-monetary ways. To say that you don’t want to make money is to say you don’t want to create something that other people will value too. Doesn’t that sound at least a little bit selfish?

Since the only way to make money in a free market is to create something that other people do value, it’s ironic that those big corporate empires can be so selfish and yet create so much value at the same time. Maybe some would argue based on what I’ve written here that they aren’t selfish then. It all depends on why they’re doing what they’re doing. If they’re doing it to maintain their ROI and keep the money flowing, their motive is still selfish. If their motive is to give people what they value, then they’re not—the fact that they’re making money doesn’t change anything at all.