Showing posts with label indiegame. Show all posts
Showing posts with label indiegame. Show all posts

Sunday, June 28, 2015

Unity is not Free

As I work towards getting my new game Word Monsters! published on the various mobile app stores, I'm mulling over the decision I made to go with Unity for this game.

Update 2: I contacted Unity's sales manager in Australia for clarification and there are a couple of things that makes this picture better than the scary thing it seems at first blush.  If you have questions, contact them via the Unity website: they're very helpful!  (Thanks Patrick).  Also, I should clarify that for hobbyists who NEVER really plan to make a living out of Unity games then the issues here may also not really be a problem.  If like me you're a serious indie developer who spends their days writing games and has to make a living out of it, especially if you do so through a Pty Ltd company then READ THE EULA and inform yourself.  You also might want to consider getting your lawyer to look at it: I am not a lawyer and this is not legal advice.

The Elephant in the Room
Its more and more obvious to me that the naive idea that a lot of developers go with around Unity - that its "free" - is completely wrong, and a bit dangerous.  For me the cost is around $6k by the time I convert into my local currency.  Let's break this down.

Non-Dollar Costs


First let's look at a couple of non-monetary costs.  I have noticed that load times are longer than native, and by an amount that might cause some players to drop off.  Also app bundle sizes are large: I'm struggling to get the size down.  I'm sure there's lots of things I can do.  I believe in "premature optimisation is bad" and as a result I'm looking to these things as I get closer to publishing, but its a real issue.  This could translate into a monetary cost if potential players are put off from the game - some players just delete a game if it takes ages to download or start-up.

Another cost:  calling out to iOS platforms like Social and Store is a pain from Unity.  Same for Android API's.  You need to use various wonky plugins from 3rd parties, and those might not play well with your existing plugins, and can add to your load time/app size headaches.

Is Unity free?


But the elephant in the room is that people treat Unity as "Free" - its not.  

I'm not saying its not worth what they're asking for it: around $6k AUD.  Its got amazing power and is a very feature-ful product.  Compared to other large software suites like the various 3D editors, like Adobe's products and other creative industry software its reasonably priced.

But wait, you say $6,000?  Unity Pro is only $1500, and you can pay a subscription of only $75 a month!

And then you say:
Well, it is $0, as long as you earn less that $100,000 - and wouldn't that be a nice problem to have.  Yeah, amirite?  Grin!
Not so fast.  OK - let's say I want to try to eke out a living making games, and I think "OK, lets meet Unity's conditions for the Personal Edition".  To do that I have to make less than $100,000 in a given financial year, so July 2014 - June 2015 for example.  But that is gross revenue, across all the Unity titles I have in the store, for my entity.  In my case the "entity" is Smithsoft, my company.  

The $100,000 is gross revenue.  Go and read the licensing conditions.  They're well written and worth a read.  So Unity is coming in to check on you before you get to deduct any of your costs.

How Much Can I Make Before Paying for Unity?

UPDATE 1: After a discussion with some game dev colleagues this first paragraph looks to be wrong.  If you don't receive the money in your bank account then it doesn't count as revenue.  So if the App Store takes it cut before passing on the rest to you, then "revenue" for the purposes of Unity's $100k calculation may be more forgiving.  My advice: check with your lawyer or accountant first.

UPDATE 2: The following paragraphs in this section have been reworded after clarification from Unity that "revenue" does mean money remitted to your bank account from, for example, the App Store.  But while you do get to effectively deduct App Store costs, you don't get to factor in all the other costs of developing the game.

Let's say that in a financial year after Apple takes its cut I get a smidgin under the Unity cut-off of $100,000USD as revenue in my bank account from sales of my premium iOS game.  That's around $130k AUD.

Out of that I have to pay for

  • contract developers 
  • artwork/artists/animators/modellers
  • voice acting, musicians
  • pre-made assets costs / Unity assets store purchases
  • work-space rentals
  • software costs
  • registering domains & running up a website
  • accountants
  • promotional video
  • advertising...
  • on and on it goes

anything else that it cost me to build my game.  There's a ton of hidden costs.

For some of us we do our own coding, art and so on.  Great, right - don't need no stinking contract developers.  But doing it yourself doesn't mean its free, as our time has value.  I could be working elsewhere as a Software Engineer at whatever the going rate is.  If instead you're working full-time for 6 months on no pay, that has a cost.  If you don't know how much it really costs to make games do some research, its not cheap.  Let's say its a casual game with one person full-time, and a few casual contractors bought in as needed to do art, etc, and took 6 months from go to whoa.  Total cost to make the game, conservatively $AUD80k.

Here at River City Labs over the past 3 years I have made my own game, and worked alongside teams of developers working on at least a dozen other titles to go to market.  I think $AUD80k is pretty fair on average for a casual game over 6 months right now.

Now out of the $130k I'm left with $AUD50,000 in my pocket - Software Engineers make twice that in a regular paying job.   And out of that I have to pay the Australian Tax Office its cut.  I'm not saying its a bad lurk, and it would be great to be that successful.

All I'm saying is that "making $100,000 a year" is not a path to fame and fortune that it sounds like.  By the time you factor in the costs of making the game its barely a living wage if you are trying to make a living so you can actually be a full-time game developer.  What I'm saying is that that figure is out of your gross revenue.  Do your sums first before you plan to "be successful" by sneaking in under the Unity revenue watershed.

