Categories
dev-process games design iphone

New free iPhone game…

Last night, I had another game approved for the App Store…

ss1

iTunes: click here to open iTunes download page

I started writing this as a real-life demo on how to use the tech for my new company (if any of our early access licensees are reading this, a project ZIP with full source code should appear on your dashboard imminently), but I gave it to a few friends to test, and they liked it so much I thought I’d put it up on the App Store too.

I’ll be updating it over time to add more of the features from our tech. If enough people download it, I might even make a paid version (which would be pretty handy as an example, too :)) with some more features, more powerups, etc.

Categories
computer games design dev-process devdiary games design iphone

Dungeon Master Clone for iPhone – Concept GUI

(c.f. my original post here: http://t-machine.org/index.php/2009/06/28/want-to-help-write-a-simple-rpg-for-iphone/)

I’ve been playing around with GUI setups for DM / EOTB / Wizardry clones on iPhone, and thought I’d post some of the more interesting results here – I’m interested to see what other people think of each of them.

The first three are all assuming a single-character RPG, the fourth is something more like DM / Wizardry (could be 6 chars, could be 3).

Everything is clickable – small maps become full screen map, blue buttons fire spells, character portraits go to the inventory screens.

Screens with no arrow buttons require you to drag your finger forwards/backwards/left/right to move, and allow 360 degree movement. Screens with arrow buttons assume you can only turn 90 degrees at a time (like the original games), although they smoothly animate the rotations (UN-like the original games – because I have access to OpenGL to do the 3D for me).

What do you think?

concept-ss-1

concept-ss-2

concept-ss-3concept-ss-4

Categories
advocacy dev-process entrepreneurship games industry startup advice

What I believe in, for Quality of Life

The furore[link] over the IGDA’s failure[link] to live up to it’s own precepts continues to snowball[link] [link] (as I suggested it would, if the IGDA Board didn’t ‘fess up and take a stand[link] against the unethical practices they were being implicated in).

(I’ll do a summary later this week; personally I’m aware of 6 different unique forum threads and several separate bloggers speaking out on the topic, each with their own comment threads – we’re gradually seeing the message spread, which is good. But it also means it’s getting hard to keep up)

One commenter, perhaps playing Devil’s Advocate for those at fault, has repeatedly posed the question: “What would you *like* the IGDA’s stance to be on this topic?”

There are all sorts of reasons that’s a dumb thing to ask, and it essentially misses all the points being made here by the unhappy IGDA members, but I thought it was a good question to answer anyway, philosophically.

Quality of Life for the Games Industry: Adam’s stance on “Crunch”

NB: this is only covering the crunch/working hours/overtime issues; there’s more to QoL than that, but it’s definitely the headline aspect.

(and hopefully you’ll also have a look at Darius’s stance on this and other related topics, since he’ll be standing for election to the IGDA Board next year, and he’s got my vote already ;))

  1. the term “crunch” is a euphemism for “unpaid overtime” used largely to disguise the true nature of what’s being described. No-one should ever use the term “crunch”. Everyone should actively encourage others to call it what it is (unpaid overtime). “unscheduled overtime” is NOT an acceptable alternative; it is simply another, slightly less positive, euphemism.
  2. no employer gets an opt-out from responsibility for Quality of Life issues, neither charities nor startups. Quality of Life is about the relationship between employee and employer, independent of individual industries, organizations, or projects
  3. the company must at all times actively discourage staff from doing unpaid overtime; if the company wishes to support overtime, it should be supporting *paid* overtime only
  4. no programmer, artist, or designer should ever stay late in the office “because it’s quieter then, and I can get more work done when everyone else has gone home”; if the office environment is that poor, the company needs to fix it, fast
  5. the MOST EFFICIENT (for the company) number of weekly office hours for programmers, artists and game designers lies somewhere between 30 and 50 hours a week.
  6. the MOST EFFECTIVE/DESIRABLE (for the employees) number of weekly office hours for programmers, artists and game designers lies somewhere between 20 and 60 hours a week.

Why does this even matter?

Most workers in this industry live to work, instead of working to live; this makes the industry especially prone, and the employees especially vulnerable, to abusive employment practices.

It also means that – handled correctly – most people ought to be happy and healthy. This topic has the potential to improve the lives of thousands of people; that it will almost certainly also improve the quality of the games they produce is a secondary (although highly desirable) side-effect.

Details / explanations

1 – Terminology

Cynically, I’d like to point out that to many young males (the bulk of the workers in the game industry), the term crunch probably initially conjures up images of the painful gym exercises that build the widely desired abdominal muscles.

i.e. the base assumption of an English speaker is that Crunch is something that “hurts now, but is good for you, and in the long run you will appreciate it”.

Actually, I don’t think that’s even all that cynical, looking at the companies that actively use the term: I think they’re extremely happy to have got such a positively-connotated word used as the main term to describe their unethical business practice.

2 – Opt-outs

Several people (such as Erin Hoffman (EA_Spouse) EDIT: my mistake – sorry, Erin! – see comments below) have claimed that startups are “special”; too fragile to be held accountable to the same standards that ordinary companies are held to; that they could never adhere to sane and ethical working practices and remain in business.

As a previous founder, co-founder, or C-level exec in 5+ different startups, and a consultant or external adviser for a further 20+ startups, it is my personal opinion that this is absolutely not true.

Further, I believe it is deeply insulting to most entrepreneurs to imply that they are so incompetent that they need to be allowed to break with ethics or law in order to succeed. The majority of successful entrepreneurs I know are awesomely competent people, and have earnt (*earnt*) their wealth not merely through “having a good idea” but through being better and smarter and wiser than their equivalent salaried employees. They need no leg-up.

Of course, there’s also plenty who simply got lucky. But that’s another story.

3 – Working late in order to work better

There are two issues here.

Firstly, if someone is doing unpaid overtime, the company needs to either reward it or try to persuade them to stop; anything else is unfair. Simply taking the proceeds of the free work and paying nothing in return is perfectly legal (although arguably, since the work falls outside of the contract, if the company’s employment contract isn’t good enough the company could find themselves not entirely owning the output of that work), but unethical.

Secondly, unless the employees have strong legal protection against coercion (both explicit and implicit) then the claim that staff are “voluntarily” working unpaid overtime is often going to be a lie that – in practice – is almost impossible to uncover. A nice, comforting lie, but a lie all the same. I have many times worked with people in the games industry who have openly claimed their unpaid overtime was voluntary – until they buckled from stress a few weeks later, or got drunk, or met up outside the office, and admitted the true reason(s) they were doing it. Generally those were “to keep my job”, “because everyone else on the team says I have to”, or a variant on those. i.e. to satisfy the employer, or to satisfy peer pressure.

This is true even in Europe, where employees have fairly strong legal protection – but in many cases don’t realise the full extent of the protection. Generally speaking, only the inexperienced, younger staff are ignorant of the basic laws here. Within 5 years they normally see at least one friend or colleague go through some situation which uncovers the laws involved, and they gain a basic understanding of what their own rights are, under the law.

4 – Optional isn’t always optional

I’ve worked with many programmers who felt forced to work late hours because of this, and a few artists. I haven’t worked with any designers yet who were *seen* to, but I know plenty who have done it – they simply went home and worked from home instead.

The main reason programmers show up with this problem more than others is that they are entirely dependent upon the tools at their desk to get any work done (software, hardware, office systems, etc). It’s *not* that they are the only ones who work hard and have to concentrate to get good work done!

5 – Efficiency

As far as I know (please correct me!) … no-one currently knows via research what the MOST EFFICIENT weekly office hours are for programmers, artists, and designers in the games industry; the research I’ve read summaries of, and in a few cases read myself, from other industries and anecdotal evidence, plus the experience of skilled game developers, suggest that it lies somewhere between 20 and 40 hours.

Further, the majority of research from other industries and evidence and experience strongly support the claim that values over 60 hours are less efficient than ANY value between 25 and 60 hours.

6 – Quality of output, quality of life

As far as I know (please correct me!) no-one currently knows via research what the IDEAL (for the staff work/life balance) weekly *working* hours are, but assuming 14-16 waking hours a day, i.e. 70-80 waking hours a week, and assuming a work/life split somewhere between 30/70 and 70/30, you get between 21 and 56 working hours per week

Categories
bitching dev-process fixing your desktop iphone programming

Unity: First impressions

I had to do some iPhone prototyping recently, and we had a trial copy of Unity to hand. I thought this was a great excuse to try using it. First impressions of the editor/IDE/environment – at least on OS X – are not good.

NB: In general, in terms of what can be done with it etc, I’m a fan of Unity. But I’ve never developed with it directly myself, and I’m now finding it surprisingly painful / steep learning curve.

Need to know basis

None of the built-in tutorials work, flat out, because the startup code has apparently changed substantially since they were written. The tutorials keep talking about things like “create a new project; by default it will X and Y and Z” but Unity no longer does any of those by default. Sadly, the tutorials don’t tell you how to get any of those manually – because, you know, they’re done for you by default, why would you ever need to know how to do them by hand?

File Association Theft

I was also *extremely* unhappy to discover a short while later that Unity has stolen the file association for PHP files. Under OS X (thanks, Apple) managing file associations is a surprisingly irritating business, as bad as with Microsoft Windows (Apple deems users too stupid to be allowed to simply edit associations – but applications are allowed to overwrite each other with absolute trust from Apple, and no user intervention allowed), so this is a pain to fix. In particular, I have an entire *suite* of applications and IDE’s for doing web editing, including a specialized high quality PHP IDE. Not any more; Unity has clobbered that with a crappy text editor that does nothing more than basic syntax hilighting. This is pretty offensive: firstly, don’t steal my files without asking, and secondly – give me back my IDE!

