Why “Free to Play” is bad for Indie Game Developers

On January 9, 2014, in idevblogaday, by Steffen Itterheim

The “Free to Play” business model is bad for us independent game developers. If we try to implement it, that is.

Let me first explain what a typical (casual, mobile) free to play game works like. The type of game that works so well on mobile, revenue-wise, that it’s all the rave and even Indies are tempted or have tried to follow down that path.

A typical, casual free to play mobile game

As you launch the app you’re presented with colorful, charming visual imagery and characters with unnaturally large eyes. This is visual appeal 101 if you’re aware of the composition of an art style that provokes a heartfelt, warming charm. Like a meadow in full bloom it appeals to all audiences. Like a meadow in full bloom it is nothing special if you know when and where to find it.

Typically you aren’t given any choice but to start playing the game. The rules are extremely simple at the start, the interaction understood in a split second and the early levels are designed for player success. It’s a series of visual and audible successes and before you begin to truly enjoy it, the level is complete. And that is intentional.

As you progress in the early levels, they all seem over far too quickly as you’re introduced to more game mechanics. This is what gets players hooked, the simple fact that they could keep playing and enjoying themselves but the game always stops them short of getting in the zone. This is the stage where the player is conditioned to advance to level after level.

In a sense, the player isn’t really “free to play” as he or she wants to.

Continue reading »

Tagged with:  
Tagged with:  

KoboldTouch: New Plans & Pricing, and FAQ

On February 14, 2013, in KoboldTouch, by Steffen Itterheim

I added two additional Plans to KoboldTouch:

  • NEW: 1-Month Support & Updates: $19.95
  • 3-Months Support & Updates: $39.95 (same as before)
  • NEW: 12-Months Support & Updates: $119.95 (4 quarters for the price of 3)

All plans are now non-recurring / not auto-renewing. No more subscription plans.

The 1-Month plan is for trying out KoboldTouch, or getting or updating it cheaply. Lowering the barrier of entry. I want to increase the user base to gather more feedback, requests and suggestions.

The 12-Month plan is for supporters and early adopters who are willing to invest into KoboldTouch while saving money in the long run.

Note: You can continue using and publishing apps built with KoboldTouch even after your support & updates plan has expired.

Learn more about KoboldTouch and sign up.

Target Audience

At this point KoboldTouch isn’t for everyone (yet). I decided to narrow the focus to the type of users I seem to have convinced and the type of users I like to work with and attract more. I summed it up like so:

KoboldTouch is a custom-built game engine for demanding iOS & Mac OS X developers.

Continue reading »

KoboldTouch now available for less!

On January 8, 2013, in KoboldTouch, by Steffen Itterheim

koboldtouch_softwareboxopentop_250x250While I did the year’s end reports on practically everything, I also ran the numbers on KoboldTouch.

Now that it’s been available for just over two months, I decided to make the $39.95 plan available for everyone which was previously only available to Learn Cocos2D 2 book owners. This plan replaces the $44.95 plan.

The “3-months only” plan is now also down from $44.95 to $39.95.

Check out KoboldTouch here.

Please take the KoboldTouch survey. I highly appreciate your feedback, thank you!

With actual sales figures of the past two months I could see a clear pattern:

Continue reading »

Tagged with:  

The 10 Golden Rules for a Donate Button

On March 13, 2012, in Opinion, by Steffen Itterheim

This is a follow-up post to my Software Developer’s Guide to the Donation Button post, a rather lengthy one at that. To make the key points easily digestible I offer you my 10 Golden Rules for Donate Buttons which should guide potential donees (those receiving donations) whether they should be using a Donate Button or not.