If you want to take home enough money to actually pay rent, and put food on your table at home, then your gross revenue is going to be more like $200k AUD minimum so that by the time you pay your game dev bills you actually have something left to pay for food.

After Flappy Bird and A Dark Room it seems like you can make some game on zero budget but make out like a bandit on the App Store.  For every Flappy Bird there's millions of low-budget, low-quality games on the stores that languish and never make a cent.  You'd be better off packing grocery shelves for that time, and spending the money on a Lotto ticket for the chance you have to get paid that way.

The reality is that games with modest production values and good development teams behind them are the ones that succeed, and those games cost to build.

So Let's Buy Unity


Or, you can make more than $100k revenue, and go and buy Unity Pro.  I guess you can do that after you make the $100k threshold right?  Be careful - you can't use non-Pro stuff alongside the Pro stuff. There's caveats.  Read the license.  But anyway, we're assuming we're going to buy it.

Update 2: I contacted the Unity guys and they clarified that the intent of the "no mixing Pro and non-Pro" clause is just to make sure that everyone on the team doing development does have the Pro license.  You are totally fine to switch to Pro later in your games cycle.

So how much is Unity?  Let's assume you require Unity Pro because you broke through the $100,000 gross revenue watershed.  Further lets assume you got Unity because you thought it was so awesome that Unity lets you publish to both iOS and Android, and that's what you did.  Well you need to get:

  • Unity Pro - $US1500, 
  • Unity iOS Pro - $US1500, and 
  • Unity Android Pro - $US1500.  

And the costs add to a total of $4500 US - which is $5857.35 in Australian dollars.  That's the lion's share of $6k depending on exchange rate.  Before you click that buy button check what your local spend is going to convert to.

If I buy Unity 5 right now, for around $US4.5k, I get to keep and use it for ever.  Usually that's what buy means.  Nice.  If I'm grossing $US100k then that $US4,500 is not so bad.

But when Unity 6 comes along, all bets are off and I have to buy it all over again.  Note that the cost to upgrade from a previous version is cheaper.  But you do have to get your credit card out again.  Maybe the subscription option is looking good?

What About Renting it?


If I go the rental route I pay $75 a month, for each of the 3 items, and that is a total of $225 a month, and when Unity 6 comes out I just start subscribing to that.  Great.

And as soon as I stop paying I don't have Unity Pro any more.  Its like a spring-loaded trap if you don't set up your payments right.  I don't like that.  I'd prefer to buy up front and know I'm clear, but its a pain that I have to re-buy if I want the new hotness in later releases.

Is it really a trap?  In fact is it really so bad, if I don't get Pro and kind of fudge around that fact?  Nudge, nudge, wink, wink.

Unity Knows...


First thing you should know is this phrase from the license:
...may send data to Unity to: (a) check for Software updates; (b) provide aggregated usage statistics of your use of the Software and the use of your Licensee Content by end users; (c) provide analytics and advertising services; and (d) validate license keys
So how does Unity know that you're making more than $100,000 from your Unity games?  By having monitoring code in your games.  
  • You are required to have that code in there
  • you can't (legally) remove or circumvent it, and 
  • you are required to inform your players that its there as part of the privacy policy
Update 2:  If you get Pro then you have the option to turn off Unity's monitoring, and if you do that then there's no privacy policy requirement to inform your players.  Obviously if you have your own analytics you should check the privacy laws in your country.

So how scary could Unity's lawyers really be?  I don't know - and I don't want to find out.  The prospect of even some sort of shadow coming down over my games which are published on the Play Store or App Store is just terrifying.  I love being a game developer.  Unity's lawyers contact the App & Play Stores and say there's an issue with my games - what happens to my account on those stores?  That could be game development over unless I change my name, move countries type stuff.

Not to mention that being non-compliant with licensing means that if I decide to sell my IP, or my company which holds the games, or seek investment based on a stake in my company, then due diligence is going to close over my limbs like a bear-trap.  Here's me waiting for my nice check for Activision buying my company, and instead I get served a writ for failing to own everything I said I owned.

Due Diligence Bug-Bear


If you work for a company and expose your employer to due diligence issues you could be in trouble personally, depending on what your employment contract says, and what kind of shares you have.  If you've never heard of due diligence before, go and Google it - know about it before it bites you.

As a little guy, you might think "its no problem - none of that could ever happen to me".  Maybe.  If you want to stay a little guy.  Maybe Dong Nguyen, the author of Flappy Bird thought like that.  Or insert any other game dev success story.

And success only to have it all taken away by some legal nightmare is almost worse than no success at all, in my view - you might lose your reputation as well.

All I'm saying is if you actually want to succeed in game development you don't just brush aside legal concerns about licensing and think you'll solve them down the track.

Things that make you go Hmmm


So coming back full-circle - what are the options then?  Do we have to pay thousands for Unity if we want to go to iOS and Android?

Update 2:  Its possible to wait until some later time in your games development cycle, such as when it looks like you will make over $100,000USD and then buy Unity Pro.  The fact that you can still pocket say $50k for a years revenue without triggering the "Unity Pro" condition makes it viable to take the risk.  But in my opinion unless you're a hobbyist with no serious intent to try to be a full-time indie game developer, you REALLY want to read up all the Unity licensing, get advice, make sure you budget for that $6000 spend and be ready with your credit card for that day.