NB: I have no idea how it has done this, but Unity appears to have overridden OS X’s systems for file association management – following the standard procedure (e.g. here) has no effect, and Unity keeps stealing control of the files immediately that you confirm you want to give the assocation to some other app.

At this rate, if I can’t find out what it’s done to my OS and undo it, I’ll be uninstalling and deleting Unity with extreme prejudice in the very near future. Sure, this is partly Apple’s fault for assuming all apps are perfect and all users are not, but at a simpler level I just cannot afford to have a non-functioning development computer just because of one badly behaved application.

Categories
agile dev-process programming web 2.0

PHP: Looking for some Best Practices

PHP is weak, crappy, and encourages people to write terrible code. But … if you know what you’re doing, all of those might actually be really really good things.

(by the way, if you haven’t already, you should read Eric Ries thoughts on PHP…)

“Best Practices” are one of the best guides you can get for sailing between the Scylla and Charybdis of “crap code” and “over-engineering”.

So I’d like some, please.

Perfection

Anyone with zero computer science education can write crap code; that’s easy. At the other end of the spectrum we have the people who write Perfect code.

Anyone who writes perfect code is either:

  1. a liar
  2. too rich to work for money
  3. works in an industry that is immune to marketing

…because marketing is always a cheaper and more effective way of making more money, compared to writing “perfect” code.

(disclaimer: in the past, I’ve been the first, and lusted after the third, but never quite managed the second)

The skill that marks out the difference between a competent programmer and a good (or great) one is knowing which of the language’s strengths to play up, and which to play down. Sometimes, the fact that a language allows extremely sloppy code is a very good thing. e.g. most scripting languages – especially any that run on an “intelligent” runtime like the truly Awesome JavaVM – where being grossly inefficient is not only “OK” but in fact “doesn’t happen”, because once it notices what stupid thing you did, the runtime silently recompiles everything into decent C code while you’re not looking.

So … how the heck do you win?

You look for Best Practices, language-specific (and domain-specific, but that’s obviously of more niche value).

I recently did two moderate sized PHP projects. I figured: OK, so PHP is very easy to hack code together knowing very little about the platform (and I’d been using my Perl experience most of the time when writing PHP) – but Perl showed us that Best Practices are damn useful and not too hard to stick to. There must be lots that the PHP community has worked out by now!

(as Quake3 would say, in a bass rumbling voice:) Denied!

Um, no. Apparently not. Google – with *considerable massaging* – threw out a few dozen attempts from different people.

There was some interesting stuff in there. I found some obscure bits of standard and near-standard extensions I hadn’t noticed previously when reading the manuals.

But, to be honest, nearly all of it was a waste of time – it simply wasn’t PHP specific. Telling people that they should “document function headers” is meaningless as a “PHP Best Practice”. It’s not a PHP Best Practice, it’s a general programming practice. You can find it in *any* textbook (and if you don’t know stuff like that, I suggest you go read a few key books like Code Complete, for starters).

There’s also – and this quite upset me – a lot of BAD practice out there being passed on from PHP programmer to PHP programmer and hailed as if it were “a good thing”, when often it’s about as wise and valuable as staring down the barrel of a loaded gun so you can see better while you clean the inside.

What is PHP good for? Why?

I have recently realised that the majority of PHP programmers cannot answer these questions, and that many of the rest aren’t great at answering them either. If you can’t answer them, you can probably never be a great PHP programmer, and it’s debatable exactly how “good” you are. (/me ducks and runs for cover)

I’ve not done enough PHP to know what it does from the inside.

But I’ve done tonnes of code in “languages that are not PHP”, and I have a really really good idea what it does from the outside. And most of the Best Practices I saw for PHP were stolen from other languages (especially C derivatives) and are totally inappropriate for PHP. Because PHP is not C, and PHP programmers will never be decent C programmers, no matter how big their inferiority complex, and no matter how hard they slave to try and write “high quality code”.

Some things PHP is good at: (in no particular order!)

  1. It’s a Scripting Language (like JavaScript, and ActionScript, and Perl. But not like C, and not like C++, and not like Java)
    • It’s intended to be trivial to read and write code; the core language is “easy for a non-programmer to grasp”
    • There’s no feature in the language that requires thinking to understand what’s going on, by design (unfortunately, some of the libraries broke this. c.f. the great Register Globals disaster too)
    • idiots can code effectively…
    • …which means that highly intelligent individuals who were never trained as programmers can ALSO code effectively, with minimal pain and suffering
    • …and that changing (modifying, fixing, extending) other people’s PHP code is trivially easy
    • There’s no compiler. No cached builds. What you see is what you executed, literally.
  2. It’s very easy to grasp two of the three most important structures of a web application (the third one is “data flow” – PHP sucks at that one). The two it does great are “program logic” and “program inputs + outputs”; together these sum to “execution structure”
    • One page == one source file : you read an output (FORM or A link) to an HREF? Or a page is crashing in the browser? You know exactly which file to find it in
    • One source file == one page : all the logic (PHP tags) and the input/output parts of the user-interface (HTML tags) are in one file. So you can’t make assumptions and the resulting mistakes
  3. It’s a context-free language. This is a by-product of being so tightly integrated with HTTP/HTML. It is one of the things that “real” programmers sneer at PHP for – how can you have a context-free language that isn’t Functional and expect it to be any good? That’s some kind of mutant offspring of Fn and Imp that ought to be strangled at birth. Or … maybe … just maybe … it’s one of PHP’s greatest strengths (although admittedly it is a mutant offspring too)
    • When a single source file is executing *there cannot be any other context* (except for the Session, sadly – but this is a strange piece of context-that-is-not-context because of all the rules about what can and cannot be in a session)
    • Oh, OK: there cannot be any context from other threads, other users, other simultaneously executing code. This is one of the hardest, nastiest parts of all systems languages, the multi-threading stuff. And PHP completely wipes it out as a problem. Nice.
    • All source files – hence all user-interaction points – are (semi-)atomic by definition: either they execute, or they don’t (by default, if they start, they dont stop, not even if a crash-level event happens; more on that later)
  4. Code is mingled with presentation, but is “together but apart” because it’s guarded (in the computer science meaning of that word, sort-of) by enclosing magic PHP tags
    • You can copy/paste move around code without the risk of it becoming part of the presentation code (this problem happens A LOT (and causes some awful security holes and application crashes) in some languages, especially in templating languages, even though it seems like such a simple thing. I kid you not.)
    • Any decent IDE (/wave at Eclipse (download PDT to add PHP to it)) can do a lot better at second-guessing what the programmer wants to type next, thanks to the explicit context of being either “in code” or “in presentation”. Saves a lot of time, in very small pieces many times a day.
  5. It’s a mainstream scripting language: very very fast to write code, code is very very fast to read + understand (it CANNOT DO complex things like STL or Operator Overloading), and you can “make it up as you go along” when writing a program – it doesn’t expect you to plan ANYTHING in advance
    • No declarations : you don’t have to plan your variables in advance
    • No declarations = faster “flow of mental programming” : you can aribtrarily change your mind “mid sentence” when writing code, and not have to move backwards in the source file to fix a declaration as a result
    • No memory management : you don’t have to plan the LIFECYCLES of your variables in advance
  6. Writing basic imperative code. Fast. (Imperative == “not Functional”; if you don’t know what that means, look it up – Fn programming is awesome)
  7. Templates for pages.
    • If you’re going to use a template method (or, god forbid, “library”) in PHP, make sure that its source code looks *exactly like PHP*. Because PHP is an excellent templating language.
    • This begs the question of “why aren’t you just using PHP in the first place, fool?”. The answer to which is usually “I didn’t read Adam’s Best Practices on this website and wrote long waffling PHP source that no-one could understand”, or “I have some truly stupid accomplices who will overwrite the PHP tags whenever they see them, just for fun” (anyone using DreamWeaver has almost certainly done this at some point, without even realising it; in that case, it’s not the human’s fault, it’s the fault of their editing software – DW – but the PHP programmer can’t really tell the difference, it’s the same net effect)

