vrijdag 4 februari 2011

game development models

Thanks to digital distribution and social platforms such as Facebook, a lot of new development models have popped up that can earn you a good amount of money. Since I will be financing myself without any income until my first game is finished, I do need a good business plan to earn this money back. Right now, I am considering the following three models (or game types):

  1. Facebook/web games: as Zygna clearly demonstrated, facebook games, even without ads, are a viable way to earn millions. However, their business model is dubious to say the least. I don't like games that give you an advantage over other players if you pay money; I have always opposed this approach in Castle Quest. In order to make a succesful webgame, I would need a different business model. League of Legends has an interesting model, in which they offer part of their content for free, but require that you pay for additional content, without giving a disadvantage to non-paying players: they just have less variety in the heroes they can choose and how to customize them. Another option is to go for a subscription fee, or offer the full package as a one-time buy, just like normal standalone indie games.

    Advantages:
    • Low setup cost: a server is all you need to get going, and you can expand your park or go to cloud services if the need arises.
    • I have a lot of experience with this genre through Castle Quest 1 and 2, as well as a huge fanbase which will immediately jump on a new webgame I develop, giving it a head start.
    • It's easy to reach a huge audience through social networking sites.
    • Games are almost automatically multiplayer, without requiring special effort.

    Disadvantages:
    • For reasons quite unclear to me, people are still very averse to paying for webgames, while they have no problems paying money for standalone games, even though there doesn't have to be a major difference between them anymore in terms of quality. HTML5 Canvas even allows for 3D games played directly in your browser (see the Quake 2 GWT project)! Yet, it seems like, of the three models discussed here, this is the one which is the least predictable in terms of earnings. Will people be willing to pay for your additional content? Who knows?
    • Webgames are by definition asynchronous: this disables a lot of game genres. Every (multiplayer) game which depends on twitch action is not an option.
     
  2. Mobile games: mobile games are obviously a booming market. Success stories abound, with trivially simple and unoriginal games such as Doodle Jump gathering 5 million sales. The altometer, touchscreen and GPS open up new ways of control that were previously unavailable. Money is earned through direct sales of your games on the iPhone and Android markets, and games are often priced very low (below €1). This model lends itself more to simple, yet creative games that can be played for a few minutes and put down again without losing any progress. Most successful mobile games fall into this category.

    Advantages:
    • If your idea is good, you can probably earn quite a lot of money with this. Everything hinges in your idea though; a good, balanced game concept will get you less far than a unique and fun idea.
    • Huge market ready to be explored, and very easy to get your game to your customers.
    • New control methods allow for unparallelled originality. This model is most likely to spawn new genres.

    Disadvantages:
    • Extremely inaccessible industry. If you want to develop for iPhone (and you do want that), there are only a few options. Firstly you can get a macbook and develop on that. Secondly you can install MacOS on your PC or run a virtual machine, and develop from there, but as far as I can read, this is quite a tricky undertaking. Thirdly, you can use one of the cross-compiler tools such as Dragonfire SDK (tried it, WAY too limited), Unity 3D (you're scripting your game), or Adobe Flash. Of these, Flash and Unity 3D are both sensible options for serious projects, but still have quite a large learning curve, as I have no experience with actionscript of C#. If you also want to develop for Android, again Unity and Flash seem to be the only good options you have. Not ideal at all.
    • Some game genres just don't work well on a small screen, or without a mouse. I have played several ports of strategy games on a mobile, and it just doesn't feel right. Basically, you need to avoid clicking buttons repeatedly with the touchscreen, because they feels slow and cumbersome. Any game which requires a repeated hitting of buttons is not a good mobile game.
     
  3. Standalone game: the oldest trick in the book, but it still does the job. Thanks to the digital distribution revolution, publishing a standalone game is as easy as putting it up on a website and placing a paypal button next to it. Distribution platforms such as Steam make it possible to reach huge audiences with minor cost overhead, once your game has been picked up. Popular websites such as TIGSource can help your games reach an enthousiastic audience quickly.

    Advantages:
    • I can develop in C++, which is my language of choice. I also have the most experience with this language, and have compiled and written a huge knowledge and library base over the years. Also, most of my most promising and developed projects at the moment fall into this category.
    • The Independent Games Festival seems heavily biased towards this model. This may be because mobile and webgames are just not on par with standalone games yet, but there's no objective reason for them not to be (besides that those industries are not mature enough yet, maybe). Mobile games are even put into a separate category (but are, theoretically, still eligible for the grand prize). Since the IGF is a very important source of income (through awards) and advertisement (through media attention), this is actually a huge advantage for the standalone game.
    • Developing a standalone game just gives the most freedom in terms of design.

    Disadvantages:
    • Requires the largest allround investment of talent: a standalone game cannot go without proper graphics and sound, for example, while a webgame can.
    • More difficult to prototype, because it always requires substantial effort to prototype something using SDL or OpenGL.
    • Multiplayer is tricky, hard to implement and can be quite expensive. Between dedicated and central server architectures, no one choice is the best. Dedicated servers require a minimum popularity for the game so that people set up their own servers. A central server can cost a substantial amount of money right from the get-go.
Right now, I am leaning towards either standalone or webgame. But this might change considerably in the following months, as I experiment with the different models. I will also document these experiments here as they progress.

Geen opmerkingen:

Een reactie plaatsen