I'm wondering if it makes more sense to ship the iOS game using native frameworks like Sprite Kit.  If it makes any money on iOS, take the $6000 you saved by not buying Unity and get someone on UpWork to build the Android port, using for example Cocos2D-X or libGDX.

In the end the goals & drivers you might have, including targeted platforms, existing team skill-sets and so on are what dictates what you choose.  Unity is definitely worth the money, but just remember - its not free, so don't decide to go for Unity thinking its free.

Wednesday, October 29, 2014

Space Bot Alpha

For the past six months I've been working on a touch device game called Space Bot Alpha.  Here's a video.

Late on Wednesday evening I pushed the final release candidate binary to Apple's App Store review pipeline.  If you want to check out the game I'm expecting it will go live around November 5th.  Doing a review, article or LetsPlay?  Ping me on Twitter and I can get you a access.

Whoa. What a totally weird feeling.

After 2013 and working really hard on Ethex2080 only to realise that I'd need a team of 2-3 people as well as me, and another 12 months to get it done, this year has been all about getting my feet on the ground and shipping a video game.

Now, I proved to myself I could do it, and even if your tastes in games are not aligned to space ships and strategy/puzzlers I hope you'll agree with me that the level of polish and completeness is pretty good for a solo indie developer's first published game.  I'm reaching around and patting myself on my back right now.  But its also weird after pushing so hard for so long to break thru and ship this thing.

Yes, I'm really pretty happy with how Space Bot Alpha has turned out, and although its the end of this stage of the Space Bot Alpha story, as the plucky little guy still has lots of work yet to go with Android releases, level packs and other stuff.  So no relaxing just yet.

But I have to say I'm really excited about what this uncorks for me going forward.  Pushing a build isn't everything: I know that.  If no-one likes the game, and no-one plays it then I am going to have to seriously rethink what I'm doing.  But I did a lot of testing and I've seen people have fun with it.  I've even had some fun with it myself which is pretty amazing considering the times I wanted to just throw my dev tablet across the room in frustration at some stupid bug.  I think this, right now, will be the moment I look back on as when my game development career kicked in to high gear.

In December I'm heading to the UK for a holiday and that'll give me a chance to reset my head.  In 2015 I'm planning to make a new game.  In October 2015 at PAX and GCAP I'm going to turn up there and belong; I'm going to have 2 published games under my belt.

Wanna know more about that new game?  Subscribe here and I'll dump some concepts in coming weeks and months.

In the mean time thanks to everyone that was so supportive and appeared just when I was on the ragged edge to say some nice things and keep me going.  I want to give a particular shout-out to my friends at Disparity Games, Nic and Jason and the rest of the Stark clan; and also +Cameron Owen and +James Bowling of AttractMode Games for making me feel like a real game developer.

And, hey - what are you doing just sitting there!  Go check out Space Bot Alpha!

Friday, July 25, 2014

Testing Games

How do you go about testing a game?  What makes a great game tester?  What is different about trying to improve the quality of a game compared to other software?  How can game studios large and small ship titles that turn out to have serious bugs?  Don't they test properly?


These are serious questions both for game developers at the indie level like me, and for larger organisations; but also for the game playing public spending their good coin on titles they expect to actually work.  The screenshot above showing a main character model collapsing under what looks like broken physics/ragdoll is from a video posted by dubesor on the Steam Community site, who found a number of pretty hilarious and also quite serious bugs in the game "Cognition" by Phoenix Online Studios.  I recommend checking out dubesor's post for the video.

I played Cognition on iPad and as soon as I started playing I ran into bugs - Erica's gun turned into a big black square, behaviour consistent with a missing sprite for a billboard, right at the beginning of the game.  Cognition was a great game with some innovative ideas, and beautiful realisations in artwork, animation and dialog.  Yet I found bugs, and others found different bugs, so how can a studio release a game with problems that are so obvious and widespread?

I'm going to take a stab at these questions and hopefully say something useful about game testing.  But first I want to say that Software QA is an enormous area, with hundreds of great books already in print about the subject, so I can't possibly give any kind of general coverage of that topic in this brief rant.  If you seriously want to be a great QA Engineer there are some excellent books on the subject.  Michael Feathers book "Working Effectively with Legacy Code" about how to get testing into an already running project is great.

Even the more specific subject of Games QA is massive and fraught with differences of approach.  Instead what I want to do is raise three things to get us thinking more deeply about these questions, and point the way to the answers.

Developers Should Test What Works


Its a developers job to test what works, not every edge case.  Ask someone who is early in their career as a developer how to put on their QA hat and test the following function:

// Given the width and height of a sprite rect, return its area
int getArea(int width, int height);

They'll probably say (especially if they didn't write that code) something like this:

Oh, right - we need to test what happens when width is the smallest it can possibly be, and also the largest; and the same for height - yeah, and let's test all the combinations of those.  Right - that is a good start.
Fair enough, but that is not a "good start".  Where you must start in my opinion is by doing what I call "testing the man page".  In Unix-like systems you can take a function and call the command-line tool man (short for manual) to tell you what it is supposed to do.  So for example here is a screenshot of what the man page for fmaxf(x, y) looks like on my computer:


Pretty specific isn't it?  If a function does not do what its man pages advertise it as doing, then its failed.  So we first need to make sure it at least does what is written on the outside of the box.  If you have a bunch of fancy ideas about testing the limits of the data types passed in, or passing random data into it that is fine - but you have not done your job as a test engineer if you have not tested that the function does what it is supposed to do when passed in typical end-use values.