Some things PHP is bad at: (in no particular order!)

  1. NOTE: just because PHP is “bad” at something does not imply that this is a bad thing about PHP!
  2. OOP. PHP is poor at OOP. It’s not as bad as Objective C (which is terrible) nor Perl (which is horrifically awful at OOP), but it’s not part of the core language, and it shows.
    • Actually, I don’t even know what to say here. Go on a long rant about how it should look like C++? Hmm. Not really helpful. I’ll just leave it at that. If you *really* need to ask why PHP’s OOP is bad, it’s going to take more than a couple of bullet points to explain it to you.
  3. It’s an “old fashioned” scripting language; it lacks some so-called modern features (many of them are older than the microchip but took a few decades to make it into mainstream programming)
    • Closures? Where are my closures? : without this, it’s much harder to write self-adapting code, and much harder to write code “for other programmers to extend and alter without needing to change my source code”
    • No OOP scripting : without this, OOP is a pain in the ass, taking a lot more typing, and standing out like a sore thumb inside any PHP file
    • No modern Array derefence syntax : (you have to do: “${arr[‘var’]}” instead of: “$arr.var”) this makes getting data out of arrays so hard that people go out of their way not to use arrays in PHP.
  4. Data flow (the third prong of three mentioned in the Good bits section)
    • SQL in PHP is not fun : it’s all manual SQL statements, with practically zero language-level support (check out Perl::DBI for an example of how funktastic language support for SQL can get; I didn’t say “good”, I said “funktastic”. There’s a difference)
  5. Distribution
    • There isn’t any. PEAR doesn’t count – and if it did, well … PEAR has one of the most appalling distribution systems I’ve seen in about 10 years. The fact that I had to hack PEAR’s installer – in 2008 – just to “not crash” let alone to get it to “start installing” says it all, really.
    • No package management. No bundling. No metadata. No repository (PEAR or CPAN? take your pick. I find both fine as manual systems, and frequent failures as automated systems).
    • (if you still don’t believe me, find yourself a Debian sysadmin and ask them to show you Aptitude, a worn-out decade-old text-based front-end to apt. And marvel at how fantastic it is despite all that!)
  6. Register Globals fiasco : the maintainers killed some core features of the language in an attempt to fix a security hole, instead of just fixing the security hole
    • Sadly, the core libraries now force you to use Arrays for evertying, because the language maintainers panicked over Register Globals and destroyed the whole input-sampling system.
    • …which is bad because of the lack of Array-de-ref syntax in the language (see above)

A quick retrospective

If you’re a PHP programmer, I hope you’ve already noticed the implications of some of the good/bad points I hilighted.

There are things that a lot of the PHP community loves with a lack of reasoning that sometimes borders on obsession/fetishism, but which – from the above analysis – are inappropriate for PHP. I’ve tried some of these, and confirmed: whoever thought this was a good idea was either smoking crack or didn’t understand how to build web applications.

Some quick examples:

  • Page Caching. You gotta be kidding me. There’s are plenty of reasons that all other languages push this OUT of the language, and OUT of the application, and most of them apply equally to PHP. Use Memcached instead, and learn to use it properly – that is, externally, not internally.
  • Separating Code from Data. As a gross generalization, if you do this, you should stop writing PHP, because you just threw away most of the benefits of PHP, and you’d be better off writing J2EE from this point on – you’d get the benefits of J2EE and of the Java language AND of the Java standard libs (which kick the living daylights out of PHP’s weak set of “Extensions”) – and you’d hardly lose anything in the transfer.
  • M/V/C architectures. If you do it the way we do it in other languages, then it’s equally stupid as the above point. It *can* be done, conceptually, in ways that fit with PHP – but the majority of PHP systems I’ve poked inside didn’t get that clever, they just tried to do it the traditional ways.

By The Way: I’m probably wrong on some of this. I haven’t spent much time thinking about it. Unfortunately, I’m not sure at this point which points are where I’m Totally Right, Dude, and which ones are where I’m Smoking Something Funky.

Sorry.

Too many words! Argh

I keep being told off (nicely) for writing blog posts that are too long.

In petty revenge, after making you read through the rant-tastic introductory bits (I have my Asbestos suit at the ready…), I’m splitting the rest into a separate post. I almost feel bad about doing this. Almost.

So, on to … PART 2: Best Practice for PHP Programming!

Categories
computer games design dev-process games design games industry massively multiplayer

We need to talk about Tabula Rasa; when will we talk about Tabula Rasa?

In the online games industry, if we keep quiet about the causes, the hopes, the fears, the successes, and the failures of the best part of $100million burnt on a single project, then what hope is there for us to avoid making the same mistakes again?

Categories
dev-process entrepreneurship games design games industry startup advice

Ptiching to Game Publishers – some thoughts

Thomas and Diane have posted a short guide to Pitching to Game Publishers over at the blog for their game consultancy. Apart from giving them some link love (they’re not even on Technorati yet), it’s an excuse for me to tack-on some quick thoughts of my own.

(NB: my experience on the publisher side is pretty short, just a year spent working with Thomas and Diane as one of the people doing due-diligence for them on the incoming pitches, and doing milestone-reviews on the signed projects that were in-development.)

Categories
dev-process iphone programming

iPhone Development FAQ

In my joyous travels developing a fun little iPhone game recently, I kept track of all the many tips and tricks and gotchas I came across. There are a fair few bugs in Apple’s IDE (including at least one critical one that bit me), some stunningly bad flaws in the Objective-C language (it’s *horrible*), and some slightly surprising lack of docs from Apple in key areas (like: how/when do I get paid?)

There was too much to blog it all, so instead I installed a free FAQ software and I’m gradually transferring my notes over to this FAQ (only got a few questions in there at the moment, just fresh installed):

http://iphonefaq.t-machine.org/index.php?action=show

(the one you probably want to start with is: How to make applications for the iPhone?)

There’s an awesome feature to this FAQ too (not that I’ve tested it): anyone can go to the site and click “Ask a Question” and it gets added to a list for admins to answer and post. You can even answer your own question at the same time as asking it.

If you’ve been developing iPhone apps yourself and have some burning questions or neat tips of your own, feel free to go to the FAQ and add them in. Any problems, email me (email address is on the About link at the top of this page)

Categories
dev-process programming recruiting startup advice

Google cutting 20% time

Oh, wait, actually they’re not. But people love to misinterpret statements with the word Google and the number 20 in them.

As I put in the comments:

Frankly, I’ve generally not bothered to correct anyone who didn’t bother to research it themselves – except in the cases where they were in my own organization, and attempting to make decisions about related matters based on misconceptions of the supposed Google rule.

Of course, my dear lovely friends may have been lieing to me. I very much doubt it (and even if I didn’t, what they’ve said over the years has made a lot more sense than most of the hearsay you hear on the web) – but the point here is that I’ve bothered to ask.

Google has so many employees that if you preach on subjects like 20% time – which, by the way, I think is one of the most fundamentally important (and least well-understood) issues in corporations, job choice, and why you get up in the morning, but that’s another post – then you have no excuse at all for not going and asking an employee how it works. Last time I looked, they had bajillions of offices around Europe, not to mention the sprawl all over the US.

Categories
dev-process iphone massively multiplayer mmo signup processes programming

iPhone: why’s my download stuck at 1.4 of 1.6 Gb?

Your possible answers include:

1. Because … Apple engineers have never heard of the concept of a “patch”, and require you to re-download the *entire IDE*, with all libraries, all documentation, all binary code – everything – when they release an update? So the current “SDK” for iPhone (hint for Apple: when most people say “SDK” they don’t mean “plus a copy of a bloody operating system”, they just mean “the few custom bits that are specific to that app”) is a whopping 1.6Gb?

[NB: actually in general I think that’s a good thing – avoids a lot of mis-configuration / version mismatch problems – but as an MMO developer the idea of *not* patching gigabyte-sized packages horrifies me, and avoiding those problems actually isn’t THAT hard (it’s been solved many times by now!) these days. Writing (or buying) a good patcher is one of the first steps you do in MMO dev projects…]

2. Because … Apple didn’t think to split The Behemoth into multiple files, perhaps make them something reasonable, like a few hundred meg each?

3. Because … Apple decided to put this monster behind an authentication check on their website, presumably for legal reasons, and there is no other “official” mirror (all the ones you find on google are technically-illegal torrents or else, ultimately, redirect you back to the apple.com link), and their authenticated sessions TIMEOUT after 1 hour of “not fetching any new pages from the site” (completely ignoring whether you have any transfers in progress!), and refuse to send you data once your authenticated session runs out?

4. All the above?

NB: I wasn’t brave enough to try resuming the downoad without first re-authenticating and loading at least one web page from the apple developer site to prove I was logged in. I suspect (*suspect*) that the web browser would receive an HTTP 300 redirect to the login page, at which point most browsers are going to delete the partial download. Ha. Haha. HAHAHAHAHAHAHAHAHAHAHAAARRRRRRGHHH!.

Expect to see some comments/tutorials/advice on iPhone game development here at some point in the near future. If I can ever get the download to complete…

Categories
agile dev-process games industry

What are the core competencies that every producer must possess?

Lots of ideas and detailed explanation from games industry Producers and production staff on the IGDA Production mailing list here.

Unfortunately, I’m afraid that the people who run the Production SIG don’t believe in allowing you – the public – to read their conversations. So all I can do is tell you that there’s good stuff that would probably help with improving the quality of the process in the industry – and hence improve the quality of life of everyone involved – and give you a link to go and apply to be allowed access to this secret world.

Sorry. Good luck with justifying your existence enough to be allowed in; I hear they are pretty generous with it (hey – they let *me* in :)), so you should be fine, I think.

(“IGDA: hiding information that would help people break-into the games industry, or improve their own level of professionalism, since 2004
“)

PS: because it’s password-protected, and uses random passwords, I can’t even get hold of the direct link to the emails in the archive – I have to wait for their mailman server to give me my password. That can take several hours (I know there’s nothing they can do to improve it: I run one of the other lists on the same server, and have the same problem :( ), so I’ll edit-in the direct link if/when my password arrives)

Categories
computer games dev-process mmo signup processes Web 0.1

Web 0.1: How NOT to run an open beta stress-test

1. Ask people to join the closed beta 6 months before the open beta happens

http://www.kongregate.com/forums/1/topics/8117

Dinowaurs Beta Testers Wanted