The rules don’t leave a lot of room for acceptable uses of a Donate Button, this is on purpose.

  1. If you don’t need donations, don’t ask for them.
  2. If you own a business, don’t ask for donations for anything in the same business domain, period.
  3. If you greatly benefit from your free work in other ways (traffic, marketing, paid work, etc.), stop accepting donations.
  4. If you can’t explain exactly how donations help your work, don’t even imply that they do.
  5. If you just want to earn some money, sell something. Anything.
  6. If receiving money is a source of motivation for you, donations will be counterproductive.
  7. If you want your work to be appreciated, accept physical gifts, not monetary donations.
  8. Don’t beg for donations and don’t appeal to your user’s bad conscience. No free project that deserves to survive needs money that badly.
  9. Don’t expect or demand anyone to donate, ever. Not even Mr./Ms. Got-Rich-From-Your-Work. You decided to give your stuff away for free, remember?
  10. Every new Donate button makes all others a little less attractive, and less beneficial overall. The purpose of your Donate button should far outweigh its detrimental effect on others.

Continue reading »

Cocos2D is a Registered Trademark

On December 31, 2010, in cocos2d, by Steffen Itterheim

Cocos2D was filed as registered trademark on July 27th and published Dec 17th 2010. The trademark includes the phrase “cocos2d” as well as the Cocos2D logo, which is described as follows:

The mark consists of COCOS2D appearing on a black rectangular background, the term COCOS appears in white letters and 2D appears in orange letters, above the wording is a brown coconut with black and white eyes appearing on an orange rectangular background.

The color(s) orange, brown, black, white is/are claimed as a feature of the mark.

The translation “coconut” was also given as the english translation for “cocos”.

You can review the supplied documents here which contain additional details.

As far as I can tell, the trademark was filed only in the US. But it may be in review for other countries.

Thanks to MagnetiCat for bringing this to my attention.

What it means

I’m not a lawyer, so take this with a lot of salt.

Specifically to those doing business in the United States (where the trademark was filed) it means that you should refrain from offering or promoting services with the Cocos2D name or logo in it, otherwise you are subject to legal proceedings for trademark infringement. Since the trademark is currently registered only in the United States, legal prosecution will be difficult (not to mention costly) in other countries. As far as I know, trademark infringement claims must be filed in the country that an individual or company is doing business in, eg. where they have an office or employ a company representative.

Infringement may occur when one party, the “infringer”, uses a trademark which is identical or confusingly similar to a trademark owned by another party, in relation to products or services which are identical or similar to the products or services which the registration covers.

This means games using the Cocos2D logo should be fine, but game engines, and addon products to the Cocos2D game engine might be infringing the trademark if they continued to use the logo and name. Especially if “there is a likelihood of confusion that consumers will believe the products or services originated from the trademark owner”. Any Cocos2D port that wasn’t authorized and where the use of the Cocos2D name and logo are not consensual may be subject to legal action. It’s likely that, if they aren’t already, that development of Cocos2D engine ports and addon products now need to be strictly permitted, or refrain from using the Cocos2D trademark entirely.

As a website owner, you may also want to add a “not affiliated with or endorsed by” disclaimer on websites carrying the Cocos2D name or logo if you benefit from the trademark in any way (eg traffic) or if your content may be confused as originating from the trademark owner.

Note also that the use of a registered trademark must be controlled and enforced, otherwise one risks losing the trademark. So we can not expect things to just go on without change, because without controlling and enforcing the trademark there will be no trademark. This is troubling.

On the other hand, there’s the fair use doctrine in the United States, and furthermore there is the allowed Nominative Use of a trademark. Nominative use of a trademark is deemed if “The user does nothing to suggest sponsorship or endorsement by the trademark holder. This applies even if the nominative use is commercial.” Hence the popular “no affiliation or endorsement” legal disclaimers.

I’m looking forward to an official statement about what will be seen as trademark infringement as well as what the accepted uses of the Cocos2D trademark are. The trademark registration brings with it a legal confusion that certainly the Indie game development community doesn’t want or need, especially not from a game engine that’s supposed to be “free and open source”.

What we need now is a Trademark FAQ like the one for Joomla to clarify the relevant issues.


Note: I’ve been asked if it’s necessary to add the (R) symbol to every use of Cocos2D or its logo. Answers.com says no.

TexturePacker goes GUI!

On October 31, 2010, in Marketing, tools, by Steffen Itterheim

The previously command-line-only TexturePacker tool now has a nice GUI. It’s called the “Pro” version and for a reason. So far, I’ve been using Zwoptex for creating Texture Atlases, but I’ll certainly give TexturePacker Pro a try.