Well, there's no man page for our getArea function above, but there is a comment above it, which shows what the author intended it to do.  First off its pretty clear that the area is intended to model what a rect of a sprite can be:  and for that it really makes little sense for width and height to be negative values.  Also given that the rect is for a sprite, we can guess at typical values, eg 640x480 and so on.

What's more if you wrote a test that included passing in INT_MAX for both those values the result would probably overflow and produce garbage.  You might conclude that your testing had found a fatal flaw; but really unless you ever plan to have sprites of tens-of-thousands of pixels in size that is probably not the case, and your test is probably not valid.  For the professed use case of the function int is probably fine - maybe uint would have been better - so the limits of the data type are not really a problem.

The thing about functions like this is that often there is fancy caching and optimisations, and various other things going on under the hood, which we should not need to know about - all we need to know is that the function does what is advertised.  My point here is that the man page, the box description, that should be your starting point, and the other stuff is typically not worth the time up-front, and sometimes even no use at all.

As developers we understand this at a pretty fundamental level, and thus when we have to test our own stuff, we usually start with testing that we have at least done our job and what we produced performs when asked to fulfil its brief.  Should we be testing a lot of corner cases and boundary values?  Are developers falling down on the job when they don't try hard to break what they have built?  No, because exhaustive suite based testing provided by complete unit testing, system testing and integration practices is a different endeavour from software development.

If you ask a developer "have you done X" where X is some bit of software functionality the answer you get will reflect whether they have written the code and tried it out on its core use case.  Doing full QA on X is a very different thing from "developer testing" which is not part of QA at all really.  A good QA engineer starts with the core use cases and goes from there.

What this means for game playing public is that if you find a bug on your particular platform, operating system release and engine version that seems so incredibly obvious to you, the question to ask is not "how could the developers have released this!" it is something more like "how could the publishers not have paid for exhaustive QA which covered my configuration!"

I'll just say one more quick thing about this topic before moving on:  random testing is also not a good start.  In the refined air of security theory we have a practice known as "fuzzing" which involves blasting large amounts of random data at an application (typically a web-app with a HTTP front end) in the hopes of getting it to break.  There are also suites of security testing tools that employ fuzzing, in combination with very large data buffers, unicode characters and a range of other malicious data intended to break the application.  If an app can be broken, then likely it can be exploited and that is bad in something that has your credit card details or personal information.

This kind of "penetration testing" or "white hat attacks" are not where you start in games QA testing.  I'm not even sure if there really is a place for this near the end of QA testing, even in the most well resourced games publisher's QA house.  Games QA is about making sure that the central game play works when taken down the path that players experience on their regular hardware.


An Aside: Aren't Developers Supposed to Write Tests?


As a Software Engineer the answer to this is "Yes, always!".  And here, tests means:

  • unit tests
    • that is per function tests like when testing our getArea() function above
  • integration tests
    • designed to catch problems when we check in our code into the project
  • system tests
    • designed to test on real hardware with networks and inputs and so on
Doing these things properly is the only way to ensure critical software projects work properly.  Mobile operating systems, production software, commercial projects - you don't know if they're actually working unless you do these things.


But in games and apps, the project has no spec as such; there is no framework or system - we're writing user or player experience right on top of a UI layer.  Testing would involve taking screenshots to see if they "looked right".  If our development schedule and project budget has allowed time for it then sure - off we go and do those tests.  But often in games development at the layer close to the player, these types of developer testing are just not feasible.

In framework or library code, yes: developers write tests.  In production systems you must write unit tests as part of development and the budget has to be made to stretch to those tests.

But if you're writing an app or a game, or some other consumer software its pretty tough to justify the expense of writing unit tests to check a screen looks right, let alone setting up integration and system testing.

As a software engineer I would always write tests for every piece of software, but as an indie game developer writing code that gets thrown away 5 times before it reaches production writing tests is not justifiable.  Hence as developers of games we rely on QA testers largely for our process.


Software Testing is an Adventure Game not a Combat Game


I've worked with some great QA guys in my time as a software engineer.  The very best QA guys could work across an incredible array of devices with ease, and juggle multiple different versions of OS on those devices, installing our new updates carefully so as not to leave artifacts from previous installs that could corrupt the results, and then delivering timely accurate reports of exactly where I had screwed up in my work.

The QA teams job is a tough one, and at times its thankless.  But its also essential.  Here's how to think of QA: its like an adventure game, where you have to go into every room, find every object in every drawer, behind every picture that swings out, and under every trapdoor, before you can say you won the game.  In combat games you beat the boss with that final swing of your sword and you're done, even if you cut straight through the instance without doing any side quests.

Some QA guys I worked with when they started out they'd come out triumphantly with something they'd managed to break, perhaps in an interesting way like the bug in Cognition above, and wave it around proudly.  We'd give them a pat on the back, smile a wry grin and give them their moment.  The QA guys who got the most respect were the ones who produced a large list of issues big and small, from all parts of the projects functionality - and who found ways to reach and test that functionality even when weird, or distracting bugs made it difficult to reach.

So if you're recruiting for great QA engineers, just remember this: you want adventure quest players with an eye for the long game, not the boss killers who think its time for a big-noting break whenever they kill a boss.

QA is Hard(TM) but Every Bit of QA Done Makes Things Better