We’re now inviting Kongregate members to sign up to test the Dinowaurs Beta. If you don’t know what Dinowaurs is, go here for more info: http://www.kongregate.com/forums/1/topics/3350.
Simply pop in to this thread and say that you want in and I’ll put you on the list for the test. Please, no conversations, as it makes it more difficult to pull all the names out.
We’d like to thank everyone who helped us test the alpha! Anyone who signed up for the alpha in the previous thread will be first in line, so no need to sign up again if you already did in the alpha thread.
Thanks, everyone!

(posted may 1st 2008)

2. When you start an open beta, don’t tell players they’re accepted until 2 days before the beta happens

Hello!

Thank you for volunteering to test Dinowaurs, an upcoming game on Kongregate. As of this email, everyone who volunteered to help test Dinowaurs will now get a chance to do so. We’re very grateful for all your help!

For those of you who have tested before, this is a different request than usual, and for all you new faces, welcome! What we need to do is load test the server – that is get as many feet stomping on it as possible and see if it crashes! Because of that, we’re going to try to stuff as many testers into the game at one time as possible. For this test, Dinowaurs will only be open on Monday, November 17 from 12 noon-2pm Pacific Time (All you non West-Coasters, take notice of the time!)

So we hope to see all 4000 of you Dinowaurs beta testers in here and playing the game on Monday! Don’t be late – our doors will close tight at 2pm.

Thanks again!

Kongregate and Intuition

3. Make it last 2 hours only

(Fair enough, normal practice for stress tests, although it’s usually a good idea to let people in a few days in advance to ensure that they have working clients etc (less of an issue for a web game like this, but still probably worth doing).)

4. Don’t tell anyone the secret link to the beta

Read that email again. Do you see the magic URL? No? That’s because THEY FORGOT TO INCLUDE IT.

Some googling turns up various people asking for it, and some friendly Kong players answering with the URL here:

http://www.kongregate.com/games/flamingbait/dinowaurs

EDIT: they just sent another email which remembered to include the link.

Hello!

Today’s the day! At 12 noon Pacific Time (3pm Eastern), the doors to the Dinowaurs Beta on Kongregate will be flung open!

At that time you should make sure you’re signed in to Kongregate and go here to test: http://www.kongregate.com/games/intuition/dinowaurs-beta_preview

Make sure you’re on time! We will be closing doors promptly at 2pm (PST). If during gameplay you encounter any bugs, please click on the little bug icon at the top right of chat and fill out a bug report. The more actual bugs you find, the better the game will be!

We really want to thank all you beta testers. We really appreciate all your help!

Kongregate and Intuition

Could be they intended this all along. Given that the beta starts less than an hour after that email was sent out, I doubt it :).

Categories
community computer games databases design dev-process games design games industry massively multiplayer network programming programming recruiting

MMO Blogger Round-up

On this site I have a rather subtly-hidden Blog Roll. When I started blogging, the site had less on it, and the roll was easy to find – and short. Now it’s not. And it’s long. And each link on there has been carefully considered. There’s some gems in there (although a lot of them are updated so infrequently few people track them).

So it’s time to call-out some of the interesting things to be found in the blogging world of MMO people.

By the way … you can tell who’s working on uber-secret or personally exciting projects these days because they’ve suspiciously stopped blogging for months at a time. Lazy slackers, the lot of them. The more you do, the more you should blog! :P

There are some that should be on the blogroll but aren’t (yet), and some other bloggers I should mention (but I’m sticking to the blogroll only for this post – I’ll go through others next time). Feel free to add your own recommended reading in the comments.

Blogs to read:
Brinking (Nabeel Hyatt)
* Who? serial entrepreneur, raised funding and sold companies
* What? currently running a funk-tastic social / music / games company with a bunch of Harmonix guys
* Why? big commentator on the games/apps/making money/predictions parts of All Things Facebook

Broken Toys (Scott Jennings / LTM)
* Who? became infamous in the early days of MMOs as a player of Ultima Online who ranted publically, amusingly, and sometimes even insightfully
* What? ex-NCsoft, now doing intriguing web games at John Galt Games
* Why? In his heart Scott’s still a player, and more than anyone else I’ve seen he interprets the world of MMO design, development, and playing through the players’ eyes. Interesting point: he’s mostly concerned with life-after-launch. Funny that. Players kind of find that bit the most interesting. Also keeps a close eye on community-management screw-ups, and WoW generally

Bruce Everiss
* Who? ex-head of marketing for Codemasters
* What? um, I’m not sure what he’s doing these days, apart from becoming a “professional blogger”
* Why? he aims to comment on every single interesting piece of news in the mainstream games industry. That’s a lot of commentary. Always something to read! IMHO he is often completely wrong about anything online-games, and a lot of business and “future of industry” stuff – Bruce is from an older age of the industry. But … he says a lot of interesting things and sparks a lot of interesting debates in the process. Worth reading. Just remember he is extremely (deliberately, I’m sure) provocative, and don’t take it too seriously.

Coke and Code (Kevin Glass)
* Who? A programmer working in mainstream IT
* What? An insanely prolific author of casual games “in his free time, as a hobby”
* Why? Because he’s better at making games than many professionals I’ve met, and he is very very prolific, making new libraries, toolsets, editors, games, game engines – and commenting on it all as he goes, and throwing up new games for you to play all the time

Erik Bethke
* Who? ex-Producer for Interplay
* What? CEO of GoPets, an online casual virtual world that’s especially big in Asia (and based in South Korea)
* Why? A hardcore WoW player who analyses the game-design as he goes, and relates very honestly a stream of both emotional experiences and seminal events in the game that should give you lots of things to be thinking about, especially if you’re a designer, business person, or product manager.

Extenuating Circumstances (Dan Hon)
* Who? ex-MindCandy, current CEO of SixToStart
* What? one of the first Bloggers (on the whole of the internet!) in the UK, and an awe-inspiring assimilator of “everything happening on the internet, with technology, with media, with entertainment and the future of the world” for all of the ten years I’ve known him.
* Why? He’s still an excellent tracker of all those things, and finds memes very quickly. Nowadays he just auto-posts links (lots of them, every day) with a few words of commentary scattered here and there (del.icio.us descriptions) – making his blog a ready-made news filter for you :)

Fishpool (Osma Ahvenlampi)
* Who? CTO of Sulake (makers of Habbo Hotel)
* What? a very technical commentator, often in great detail, on the issues of running a 100-million user virtual world, with observations about Habbo’s community, business, and culture thrown in
* Why? He posts very rarely, but when he does, they’re usually full of yummy detail

Futuristic Play (Andrew Chen)
* Who? ex-VC (Mohr-Davidow Ventures)
* What? entrepreneur with a web-background who’s come into the games industry and bringing lots of useful stuff with him
* Why? blogs a LOT on advertising (and how to make money out of it in games and web and casual), and on metrics, and how you can use them to run you games or web business better. Also has a long fascination with what are the best parts of the games industry, and the best of the web industry, and how we can each put those best bits together to be even better

Off the Record – Scott Hartsman
* Who? ex-Everquest, ex-Simutronics
* What? Senior Producer for MMOs – but previously an MMO lead developer, and once (apparently) a Game Designer.
* Why? he’s funny, he knows his stuff, and he’s worked on some of the most important MMO projects outside Asia, so he’s got an interesting perspective going there.

Orbus Gameworks (Darius Kazemi)
* Who? ex-Turbine, now CEO of Orbus (a games-metrics middleware company)
* What? Likes the colour orange *a lot*, infamous for networking his ass off at games conferences (*everyone* knows Darius), very friendly, generous – and mildly obssessed with the use of metrics and stats to improve the creativity and success of game design (in a good way)
* Why? If you liked the Halo heatmaps when they came out, you’ll love some of the stuff they post on the Orbus company blog. A year ago they were posting heatmaps-on-steroids. If you thought “metrics” equalled “spreadsheets of data” then prepare to have your view changed pretty thoroughly.

Prospect Magazine/First Drafts (Tom Chatfield)
* Who? section-editor of the highly respected socio-political print magaine Prospect
* What? a highly-accomplished English Literature post-grad (bear with me here) … who also happens to have been a lifelong hardcore game player, I think the only person I know who got a hardcore character to level 99 on Diablo2, and now plays WoW a lot.
* Why? although Prospect only very rarely (like, only a few times ever) covers games, it’s very interesting to see what the rest of the world – especially the highly educated and highly intelligent but non-technical, older generations – thinks of us. And a bit of culture in your blog reading is probably good for you, too.

Psychochild (Brian Green)
* Who? ex-3DO/M-59, now the owner and designer of the revamped, relaunched, more modern Meridian-59
* What? an MMO game designer who disingenuously describes himself as an indie MMO designer but like most of the others has probably spent too long doing this and knows too much (compared to many of the modern “mainstream” MMO designers) for that to be true any more
* Why? lots and lots of great design ideas and commentary here for anyone wanting to do MMO design

Scott Bilas
* Who? programmer on Duneon Siege
* What? …in particular, responsible for the Entity System (one of my main areas of interest)
* Why? Scott’s phased in and out of blogging, but when he does blog he tends to do good meaty programming posts that contain lots of source code and some useful lesson or algorithm.

Sulka’s Game (Sulka Haro)
* Who? lead designer for Sulake (Habbo Hotel)
* What? more of a Creative Director than game designer, more of a web background than games, but above all a community/product/creative person who knows his stuff. Also a big player of MMORPGs
* Why? are you cloning Club Penguin or Habbo Hotel and want some pointers about revenue models, community management, and how to be successful with virtual-item sales? You might want to read his posts ;)

