Monday, November 30, 2009
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....
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. 
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 , and our business is benefiting from having two very different, complementary co-founders.
 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.
 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.
 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.
Monday, November 9, 2009
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!
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.
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.
Tuesday, October 27, 2009
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?"
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.
Wednesday, October 14, 2009
Thursday, October 8, 2009
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.
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.
Threats to portals
Like all middlemen, portals can only stay in business if their customers would rather pay them  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.
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.
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.
The real value a portal provides is not delivery, but filtering information. 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, 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.
- NOTES -
 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.
 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.
 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.
 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.
 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.
Monday, September 28, 2009
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.
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).
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.
Monday, September 21, 2009
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.
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.
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.
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.
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....
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.
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.)
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.
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.
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.
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.
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.
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).
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.
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.