Finally my third and last point: don't be discouraged.  If you're a player and you still see buggy games; or if you're a developer or studio producer and it feels like you'll never make the game perfect; remember that the perfect can be the enemy of the good.  Delivering and publishing are essential and there's a very real truth to the idea that the best software is the software that got delivered, when compared to the theoretical amazing software that didn't.

I hear student developers and those working on their vanity projects say 
But what is the point?  No testing is going to find every bug!  You can test yourself blue in the face and still miss bugs!  What good are QA procedures if its not going to stop the problems its supposed to fix?
Well, here's some tough news to hear:  nothing is going to stop all your bugs.  If you are writing software (and games are software) then you are writing bugs.  The only way to make no bugs is to make no software.
Why have laws against murder if people keep murdering?  Why have democracy and voting if corrupt politicians keep getting in and feathering their own nest?  Why do exercise and eat healthy if we're just going to die anyway?
The answer is in the title of this section:  we do what we can to make it better.  Every incremental improvement trends us closer to where we want to be.  That is what QA is about, that is what being a tester is about.  You don't get to kill the boss, you don't get to save the world, you just get to make things better than they might otherwise have been.

If great testers and awesome QA procedures mean that you ship your game and the number of players experiencing awful bugs is one less; then it was worth something.  That one player gets a great experience from your game, and played it how it was meant to be played.


Tuesday, June 18, 2013

Progress update video

A thing or two dropped into place today so I thought I'd upload this progress update video showing where things are at with my game, EthEx2080.

Apologies for my halting voice-over - I am a bit weary but I get there in the end.  :-)

All constructive criticism is gratefully received.

Please bear in mind that nothing is carven in stone at present, especially the character look and animation.  I am looking at changing over to Spine for that which will give me an opportunity to redo the vector art from my original Anime Studio work.

I want to give our heroine a slightly softer look - she's kind of a hard-nosed type at present!  Also the way the vector art came out trying to allow for the face animations and neck movement made the line around the face heavier than I wanted.  Anyway - you get the idea.

By the way - if anyone followed my presentation on Lua scripting you can see a bit of that coming through here in how the game text is generated from the state of in-game items.

Let me know what you think.

Wednesday, March 20, 2013

Games: Free Stuff, No Matter What the Cost?

XCode's In-App-Purchase documentation - screenshot
XCode's In-App-Purchase API doc

As an Indie game developer my livelihood depends on being able to sell what I make.  What I make has to be good, and then - so the theory goes - people will pay what its worth and I will be able to make rent and go on making games.  In this little article I am not posting because I have the answers - I guess what I'm more interested in hearing about is what people feel about the issues.  In-App-Purchasing - which is made drop-dead simple by technologies and API's like Apple's iTunes one shown here - make it easy to make money, but if people feel that is evil, that then is a thing.  Feelings can't be fixed by technology.

Thing is, a lot of people don't want to pay for games.  This is the so-called "race to the bottom" in game pricing.  One way to deal with the desire for free games, while still making money, is via In-App-Purchase - but there is a lot of contention out there amongst gamers about IAP.  I agree that there ought to be some rational perspective on IAP, but it can cause media spectacles like the kid in the UK who spent thousands of dollars buying virtual donuts on IAP.

I was having a discussion yesterday with a friend about how badly we as human beings do our calculations on what is good value.  We'll crawl over broken glass to get something "for free", even though it would actually be much better value to us to pay up front for it.  Why IAP works is that we "get something for free" and figure we'll have the judgement to not fall for the mechanisms that lie in wait to get us to pay for it.  So why is the games industry so hot on IAP?

IAP as an Anti-Piracy Mechanism


Here's another way to look at In-App-Purchase - as a response to "piracy" of games.  Below I mention the SimCity fiasco and a mention of it in an interesting article by Tommy Refenes which I link to.  That was ElectronicArts trying to do "DRM" by making SimCity players connect to a server - IAP requires connecting to a server to access game content too.  But IAP is not DRM and its not the flash-point rage causing issue that DRM is.  It's like "DRM-low-tar" and we can sort of deal with it, so industry is turning to it big time.

So let's look at this: what is "piracy"?  Note that I put that word in quotes because I think its a poor choice of word but one we seem to be stuck with.

I have some acquaintances who pirate movies.  I smile and shake my head.  One of my friends downloads her movies via torrent and when the file arrives burns it onto a DVD for watching later.  She downloads the color cover art for the movie, and prints it out on her colour printer, and tucks it into the DVD jackets she buys for the purpose.  She feels she has "got something for free" then because she has the same DVD she could have bought from JB HiFi in town, but didn't have to pull out her credit card for it.

But she did have to pay.  All that printing and stuffing about.  Even if you're not a high-rent computer pro your time is worth something.  My point is doing that downloading is not nothing - its a personal investment.  Those bytes come out of your quota.  When you torrent you advertise your IP, and expose yourself to malware.  Then there's the cost of whatever else you have to do to install and maintain the software to do the downloads, and manage and store the content.

My point is that with all these costs, why would folks do it?  Answer: our desire for free stuff.  IAP is clever because instead of defeating the human urge to get stuff for free, its exploiting it.  So - with IAP if we get stuff for free, what's the problem?  Answer - its not free because we shoulder risk.

Risk is a Hidden Cost


Downloading also involves a small but not inconsequential amount of personal risk.  When I was at the University of Queensland doing my degree (far too long ago) the RIAA showed up one day at the IT center with a bunch of lawyers, and a court order demanding the computers at a given set of IP addresses and the hides of the students & staff using them.  I know some people were identified in that fiasco, and I don't know what happened to their careers - I would not want to be part of that.  Regardless of what you personally feel the morality is of downloading, you cannot say that the personal risk is zero.