The Creation Engine No.2 (Jim Purbrick)
* Who? ex-Codemasters, ex-Climax (both times working on MMO projects)
* What? originally a network / MMO academic researcher, then a network coder, and now the person who runs Linden Lab (Second Life) in the UK. Very big proponent of all things open-source, always doing interesting and innovative things with technology
* Why? Keep an eye on the more innovative technology things that are done with Second Life (stuff you don’t tend to read about in the news but – to a tech or games person – is a heck of a lot more interesting by a long long way), and get some insight into the life of serious open-source programmers who succeed in living and breathing this stuff inside commercial environments

The Forge (Matt Mihaly)
* Who? developer of one of the earliest commercially successful text MUDs, now CEO of Sparkplay Media
* What? spent many years running Achaea, a text-only MUD that made a healthy profit from pioneering the use of itemsales (virtual goods) – and the things weren’t even graphical – and has now finally (finally!) moved into graphical games with the MMO he’s developing
* Why? one of the few MMO professionals who talks a lot about his experiences playing on consoles (especially Xbox), which makes for a refreshing alternate view – especially from the perspective of an MMO person talking about social and community issues in those games. Just like Brian Green, claims to be an indie MMO designer, but probably knows far far too much for that to be even vaguely justifiable

Vex Appeal (Guy Parsons)
* Who? ex-MindCandy
* What? Guy is an extremely creative … guy … who had a small job title but a big part in inventing and rolling out a lot of the viral marketing stuff we did for Perplex City (online game / ARG from a couple of years ago)
* Why? Awesome place to go for ideas and info on the cutting edge of doing games stuff with social networks. Usually. Also … just makes for a fun blog to read

We Can Fix That with Data (Sara Jensen Schubert)
* Who? ex-Spacetime, currently SOE
* What? MMO designer, but like Lum / Scott Jennings, comes from a long background as player and commentator, and shorter background as actually in the industry. Like Darius Kazemi, spent a lot of time in doing metrics / data-mining for MMOs
* Why? Take Darius’s insight into metrics for MMOs, and Scott’s knowledge of what players like, don’t like, and ARE like, and you get a whole bunch of interesting posts wandering around the world of metrics-supported-game-design-and-community-management. Good stuff.

Zen of Design (Damion Schubert)
* Who? ex-EA (Ultima Online), currently at Bioware (MMO)
* What? MMO designer who’s been around for a long time (c.f. UO)
* Why? Damion writes long detailed posts about MMO design, what works, what doesn’t, practicalities of geting MMO development teams to work together, how the playerbase will react to things, etc. He also rather likes raiding in MMORPGs – which is fascinating to see (given his heavy background as a pro MMO *designer*)

[NC] Anson (Matthew Wiegel)
* Who? ex-NCsoft
* What? Dungeon Runners team
* Why? was doing lots of interesting and exciting things with data-mining/metrics in the free-to-play low-budget NCsoft casual MMO. Watch this space…

People with nothing to do with games, but you might want to watch just because they’re interesting:
Bard’s World (Joshua Slack)
* ex-NCsoft
* Josh is one of the key people behind Java’s free, hardware-accelearted, game engine (JME)
Janus Anderson
* Who? ex-NCsoft
* What? um, he’s been taking a lot of photos recently
* Why? watch this space
Mark Grant
* Who? non-Games industry
* What? an entrepreneur, web-developer, and Cambridge Engineer
* Why? very smart guy, and interesting posts on web development (no games tie-in)

Categories
computer games conferences dev-process security

RSA Conference 2008 (London)

I’m there now, drop me a line (see About page for email) if you’re around.

I’ve just given a quick presentation introducing the ENISA’s (European Network and Information Security Agency) whitepaper on “Security and Privacy in MMO’s and VW’s”. It’s free, and it’s fairly simple (aimed at everyone from consumers to governments), worth a read if you’re interested but relatively new to this stuff. Contributors include people from Sulake (Habbo Hotel), CCP (EVE Online), NCsoft, and people like Richard Bartle and Ren Reynolds.

Categories
dev-process facebook games design games industry web 2.0

Cultural differences: game developers vs web developers

Andrew Chen has just written a post comparing the cultural differences between Web industry people and Games industry people. They’re all very interesting, and on the whole I’d say they’re on the money – definitely worth reading (and see if you can spot yourself in some of the either/or’s ;)). At the start of the post, I stopped reading and paused to list my own observed differences, so that I could then compare them to what Andrew had written. There was no overlap, so I thought I’d write them up here.

Cultural differences: game people vs web people

  • concrete revenues vs “future monetizable” growth
  • team-as-blob vs sliding scale of headcount
  • obsessive search for fun vs time-wasting activities
  • surprise and delight audience with something we liked and think they want vs randomly guess and test on live audience; iterate until done
  • very high minimum quality bar vs dont worry, be crappy
  • high, strict specialization vs almost no specialization
  • money happens elsewhere, far down the chain vs show ME the money

concrete revenues vs “future monetizable” growth

Largely driven by the “money happens elsewhere” part, game people are obsessive about “what’s the actual revenue this will make (what’s my percentage of the revenue this will make)?”.

In particular, if you cannot *prove* the expected revenue (and in many cases not even that: instead you have to prove the *profit*), they won’t even carry on the conversation. This happens everywhere from small startups to massive publishers. I’ve seen meetings on “social networking” get shutdown by a senior executive simply saying “how much profit will this make at minimum, even if it’s not successful? Remember that these resources would instead bring in an extra $5million if we deployed them on [one of our existing MMOs]”, and refusing to carry on the meeting unless someone could prove that the opportunity cost to SN didn’t exceed its income.

surprise and delight audience with something we liked and think they want vs randomly guess and test on live audience; iterate until done

A team of game people sets out to make something fun. They like to get some input from experts on analysing and predicting the market (market researchers, marketing departments, retail executives, industry analysts, etc) – and then use that merely as “inspiration” and “guidelines” to making something awesome and new. They assume that “the customer doesn’t know what they want, but will recognize it when they see it, and fall in love” (which is largely true!), and so they go off and build something beautiful largely in isolation.

This beautiful thing then surprises and delights the consumer when it finally comes to market.

Web people do the first thing that comes to mind, care not whether it’s objectively good or bad, and test it in the market. Then they try again. And again. And again. And look for patterns in what is popular or not.

As a result, game people tend to think of web people as “skill-less” (partly true) and “puppets of the market” (largely true). Meanwhile, web people tend to think of game people as “perfectionist” (largely true) and “monolithic / unagile” (largely true) and “non market-lead” (partly true).

obsessive search for fun vs time-wasting activities

Game people don’t make stuff unless it’s fun. If it’s not fun, it’s a failure, and only a stereotypically bad EA Producer (or a second-rate clone) would OK the ongoing funding and/or production of a project that wasn’t fun any more.

Web people generally couldn’t care less. They generally think they want stuff to be fun, in a “well, it’s better if it’s fun, isn’t it?” kind of way – but they usually only really care that there is some activity going on, and that the users come back to do more of it. They are less judgemental about the type and motivation of activity going on. They will slave away to try to understand this activity, to extrapolate better ways of motivation people to do more of it, and to monetize people for doing it, but the activity could be selling used cars or real estate and they would not be greatly affected.

This one even shows up subtly in Andrew’s own writeup – he casually uses the word fun. To game developers, the word is Fun, and they would never write:

Now, I think that the productivity-inclined have their claim to the world, as does the fun/entertainment games people. But the intersection of this, in web media, is where the fun happens.

…because you don’t use the word “fun” casually like that where someone might hear it as “Fun”. You are sensitized to all uses of the F word :). Fun would never come from an intersection like that; that intersection could give rise to a number of side-effects and new content areas, and those content areas – with appropriate rulesets imposed – could merge, and react with some of the side-effects, to give rise, finally, to something “Fun”. Fun is not a simple concept.

very high minimum quality bar vs dont worry, be crappy

Game companies have QA departments that are larger in headcount than the entire development team, often by a substantial margin. They don’t ship stuff that is half-arsed, partially complete, partially working, etc. Hence, when they do, there is huge press and consumer attention around it. This is one of the thigns that the games industry has been doing more and more web like over the past 10 years – ever since they realised they could drop some launch-quality and end up with the same level of quality as standard by shipping a “patch” 1-3 months after launch (and probably getting an uptick in sales as a result, re-box the patched version as an “improved” version).

But, on the whole, games companies still consider quality the one unassailable pillar of the development triangle (“quality, short development time, cheap development cost – you can only have two at most”).

In fact, most game people turn “Quality” into 3 separate sub-pillars: core fun, longevity, and polish. And consider all three inalienable, but occasionally flirt with sacrificing one of those three instead of sacrificing either of the two other full pillars.

If it strikes you that the games industry is thereby trying to cheat and get “2 and 2/3 pillars out of 3” then … you’d be right. Understanding this can help explain a lot both about individual games and the industry in general over the past 15 years.

high, strict specialization vs almost no specialization

A game team is (typically) made up of distinct people doing:

  • Art
  • Code
  • Design
  • Production (project management)

You need at least one person devoted to each. For teams of size less than 5, it’s acceptable to have some people do two of those roles rather than just one, but it’s often considered “hard”
(by default – although in practice many teams flourish with people moonlighting/two-hatting these roles).