At first glance, what I liked was that it told me when the Texture Atlas was “full”, eg. not all sprites could fit into that Texture Atlas. And the always present list of image filenames on the right side is a welcome feature. Although Zwoptex does have this list as well, it’s almost rendered useless because it’s a seperate view option.

Zwoptex’ price has changed since I checked last time, it’s now at only $14.95. TexturePacker Pro costs $17.95, it’s command line version $9.95 and the upgrade from command line to Pro is $7,95, so you’re saving a whopping $0.05! :)

A couple words on pricing

I find both tools are underselling themselves. Zwoptex was initially at $24.95 and even that price seemed “cheap” to me, given how much trouble it saved me and how much faster and more memory efficient it made my projects. I would say that a price range of $30 to $50 would be more than fair for those tools. I can imagine that the TexturePacker command line version at $9.95 and now the Pro version probably forced Zwoptex to adjust its price.

Problem is: this isn’t a market where people choose their tool based on a $3 price difference. Also, it decreases margins for upgrade prices, with TexturePacker upgrade already below $10. Those low-end prices incur a proportionally large amount of transaction fees, paid to the eCommerce vendor, making them less viable. Since this is also not a mass market, but a niche, it would be wiser if both upgraded their prices back to reasonable regions, around or above $30.

Likewise, Particle Designer is also absolutely undervalued at $7.99. Those low prices undercut the value in tools, and make tool development less and less attractive than it already is. And if anything, cocos2d and the other engines need one thing above all else: tools. And good ones!

Be it Ricardos mysterious “world editor” or the Physics + Tilemap IDE (website) or the other game editing tools currently being worked on – if any one of them is being released as a commercial product but sold for less than $30, I’m going to be very mad at you! If it’s less than $60 I’ll still be mad at you, not very, but still mad.

Rant

Seriously, this isn’t the App Store! It’s developers you’re selling to, and they do value useful tools. Just because cocos2d is free doesn’t mean that all tools surrounding it need to be cheap (or free for that matter). Take Sprite Manager 2 for example. It sells for $75 (per seat!) and isn’t all that different from Zwoptex or TexturePacker Pro. If it were a standalone app it would probably pale in comparison! You might argue that SM2 is for Unity, and their developers are less price sensitive – I don’t think so, and some are even more price sensitive because they just made that huge investment in the first place.

In general you could say that those developers who invest several hundred $$ into a game engine (and toolset) are simply more serious about game development. You do have those enthusiasts working with cocos2d as well, but they’re probably outnumbered by a lot of hobbyists and “I’ll give it a try” kind of people who simply join because of the fun involved, and because the only investment in cocos2d is time and they got plenty of that. The question is: do you want to be kind to the hobbyists, or do you want to build a sustainable business? Plus, Zwoptex and Texturer Packer are also being used by Corona developers.

Now you may also be arguing that a cheaper price allows more developers to enjoy the tools and we’re a friendly bunch and not a commercial, greedy corporation. Sure. But those prices do devalue everyone’s tools, so if anyone wanted to build a tool that takes maybe not just 1-2 months to build (initially), but maybe 4-6 months or more before it’s going to be useful, those price points are not very encouraging to start such a project. That doesn’t mean it won’t happen, but I do know that those people who could pull this off, are generally terrible at doing business. And easily influenced by comparable prices, punching a few numbers, and then getting on with their next train of thought which probably involves solving an obscure programming problem.

And the kind of tool that needs this time investment is the one I’ve been looking forward to since I first started working with cocos2d in May 2009. Back at the time I was convinced that by the end of 2009 cocos2d would be having a game editor or at least something to build the GUI and screens with. I wished for a fully-fledged, professional game level editor, with a physics editor, sprite animation builder, asset management, and whatever else you can dream of.

Now, if that ever happened, it shouldn’t cost less than $100. If you can provide killer features like Box2D integration or scripting game logic, ask twice as much. And offer Lite and Pro versions with a variety of feature sets to make the most out of what developers need and what they are willing to pay extra for niche, but very useful features if you need them.

Tagged with:  
Page 1 of 212