Risk is a cost.  If you shoulder a 0.1% chance that you have to pay $100,000 - then a statistician or an economist will tell you the expected outcome of that decision is $100.  Its just that as humans we are absolutely lousy at seeing this.  We are crap at figuring out if we really got something for free or if we wound up paying in some way that we did not expect.

I know some of you are pretty clued up when it comes to downloading stuff, and you know how to use torrents and other warez services so that you're not at risk: you can manage all that stuff, and make out like a bandit.  I'm impressed - I would not know how to secure myself against those risks.  I guess I could learn.  But when it comes to getting warez there's lots of folks cleverer than me, I freely admit.

But you know what?  A lot of people feel the same about IAP - they can download the free game and not be hooked in by the IAP.  But plenty of people do fall foul of these things.  I guess all those folks who wound up paying felt they would not be the ones to be hooked - but they were.  Maybe we'll be the clever ones - but we need to ask, how good am I really at assessing the chances?

Maybe I'm drawing a long bow here, but my argument is that whenever we think we're getting something for free, we should be saying "if its too good to be true, it probably is".  Google search is "free" right?  "I never click on those adverts!"  But guess what - millions and millions of people do.  Maybe you've clicked on them and not realized?  How confident are you really that a "free" app won't cost you in the long run?

Buying Up-Front versus the "Never-Never"


I don't have time to muck around searching for warez and freebies - I find it much easier to buy stuff.  I'm not rich, in fact I'm not well-off even - but I can afford to buy a movie or TV program if I want.  Certainly I can afford to buy more than enough for the time I have to watch them.

My friend that downloads stuff - I don't judge her for that.  I just smile and shake my head in wonder because the once or twice I have been at her place and seen some of that stuff the quality is pretty awful.  I know if I'm watching a 100 minute movie I don't want the key part of the movie to have some guy with  big hair stand up in front of the cam, and obscure the best part of the show.

I know its possible to get much better quality pirated stuff, but why should I bother?  I can spend a fraction of the time and buy stuff on line - in and out in seconds from Amazon or where-ever.  I have only once had issues with quality on some DVD's I bought that way - and it was a lousy cardboard jacket that a collection of X-Files DVD's came in.

But the point for me is that watching DVD's is a relaxing and fun thing to do - I don't want to be stressed out trying to deal with all the issues around pirating stuff.  LifeHacker has this interesting article about how to torrent safely - man it sounds like a lot of work.  Some of the best suggestions like using a VPN service may actually cost money, and still don't guarantee your safety.

I just feel a lot more comfortable with my nice crunchy shrink-wrapped thing I bought for some $$$$ and if there is any quality issues I know exactly how Amazon or whoever can fix it for me.

Paying for Games


Does this carry over into games?  

For me it does - I know I personally would much rather just pay up front for a game.  I just don't think in general that I am clever enough to monitor how much I would spend on IAP on games that work that way.  One $0 game is "worth" about the same as any other $0 game - but if I pay $7 for a game - like I did with Bulky Pix's "Yesterday" recently - then I know some things about what I'm buying.  I have some expectations about its quality, the amount of content, and I know if I'm not satisfied I can hit up iTunes for my money back.  That's not really an option with IAP.

Maybe this is a weird analogy - comparing downloading a free game with IAP, to "pirating".  What I am really trying to say is that what we do as humans and as gamers when we "go for free stuff" is always driven by the same desires. 

It's like loans with "pay nothing for 6 months", and credit cards with high limits.  Some people do well on those things.  Most people don't and pay a fortune.  Corporations and fancy marketing guys know how to abuse our desire to get free stuff.  They are awake up to how poor our decision making can be in that regard, and now they're in digital media gunning for our wallets with the same techniques.

As far as "piracy" of digital stuff goes - I think that word is idiotic - it is stupid to compare attacking ships on the high seas to downloading digital content.  I think it is not a crime, its just bad karma.  I think that if companies need draconian laws to protect their business model they are doing something wrong.  And I think that if they make it easy enough and cheap enough to buy good stuff, people will do that rather than pirate it.

No Harm, No Foul?


However: I think "piracy" is not innocuous and its not harmless.  I strongly suspect it hurts you and me more than it hurts Electronic Arts.  I suspect that faster than we can profit from it clever corporate types can turn the urge for free stuff into profit for them.

There is an interesting article about piracy of Super Meat Boy, from Tommy Refenes who was one of the creators of Super Meat Boy, and featured prominently in the indie movie "Indie Game" about the lives of indie game developers.

Tommy is pretty philosophical about piracy, and I agree with pretty much all of what he says.  I agree that if someone pirates 1000 copies of your game you still have infinite copies.  Tommy says "there's worse things than piracy:  like DRM and refund requests".

True that.  However I have a couple of comments.

First I think that the best industry response to piracy - "easy enough and cheap enough" - when driven to its logical conclusion means IAP and things like it.  I don't think IAP is evil, but I do think its very easy for people to spend a lot of money on IAP without being aware of it.  You need to be pretty clever to avoid paying out large on those things - I don't trust myself to be that clever and so I mostly avoid such schemes.  I'm lousy with my credit card - so I have a low limit.  And I just know I'd be lousy with IAP in my games I buy.