It is an onrunning joke that various non-design people in games companies have the unofficial job title of “Frustrated Designer” (most usually Producers and Programmers get labelled with this). i.e. someone who secretly wants to be a designer, but lacks the skill and experience – despite potentially many many years working in their person discipline, developing and launching games. Nowadays you also see people labelled as Frustrated Artist, and occasionally even Frustrated Programmer (although anyone brave enough to do that in the face of the programmers, who tend to be quite bullish about welcoming such people to try their hand at fixing a code bug (snigger, snigger, watch-him-fail) generally is quickly disabused of their frustration).

There’s good reason for this, too – the expected level of skill from anyone non-junior in a game team is sufficiently high that it can be very difficult for people to cross skills. It’s easy if they’re willing to drop to “junior” status (the level of incoming recent-graduate – very low-paid, and with very little creative or project input/control), but few are willing to take the massive drop in status and (usually) pay to do that.

money happens elsewhere, far down the chain vs show ME the money

Interestingly, perversely, this means that game people obssess about the money, despite never seeing it themselves, and worry about how their actions will affect the ability of later people in the value chain to make money, and how much the total pot will be.

Whereas the web people generally are much more blase about the money side, because they know it’s going to come almost directly to them, and they have a much more direct relationship with it (understand the ups and downs).

Game people’s approach to money is generally characterized by Fear, Uncertainty, and Doubt – plagued by rumour. Web people all know for themselves how much money can be made, and how, and don’t peddle in rumours.

Comments on Andrew’s observations

Andrew’s observations were all good, except for one thing which I think he misunderstood: “By withholding levels, powerups, weapons, trophies, etc., it creates motivation from the user to keep on playing. They say, “just… one… more… game…!!””.

…and then he makes a conclusion that makes sense given what he and wikipedia have said, but which is almost the precise opposite of the truth.

As a result of this treadmill, there is a constant pressure for players to stay engaged and retained as customers. But the flipside of this is that it’s not enough to build one product – instead you build 70 product variations, and call each one a level!

The truth is that content-gating was introduced and/or stuck around as a technique because the cost of creating content is exponentially higher than the cost of consuming it without gating. If you have decided to operate a content-centric game, you are doomed to be unable to run a service product based on it – no matter how many years you spend developing content before launch, your playerbase will soon catch up to your level designers etc and overtake them. Content-gating, levelling especially, forceably slow players down in their content consumption rates, even forcing them to re-play set pieces of content many many times (if you can get them to replay it enough, you can lower their rate of consumption to the point that a sufficiently large team of content-creators can keep ahead of them. Just).

Various other experiments have been tried over the years – most notably, User-Generated Content, but none have achieved the same level of efficiency (or yet been as well understood) as level-based content-gating.

Categories
design dev-process games design massively multiplayer

MMO do’s and don’ts: Launching an MMO

Thord Hedengren (TDH) posted for GigaOM a list of things you should and shouldn’t do immediately after launching an MMO. They are mostly specious – I’m afraid I have no idea who Thord is or what he’s done, but from reading the article I get the impression he doesn’t know much about MMOs. Now, I’m sure TDH is a nice person, probably very smart, but these dos/donts are naive and ill-thought-out to anyone who’s been working in the MMO field for long. Some of TDH’s advice will probably cause you more harm than good if you follow it as-written.

What’s wrong with TDH’s list:

“Make sure the game is stable” – the games that launch “prematurely” (TDH’s description) ARE stable. Perhaps he meant something about “works on the majority of machines of your target market” or “has no economy-breaking bugs” or “all the quests work out of the box”, or … or … or etc. Depending on what he meant, my response would go in different ways.

If I were him, I’d have said “make sure the game is READY”, but whilst I know what that means, and most people in NCsoft seemingly had mostly congruent opinions, that’s not something I’m sure I can quantify off the top of my head. Hey, it’s part of what good publishers do as their value add, it’s not supposed to be obvious! More on this later, maybe.

Include significant content for all levels – you cannot possibly afford to do this, and it’s NOT ENOUGH even if you could. Rather, you need to provide masses of highly polished content for two particular levels: level 1, and level 20. Levels 10 through 19 need increasingly polished levels of content. Here I’m assuming that level 10 is the end of the newbie experience, and level 20 is the highest level 95% of the playerbase will reach within 1 month of starting play EVEN USING THOTTBOT et al to cheat their way through content faster.

Why? Because you lose subscribers at two points:
1. When they start playing.
2. when their first month subscription comes up for renewal.

All players should have completed the newbie experience (level 10) before their first subscrption renewal. From the moment they complete that, you want them to be more and more surprised, in a positive way, by how much “better” the game gets the longer they play. You also want to offset the decreased sense of wonder they have as individuals as they get to know the game and the world, so that they perceive a linear, constant, level of content quality (when in fact the content quality + volume is increasing, but their expectations are also increasing).

“Add new content on a regular basis” – like the outcome of a negotiated sales price (which can never go further in the vendors favour on future re-negotiations), whatever rate of content release you provide, you can NEVER reduce that rate in future, your players won’t let you. So DEFINITELY do not go around adding the “frequent” chunks at first that TDH recommends. That may well be suicidal.

“Make it easy for players to network, form guilds” – don’t bother. They will do it anyway. No MMO in existence has bothered to make this easy, and so the players have become adept at doing it themelves. This feature is therefore a complete waste of money – UNLESS you decide to make it a major competitive feature/advantage which becomes part of your sales strategy. Given how few MMOs do it even at a mediocre level or above, you could easily get great sales out of doing it well.

“Let players move characters between servers” – except that this destroys server-level community – something that all the big MMOs make heavy use of today. IMHO, the benefits to character-transfer outweigh the losses, ASSUMING you know what you’re doing and make use of those benefits, but TDH’s explanation (by omitting these) is probably going to lead many into weakening their game instead of strengthening it.

“Keep an open dialogue with the players” – Yes! This I agree with. Good recommendation.

So, just one of TDH’s points actually works without large amounts of hedging. Hmm. What about the “don’ts”?

What’s wrong with TDH’s list part 2: “Donts”

A general observation here: these have almost nothing to do with the realities of launching or post-launching an MMO; rather, they read like TDH’s personal bugbears of what he wishes that his MMO of choice did differently. I would humbly suggest that GigaOM is not the place to be airing a random selection of your personal criticisms of minor elements of someone else’s game-design (my personal blog, on the other hand, is an AWESOME place for me to be ranting about the quality of articles on other people’s sites. HA!). I’m only going to go through them for the sake of completeness, but mostly I’m not going to bother analysing them, they’re too trivial.

“Don’t promise features that are months away” – what TDH should have said was “in the management of online communities, Expectation Management is one of your core activities. This is also try of all mainstream AAA game development, just do what you would normally (not) do with a mainstream game”.

“Avoid having portals to future places” – this is just the same as the previous point. Nevermind.

“Don’t rebalance the game too much, too fast” – Hmm. Apart from directly contravening one of TDH’s “Do” points (“frequent updates and changes”) – what does TDH think updates are? Every update rebalances the game, de facto – “breaking [players] characters” is probably a good thing rather than a bad thing, as it extends the content for them (rebalancings can be the impetus for players to create an alt (second character) for the first time ever, and thereby increase attachment / stickiness for mass-market (non hardcore) players). Just don’t do an SWG NWE (if you don’t know what that is, google it – it was an extinction-level event in the Star Wars MMO that has masses and masses of commentary and post mortems all over the web).

“Publicly acknowledging problems” – Yes! Again, TDH’s final point actually has merit. Do it. It helps. But then again, this is nothing surprising – this is, in fact, part of that basic community management I referenced above.

Fine. “So, Adam”, I hear you ask, “if you’re so damn clever, what ARE the do’s and don’ts of launching an MMO, especially with respect to the post-launch period?”

Since I am currently technically unemployed – doing a Super Sekrit Stealthy Startup – I should really just put a PayPal donation link >HERE< and/or my cell number and an offer to answer your question (and any others you may have) at a discounted $100 an hour.

Launch Period: What Really Counts

For a subscription-based MMO (the target that GigaOM chose), two things count above all else:

  1. Absolute number of registered active accounts
  2. Conversion rate of registered accounts to subscribers who make one monthly payment IN ARREARS (i.e. one payment at end of month, or two payments at starts of months)

There’s some extra things that matter, because you NEVER launch an MMO in isolation – there has always been months or years of development leading up to this, and at least an alpha, if not two or even three betas, before launch:

  1. Retention of final beta (usually “free”) accounts that convert to paid subscriptions

I’ll come back to all three of these in a later post – I’ve been meaning to write something up about this stuff for ages now, but I don’t have the time this instant to do it justice.

As a parting shot, though…

Big Background Question Number 1

Ask yourself (and your team) this:

Do you even know what an MMO launch is? A pre-launch? A post-launch? A live team?

…and think about it; a lot of people these days don’t stop to think about the knock-on effects of that question, and there’s really no excuse now – there’s so much evidence staring you in the face, in the form of many many MMO launches that have happened. If you can’t answer those questions – and understand the menaning behind them – go do some research ASAP before you get even close to launching.

It’s easy to gloss over the launch, think it’s a one-off special event you plan for, just like alpha, or beta. It’s easy to forget some of the complexity that is peculiar to launch. We had people at NCsoft (both external developers and internal staff) who failed to include the live team as part of the budget for their games. Live team is going to be anywhere from 50% to 150% of the size of the develoment team. Since dev team staff are the majority of the project cost, failing to budget for live team is a MASSIVE hole in your budget. There are games that have launched with live teams as low as 30% (I think there’s some that were even like 10% but I can’t remember any off the top of my head) of the dev team; they failed.