I think that our desire to "make out like a bandit" can be used against us by corporations to make a profit and IAP is an example of that.  We can outsmart ourselves too easily this way.

Secondly - you know what?  Ripping off digital content is Just Wrong(TM).  Do you really want to be that guy?  When something is wrong that doesn't make using DRM or laws to try to stop it right or justifiable.  "Wrong" doesn't mean - "let's bring in the DMCA and the goon squad".  Wrong means bad karma.

Play Nice with your Friendly Neighbourhood Indie


Developers of games are people, people like you and me.  People like Tommy Refenes and Edmund McMillen.  Pirating our games is just lame.  Go ahead and do it, why not?  We can't stop you.  Like Tommy in his article all I am going to do about it is say "WTF really?" and write about it.

I understand Tommy's point that there are worse things to worry about than piracy.  But just because you can find something worse, doesn't mean that its harmless.  Just because there's other stuff going on that's bad doesn't make it totally fine.

I'm going to sell my games with an up-front price and hope that folks are OK with that.

I doubt my game will be as successful as Super Meat Boy, and if I fail to make enough money to keep doing games then it won't be piracy that causes that problem.  In fact if I ever get to where my game is pirated that probably means I have finally made it to the Big Time.  :-)

But we're all gamers and I just think that our desire to Get-Stuff-For-Free-At-Any-Cost(TM) is just making our world a worse place to be in, but worse we're outsmarting ourselves when we follow that instinct without watching our hip-pocket.

Saturday, March 2, 2013

Game screen design in Google Docs

Looked at Google Docs lately?

If you're like me you probably think you know pretty much what there is to know about Google Docs: its a web-based thing that tries to be like Microsoft Office, right?

Well its been getting better - a lot better.  There's a really good Draw app now.  Combining Google Docs Draw app with the Google Sites features allows you to create a real-time game screen-flow sharing/co-development tool.  The cost is $0 and there's not much you have to do without compared to some commercial apps.  Here's how I use it.

Quick note: these are mocked up development shots for this post, but based on real work from my private Google Docs/Sites - please don't make any judgements about this based on its current state - "Oh I saw the game from Sez and she's making this thing about a room with nothing in it...".  Examples only guys.  :-)

What I discovered is how awesome Googles suite of apps can be as a platform for doing game design, especially if you're an indie and trying to work with others who are not in the same location as yourself.    If you have mentors or friends you want to get reviews from same applies - its a great tool for sharing development ideas in a quick mock-up form before you spend ages coding them up or paying out for finished artwork.


When you work from your spare room, and need some who's remote, doing art-work or some other part of the game to be able to see your ideas, it can be a pain to try to get the latest version of your stuff and drag it into DropBox, or share it on some kind of paste-bin site.

The Draw application is not good enough in itself to do finished work, but its great for quick mockups of screens so that you can get the general proportions, colours and most importantly the flow or sequencing of screens right.  You can import artwork including sprites and backgrounds (like the room background below) and combine it with graphics created with Draw's basic vector tools.  It has a palette of predefined shapes you can use, and you can fill them with color, or make them transparent - even alpha blended, like the Map HUD above.

What is great about Google docs is that you can edit the document right in the web-page and who ever you're working with always gets the latest version when they open it.  In fact you can collaborate in almost real-time.

But even better with Google Sites you can then embed your Google Docs - graphs from the spreadsheet app, or in my case drawings from the draw app - right into the webpage, creating a flow of screens for different use-cases.


When you update the Draw doc, folks visiting the screen-flow page with your use-cases on it get the latest version - since its a live link, not an embedded render of the drawing.  This makes the Google Docs & Sites a very powerful way to collaborate.

Sites also has very good sharing features so you can make collaborators have writer levels of access, and provide others with read-only, all while keeping the whole thing private while you're still in development.

One other quick tip - if you want some great general icons that are good for doing development mock-ups and use as placeholders, but do not have the commercial limitations of some icon sets, have a look at the Tango project - I've used some of them in the above shots.  There's around 180 icons with standard sorts of things, like "Save" and "Quit" and so on.

The direct link to download the tar.gz of their icons is here:  http://tango.freedesktop.org/releases/tango-icon-theme-0.8.90.tar.gz - on Mac you  should be able to open that archive up without any problems, but on Windows you might need a special archive tool.

Have fun designing your screens!

Tuesday, February 19, 2013

Game Mythos

Working on the intro animation for my game has led me to do a bit of development of the game mythos.  What I mean by mythos is basically the rules and background that governs what goes on in the game world - other than normal world stuff which we already know.

When it comes to normal stuff like "how big is a loaf of bread" - that is certainly the rules and the background, but where it does not differ from our  normal world you can just take it as read.  Where your game world is different - magical, super, silly or just plain weird - that is where you need to start work to figure out just how different.

Think about any game that features vampires for example (no vampires in my game by the way - this is just an example).

  • Do the vampires get to go out in the sun?  
  • Does garlic or crosses work on them?  
  • What about their powers - are they super strong, or super fast or both?  

When you ask those questions for any game, about the characters, the world and so on you are defining the mythos.  I chose vampires as an example because it seems like almost every game, TV show, movie or book that deals with them has a different mythos.  Just saying "this game character is a vampire" doesn't answer all the questions - and its always good to answer them upfront.