Damion Schubert came up with the term “AO Purgatory” (AO = Anarchy Online) to describe live teams with just enough income to pay for upkeep, bug fixing, etc, and a few bits of content upgrade – but not quite enough to add enough content, fix enough bugs, to cause the overall subscriber base to grow significantly month-on-month. Rule of thumb: I would never launch a game without a live team that was the same size as the dev team if I could avoid it. If I had someone else’s cash to burn, I’d budget for live being 125% size of dev.

Categories
databases dev-process games design massively multiplayer server admin web 2.0

Web Analysis Tools: what’s free?

This is a quick review of free tools for web analytics / stats-analysis / weblog analysis. I’ll follow up with some more detailed posts about non-web tracking. Follow-up posts will extend this into game development, but this post is purely about web stuff.

Categories
dev-process games industry recruiting startup advice Uncategorized

What’s the future for Game Development Studios?

(this is part 2 of Publishers are from Mars, Developers are from Venus)

Last time I said that “good Developers are very similar to Valley Technology Startups”, which suggests one obvious way things could develop:

Publishers to become Venture Capitalists; Developers to become commodities

In this model, the Publishers spend their time “speculating” in Dev studios: instead of buying a studio in order to own the output of that studio, you buy it with the intent of later selling the studio itself at a profit.

This is a good model; as I first heard from Jack Lang, at one of the Cambridge Enterprise Conferences many years ago:

“The best way to get rich is by buying and selling things. Preferably companies”

IIRC it’s a quote that’s been around for a long time, but I can’t remember where the original quote came from, unfortunately.

(of course, this observation is why Publishers are box-shifters in the first place: simply buying and selling things is an easy, fast, stable, sustainable way of making a very large amount of money. It’s not particularly creative, perhaps, but it’s a very efficient way of generating profit, and lets you leverage your resources/cashflow way above the profit you would generate simply from manufacturing your own goods and selling them)

The real beauty of this is that – as Jack’s quote illustrates – a Publisher and a VC have very similar fundamental business models: they buy stuff that they have no intention of using themselves primarily to sell those things at a profit to other people. In both cases, the less time the company can hold onto the products, while getting the same price differential between purchase and sale, the better. What is a VC? A VC is just a higher-value version of a box-shifter. So, for a Publisher to diversify into being a VC may not be so difficult…

As someone who’s been through the mill of raising finance for startups before, I’d also like to add that “funding game development” is commonly thought of as having no equal in risk and unpredictability – save “providing venture capital for a new startup”. The hardest part of being a VC – the insanely high risks involved – is bread and butter for Publishers, who routinely spend tens of millions of dollars on stuff they don’t understand, cannot effectively control, and cannot reliably predict!

Studios would find that:

  1. Publishers would look after them more – you don’t want to harm something you’re planning to sell
  2. Funding and marketing decisions would be driven more by what was in the interests of the studio rather than the Publisher’s marketing dept or cashflow
  3. Publishers would stop being stupid about trying to “reduce costs” of development purely for the sake of it
  4. Publishers would be a LOT more interested in supporting and creating external partnerships for the studio, especially where those partnerships involved competing publishers or their subsidiaries (because that would make it easier in the future to sell the studio to that competing publisher), which would help reduce development costs (a little) and increase productivity / quality of working environment (probably a lot more – publishers usually consider this too little justification for allowing such things)
  5. If the publisher got cold feet about publishing a certain game and it was far advanced, they would push for POSTPONING it rather than RUSHING it – they’d rather sell the studio BEFORE it publishes the game, and “price-in” the potential of the game than sell AFTER the game had launched and flopped
  6. The publisher would push harder for maintaining quality standards of the games output by the studio – they have literally invested in the brand of the studio, a brand they are planning to build up in value as much as possible, before selling

Publishers would find that:

  1. Development costs would no longer mar their balance sheets and make their financial performance look bad; the offset of being able to mark the studio as a sellable asset with a quantifiable value in excess of the money being poured into it would make it all smell sweeter to shareholders
  2. There would be less friction with studios, leading to better communication, less frustration, and probably better overall quality of product – and hence, more profits
  3. Studios could safely be given more leeway to make strategic business decisions that were “right for them”, offering the possibility of mega-wins for the publisher whenever those paid-off (e.g. the decision by early FPS developers to not only allow but encourage modding was enough to terrify publishers even today, and yet a massive win in sales and profits), but also to not have to take responsibility – and blame – when they failed; this would all be priced into the “value” of the studio as a separate, tradeable, entity
  4. If a studio made some bad strategic decisions that led to commercial failures, that might actually INCREASE its tradeable value, if the market perceived that the studio had “learnt” significantly from the mistakes; potentially, such increased value could completely offset the actual financial losses incurred from the mistake

A practical example

I’m just pulling this out of thin air, trying to think of a studio that many years ago was worth something, got acquired, went internal, and now is probably worthless. When EA bought Westwood Studios, one of the things they paid for was the brand; how much value did they really extract from that brand? How much value does it have *today*? Today, it’s probably next to none – customers don’t care, and other games industry companies all know that the real meat of Westwood Studios (the staff, the equipment, the processes) was disbanded shortly after being bought by EA. Could they have made more money by promoting and protecting the WS as an owned-but-independent studio? If they’d taken that route, and even if they had made less money than they have with the route they chose, would it be more than made up for by the fact that they might be able to sell WS right now for, say, a couple of hundred million dollars – if only it still existed as more than a name?

And why not?

But this isn’t the way Publishers work right now, so … where does this plan all go wrong? Why hasn’t it happened already? What might prevent people from trying this?

1. Cojones

At the moment, the funding decisions that Publishers make are so distantly removed from the actual point of capitalizing on them that it’s quite easy for the people making the funding decisions to blame many other departments and personnel within their organization should the investment go poorly. Indeed, this plausibly deniability, this easy abrogation of responsibility by the decision makers – and the great distance between them and the people actually implementing the game – are root causes of a lot of the practical problems in the Publisher/Developer relationship whenever they do “external” publishing (i.e. publish a game made by an independent / external studio, as opposed to a wholly-owned internal studio).

A lot of the benefits for the New Way cited above stem from removing that indirection; that means a bunch of people making hundred-million-dollar decisions would be exposed to rather more scrutiny and responsibility than they hold right now. I’ve heard people (usually the ones who don’t really understand VC’s, have acted naively or foolishly with them, and come away poor and bitter) describe VC’s as “arrogant”, “bullies”, and “too demanding”; while I don’t agree with that, just think how you’d act if you were the named individual responsible for a handful of $10million investment decisions, and how that might come across sometimes. Could the individual people working for Publishers accomodate such a change? If they were content with that level of personal exposure to risk, would they be working in the games industry, or would they already be working in the higher-paid VC industry?

2. The Art of the Sale

Another issue is that the success of selling a studio depends on, well … your ability to sell!

Publishers do not, generally, have any experience of selling companies. A publisher might spin-out or sell off one division every decade, at most – and many of those are instigated by the division itself (management buy-outs), or are fire-sales (find a buyer at any cost, no matter how low). They don’t have staff who are experience in doing this, they don’t have any contacts suitable for doing it, and they don’t (generally) maintain the level of immersion in the marketplace of studio buyers to be able to setup great deals when selling on a studio. Look at how much time the individual staff at VC’s spend purely “networking”, both looking for things to invest in (new purchases), but also looking for, befriending, understanding, and keeping up to date with the needs and desires of potential buyers (people who might acquire some of their portfolio).

3. Organizational Change

Lastly, have a look at the typical VC organization – a handful of Partners (maybe half a dozen people who make investment decisions), a handful of Entrepreneurs in Residence (EIR – maybe one or two domain-experts who make recommendations and help in due diligence). This is enough to manage billions of dollars of investments.

Now look at the typical Publisher organization – 50 people in each of marketing, customer service, and sales, perhaps 15 handling external develoment (finding and making development/publishing deals), and another 10-50 people in internal support roles. This is enough to own 1-3 development studios.

This isn’t to say that Publishers would need to downsize. Rather, it’s to point out that if the external development side started doing sales of studios for as much as $100million a time, their revenues and profits would suddenly massively eclipse (20 to 1, perhaps even 200 to 1) the whole of the rest of the organization, despite being outnumbered more than ten to one. Sooner or later, the “rest of the organization” would become politically weak and subservient to the massively profitable “trading in ownership of development studios part”.

The VPs of the current departments may well find that the total pie they’re sharing in becomes much bigger, and much more than makes-up-for the fact that their slice has got smaller, but will they accept their slice going from being a “Vice President” sized slice to a “Operations Manager” sized slice?

A few little Notes…

1. When I wrote Publishers are from Mars, Developers are from Venus, I had *no idea* that NCsoft had just decided to shutdown its European development studio, and make a swathe of redundancies in European publishing. Sheer coincidence, and sad for a lot of people involved, but very interesting nonetheless.

NB: if you work for a publisher or developer and are interested in picking up any of the good NCsoft Europe staff, especially development, QA, localization, and customer support – and you have jobs in or within commuting distance of Brighton – let me know. Lots of people are suddenly looking for stuff to do next…

2. I said that “Developers exist to make a loss, every day”, and some people questioned that.

Yes, I really mean this: the more they spend, the greater the potential profit, and they should be maximizing their potential profit. Obviously, there is a point of diminishing returns, but generally speaking whenever you have an R&D lab, you want to pump as much money into it as you can possibly spare. Generally, R&D labs are rather good at soaking up almost infinite amounts of money.

Compare the revenues and the expenditures of, say, GTA IV with those of Bookworm Adventures. The latter may have been much much more profitable in percentage terms, but the former made a bigger amount of money overall. Often, the sheer amount of money you make is more important than your profit percentage.

3. I decided to write these blog posts after a comment I made to Steven Davis about the problems of publishers owning development studios, which he replied to with “Actually, the publishers should fund these things like a movie studio or VC. Let them be independent, get them off the books, and use your money to control distribution or via publishing rights.”

I’d been thinking along similar lines, but I also realised I saw some big problems with the approach, so I thought it would be interesting to explore in more detail. But if he hadn’t made the comment, I probably wouldn’t have got around to it :).

Categories
dev-process games industry recruiting startup advice Uncategorized

Publishers are from Mars, Developers are from Venus

Over the last few years, there has been a big shift in power and success away from independent studios, and towards in-house, publisher-owned studios. This has been driven by several things, sound economic reasons, competitive reasons, and because the strong independent studios had done a good job at creating a slew of new IPs (which publishers were eager to snap up, as always).

In my experience relatively few people in the games industry realise this, but all these things are cyclical (it’s a lot more obvious in non-niche industries, like the IT industry, where you have many more companies, and the billion-dollar companies can’t be counted on one hand). So, what’s next? What’s going to happen over the next 3-5 years?

Some (recent) history

My last job was working for a large publisher (NCsoft – http://ncsoft.com) where we were setting up a new internal development studio from scratch. When I arrived I there was only one other person (plus my manager). We were doing a lot of other things at the same time – external development, pitching new internal projects, etc – but over the course of the first year I spent a lot of time looking at what we had to do to get a studio up and running, starting from scratch.

Interesting and fun. But also … surprisingly difficult. I’ve been one of the first employees at a couple of startups, and founded some, so I’m accustomed to starting up teams and departments, and a lot of the problems we encountered with this studio were just variations on familiar themes. But then there were also some new ones, side-effects of being inside a huge, well-established, publisher – one whose head-office was on the other side of the world, where the vast majority of the staff didn’t share any languages with the vast majority of the publishing office in our country, and our staff.

To summarize: the things that should have been completed fast were incredibly slow, and the things that should have been easy often turned out to be extremely hard. My definition of “should have” here is based on “whatever plays to the strengths of large corporates”.

As that became clear, one option would have been to throw up our hands and say: “this company is crap! No other similar company works this way!”. Instead, I dug deeper, and tried to understand how it was that we seemed to be seeing a lot of the opposite of what I expected. Sure, a lot of it could be explained by some over the top internal politics, and some by issues with individuals, but … this is a billion-dollar public company, and it’s foolish to think that management could be so weak and disorganized that a few internal battles and a few individuals could cause major aims of the organization to fail. No, there were underlying problems that were natural side-effects of the way the company worked. IMHO, these same issues are almost certainly causing problems for other internal development studios already, and will probably be major contributory causes of the move away from internal studios (when that day comes).

Publishers exist to make profit, every day; Developers exist to make a loss, every day

I could stop there. In that one sentence is encapsulated a problem so powerful and subtle that it’s more than capable of causing all the secondary problems – the ones people actually notice – that lead to publisher/developer acrimony when the two are together in the same company.

A traditional publisher is a box-shifter that pays a hefty license fee for exclusive rights to import a popular, trendy product from a foreign country. The things they need to be good at are:

  • Identifying the Next Big Thing, and signing an exclusive deal before anyone else gets it
  • Efficiently importing that thing and distributing it out to mass-market consumers (this is where most of the opportunity for profit exists)
  • Persuade as many people as possible to buy the product, as quickly as possible, for as high a price as possible (this is where ALL their revenue comes from)

Why did I mark the SECOND point as the point for profit? Because profit is extracted through the differential between the costs generated in that bullet point, and the price point that the publisher – arbitrarily – places on the product as sold to retailers (who then, typically in retail (forget the games industry – this is normal for all industries!) double the price again before selling to consumers).

The price point can be … anything you want. The volume you sell comes from the third bullet – but you have NO control over how much you sell. You *try* to sell as much as you can, but you cannot wake up tomorrow and *decide* to double sales. However … in contrast, you can wake up tomorrow and *decide* to halve costs. Or double them. So you focus on that middle bullet point: Efficiency (while making sure you assign a healthy slab of money to a sales + marketing department, and set them “targets” to try and meet).

A traditional developer is an R&D (research and development) laboratory. They try to be as scientific as possible, whilst spending every day working with masses of unknowns (and several unknowables – what is “fun” anyway?). After working for an indefinite period of time (no way of telling how long it will take) they’re trying to create (or discover) something that has never been created before, and which satisfies various criteria – many of which cannot be measured until after the project is complete.

They absorb money like a dry sponge in a puddle, with very little to show for it. The things they need to be good at are:

  • Securing as large a pile of resources as they can, and spending it to the fullest
  • Trying crazy stuff that they can’t explain, and waiting to see what will happen
  • Sticking as close to the cutting edge as possible, and always investing in long-term improvements

Why do they have to secure a large pile of resources?

Because their success is limited only by two things: their resource, and their skill. That translates into three concrete things:

  • How good is their equipment? (”equipment” means EVERY TOOL they use to do their work – including lots of indirect things that you may not think of as “tools”)
  • How much reagants and raw materials do they have? (everything consumable … including “time” … that could contribute towards doing MORE experiments)
  • How good are their staff?

Those three things are, in turn, only limited by “money” and “the quality of the people they hire”.

Publishers hate this. No, that’s not strong enough; Publishers REVILE, DESPISE, RESENT and LOATHE Developers for always, ever, and only going after those two things. And … they don’t understand it.

Frankly, as a box-shifter, with “efficiency” your only concern, WHO GIVES A F*** HOW “GOOD” YOUR PEOPLE ARE?

But that’s not the worst. No, the worst is this: as a box-shifter, the only thing you can directly control is your costs. Everything in your business, from the structure, to the choice of staff, to the processes, is designed to reduce costs. And what does every R&D laboratory obsessively try to do? Yep – raise costs!

If you ask a Publisher to create, fund, nurture, and partner with a Developer, you are asking the staff to encourage, to aid and abet, the one thing that you are already telling them every day to hunt down and destroy. Capiche? Does anyone see a problem here?

Developers in the Wild: R&D for profit

Well, this is clearly insane – how could a Developer ever make a profit? The answer can be found most easily by looking to the one place in the world where R&D laboratories make more money than anywhere else: Silicon Valley.

In the Valley, the Technology guys have become Entrepreneurs (or found an Entrepreneur to work with), and they’ve gone out there and applied their intelligence to a new problem: “Given this thing I’ve created, which is novel and cool and awesome, how could I use it to drive a product that people would pay for, and which (because of my NEW tech) I can sell cheaper than what is available, or (because of my NEW tech) does something people have been trying to pay for but been unable to find a working solution for?”

Despite appearances otherwise, good Developers are very similar to Valley Technology Startups: it’s all about the monetization, the capitalization – what bridge are you going to build between “what you’ve created” and “someone who has money and a problem”, and HOW are you going to build that bridge?

“Sell the exclusive publishing rights” is one bridge. It can be built many ways.

“Create an infrastructure that lets us deliver this product to the public, and take money from them” is another bridge, with just as many potential schematics.

But then there are others too, many others. Just because those two are the ones that the game-playing public tends to talk about (and are the two that Publishers are most familiar with) doesn’t – by any stretch of the imagination – mean those are the only ones that exist. Ask Blitz (an independent developer) about their Advergames for Burger King (definitely not-a-game-publisher). But, in general, just like in the Valley, the “other” bridges are tricky to invent, and tend to make someone rich just once or twice once invented and done for the first time. There are always new bridges to invent, and if the Technology person’s main role is to invent new tech, the Entrepreneur’s main role is to invent new bridges. So don’t be surprised if you find it hard to think of some.

What happens when a Publisher catches a Developer, puts it in a cage, and ships it back home? Or, more specifically, what do they do to the people that are thinking up innovative new bridges for monetizing the Developer’s assets, and trying to implement them? I’ll give you a clue: if everyone you know believes the world is flat, and has never walked more than a few hundred miles, and one day you meet a person who claims to have walked around the circumference of the planet, would do you do?

Yep. These people tend to be first in the firing line when nerves start to fray and the tensions between Developer and Publisher flare up. They’re an easy target – they make no sense to the Publisher, and their very existence is an affront to their core business model, to their box-shifter mentality (it suggests that the box-shifter is doing a simpler business, something run by simpler, less imaginative, more stupid, people).

UPDATE: I’ve just written a followup looking at one of the possible future directions coming out of this

Categories
agile dev-process games industry

Problems to Avoid as a Scrum Project Customer

(I’m quoting a very handy short extract from Clinton Keith’s December 2007 Gamasutra article, so that I can find it again easily later. Clinton is/was the CTO of High Moon Studios, and is probably the most well-known proponent of Scrum in the games industry. Rather than wade through the whole article when I want to pass on some of his advice, I wanted to be able to copy/paste the relevant sub-bits)