Pragmatics also comes into it.  Sometimes in your game you want a particular mythos element but it is just not practical for the development of the game.  If your vampires (to extend the above example) cannot go out in the daylight does that mean absolutely all your game scenes/rooms/levels have to be at night?  That might be a bit limiting.

It's important for any game to nail down the mythos elements early on to avoid continuity problems.  This is especially the case if you are building the game with help from others.  Keeping and updating a mythos document can help do this.

In my game, EthEx 2080, the setting is a near future planet Earth.  At this time, medical technology has advanced so far that almost any ailment or weakness - real or imagined - can receive treatment, at a price.

Many of the problems this brings about exist today in 2013: trafficking in body parts, illegal sales of medicines and therapies, illegal or ill-advised cosmetic and surgical enhancements.  And of course performance enhancing drugs and therapies - such as blood doping, and steroids.  You don't have to look far to see this stuff in the news today.

The hero of my game is an Agent in the Ethics Executive - she is an Eth-Cop.  Their motto is Dignitatem tutando Hominis which translated from Latin is Defending the Dignity of Man.  The dignity of man is a key idea in the field of Bio-Ethics.  I came up with the ideas for the crest above, and the motto from my reading.  Then working them up like this using my tablet and a vector drawing program starts to make the idea of the Ethics Executive come alive.  By the way the above is just the basic design - I have not added any color or lighting to this - but you can see the idea.

I used Google's translate service to go through a few variations on the English version of the motto until I got one that came out sounding good in Latin.  I'm planning for one of the cut scenes that the camera will zoom right in and come to rest on the crest so the detail is not just an exercise.  And likely it will also probably feature on an Eth-Cop's badge which will be an inventory item in the game.

Working on some elements for this globe-spanning bio-ethics justice group has involved trying to nail down who they are, what their powers are (legal rather than super) and what kind of an appearance they have.  In the crest you can see some of these elements: the UN style globe & wreath - symbolising peace and international reach; the medical profession (although the staff of the Caduceus is replaced with a sword) - also the hand (symbol of human rights) and the scales (for justice and the legal system) appear here.  Interestingly there is some history around whether one snake or two should appear - one snake is actually correct for the original Greek mythology, but recent history has led us to use the two serpent version.

It's good when looking at mythos to examine other great mythos makers in the same genre.  For the dystopian sci-fi near-future you can't go past Phillip K. Dick's "Do Androids Dream of Electric Sheep" which was realised in movie form as "Blade Runner" by directory Ridley Scott.  I've been watching a great documentary on sci-fi writers which has a good discussion of Dick and his writing.  In particular the paranoia and ethical conflict that Dick was trying to portray.

The thing about the future world of Blade Runner is that there was no new special group of cops, or legal framework for dealing with the massive scientific advances it depicted.  Dick's hero Rick Deckard was an independent; a bounty hunter, although he took his work from the Police department.

I will need more structure in my game.  For EthEx 2080 I want collecting evidence to be an important game mechanic.  Also I love procedural cop dramas and wanted to capture some of that too.  So I needed to know more about the Ethics Executive and what they stand for.


So far I'm thinking of some thing a bit more like the real-world FBI, but with a bit of the British MI6 thrown in for good measure.


I took the above shot of the MI6 building from the Lambeth Bridge when I was in London in 2004 on holiday, and this building has captivated me for ever since.  Looks menacing, secretive and bunker-like doesn't it?  It's pretty impressive in real life.  Makes you wonder what goes on inside.  I'll probably never know for sure, but soon I plan to lift the lid on the Ethics Executive and give us all a view of the life of an Eth-Cop.  :-)

I am hoping to have the title animation done this week with any luck so stay tuned for updates.

Sunday, February 10, 2013

Animation begins

Screen grab of the Neural Probe character that I'm working on currently in Anime Studio.  This is for the title sequence of the game which is non-interactive (basically a movie that rolls while the game title and intro is being displayed).  This little guy is so much with the lamprey and menace vibe that I just have to find other places for him to show up now.

I'm going to try to do a bit of animation every week I think, so I don't have a huge pile to do at the end. It's really intense work, and so different from coding.  I will pretty much need to mix it up, or my spine will be a pretzel from all the concentrated tablet work.


This is a part (can't give everything away at once) of the scene the cute little guy above appears in.

Monday, January 28, 2013

Game Music



Wow - nearly the end of January and I haven't posted here for a week!  Time flies when you're hacking.

This is a really quick post just to frame a quick recording I made of some basic video game music.

I didn't want to just post the music as a raw sound file so I dropped it into a quick video format so I could put it on YouTube, and that also gave me a bit of an opportunity to mention the technologies I used to make the music.

I have a Yamaha PSR-E413 Keyboard, which is a very basic guy - just fine for what I need.  I can play it stand alone as a keyboard but I mostly use it as a midi to drive Garageband.  Because I am very low on the skill level - I can do a few basic chords & scales, that is it - I love the GarageBand ability to do multiple takes until you get something you like.

For this I chose a basic scale and just fiddled about until I found some notes I liked, then worked out a rhythm to suit.  I used GarageBands metronome to get things in time, and then turned that off when I exported the recording.

As I mention in the video to get the atmospheric and futuristic feel I wanted, I used a synth pad.  GarageBand comes with a few but I wanted to be able to tweak it a bit so I picked up NLog Poly Synth from http://www.temporubato.com/

The result is pretty average but good enough to use as a place holder for the early stages of the game, and to give a pro musician an idea of the sort of thing I want if I get funds for a bit of polish on the game.