T=Machine

If your startup sells stuff via the internet (you have an online product, service, web-app, etc), this may be the single most important thing to get right (assuming your core idea, team, etc has inherent merit). And yet so many companies spend so much money doing it so wrong.

Why are modern software companies so bad at selling software? Today I was looking at Scrum tools (or Agile if you prefer), and I was struck by how hopeless some of their websites are. With some of these sites, I am sure that I could increase the sales of most of these companies by hundreds or thousands a year, just through basic principles of sales.

(and, obviously, HOWEVER you design your sales page, you should be using A/B testing to increase sales, conversion, etc. But A/B testing is no panacea: you still need the creativity and understanding to make the “big leaps” yourself)

Example: VersionOne

I’m going to pull out one example (by accident, the first I came across). Many others are much the same.
VersionOne.com

Before we go further, let me be clear what “kind” of customer I am. I’m currently looking for solutions for two commercial setups. One is for tiny projects on a case-by-case basis. This would be 5-seat licenses (worth up to $3000 at VersionOne’s current prices). The other is for a company-wide purchase of up to 30 licenses per annum (worth up to $15,000).

But, at the same time, my last full time job was running development for a large development studio. I was the primary reviewer and purchase-maker for software tools that were 50-person per annum immediately, and meant a commitment of up to 150 within 3 years. I’ve done a *lot* of this purchase-review process, on a lot of software.

My negative reactions to VersionOne’s sales are fairly consistent across the 3 profiles (although the reasons behind that are complex)

Landing page, from Google: the “don’t ask questions, you’re too stupid, just buy instead”, and “we love ourselves, we’re awesome” page

Page: http://pm.versionone.com/Trial_ScrumProjects.html?c-aws=trs&gr-tss&v-029abt&gclid=CNGTgsrEoaICFUcA4wod82WOwg

This has a *concealed* URL, so it pretends to be the front page, but actually lies, and redirects you to this page instead:

Ont this page, your website states it’s a commercial product, yet REFUSES to answer the single most important question: how much does this cost?

There aren’t even any LINKS to finding out about the product. It’s just “buy our product, or piss off”.

This page serves one purpose: lock the customer into a product they don’t want. You are “not allowed” to know the cost, you are only “allowed” to “signup now for a 30-day trial” – you have to commit yourself, and they’ll sting you with a price later, when you have no choice.

Word of advice: merely making something “free, for a few minutes, then I charge you” does NOT lower the customer’s barriers to purchase. For an ultra-long-term product like Project Management tools, it often has the *reverse* effect. The MINIMUM trial for a PM tool is “one project”. Most projects – using new tools – will need several months; 2 week to learn the tool, 10 weeks to run + launch + finish the project. The customer knows this; they know that a “30 day trial” is completely dishonest.

So, we use the navbar, and head to the “Product” page:

Product page: the “Want more info? Oh no you don’t! You’re too stupid, you’re just a customer!”

Page: http://www.versionone.com/Product/

I’ll sum up the stupidity and smug self-satisfied attitude of the person who wrote this page with just one quote, their final bullet point in the top-section:

“Accelerate agile adoption”

[hey! Look at that! I'm so clever - three words all beginning with "a"! They're guaranteed to buy now! I'm so sharp, sometimes I cut myself]

Sigh. Ignoring the “infographic” which has been screen-captured with a font-size of 2pts (i.e. literally physically impossible to read), we try to do something useful with this page: review the product (we’ve given up on pricing, for now – they obviously don’t wany anyone to buy the product, but maybe the product is so good we can force our way past that?)

Product page, part 2: the “we don’t trust you, we’ll spam you with marketing crap”

Page: http://www.versionone.com/Product/

(below the infographic)

Just look at that page. It has literally zero information about the product, yet it’s the “product” page.

Instead, it has paragraphs of marketing crap. There’s no other term for it; let’s look at the first example.

Bullet-point: “Product Planning”

What does this mean? Absolutely nothing. BY DEFINITION, this is a whole website devoted to project-management-planning software used on projects that create products. Why do you repeat this, in such a childish gross genealization, as if it’s a “feature”?

Ah, but … actually, that’s not necessarily true. Scrum is often used on projects that are NOT generating a Product.

So, in fact, this lazy marketing title has already told some of the target-customers: “Don’t use our product. Go away”.

Let’s look at the text underneath the bullet:

“Plan and manage your requirements, epics, stories, and goals across multiple projects, products and teams.”

What is this – Dictionary.com? Why are you patronising me by telling me what you think “Product Planning” means, as an abstract concept? What kind of project manager – or engineer – is so stupid as to not know what it is they do on a day to day basis, and to feel happy that you’re telling them?

I WANT TO BUY YOUR SOFTWARE, NOT LISTEN TO YOUR PHILOSOPHICAL DISCOURSE.

I suspect that the weak marketing person who wrote this copy thought it “looked nicer” to put features into a long sentence. Let’s look at that sentence, from a copy-writing perspective. It has eight separate phrases. EIGHT. The average sentence has 2-4. Concise sentences have 1-2. Waffle has 5 or more. This is a sales page; every sentence should be no more than 3 phrases. EIGHT! NO-ONE is going to pull useful information from that sentence.

Onto another problem with this page, for the customer who comes here: No screenshots. Anywhere.

OK. Take a deep breath. This is a company that, so far:
– wants to deceive us into locking-in to their product
– patronises us intensely
– works hard to hide features (check that “unreadable” infographic)

…but let’s put all that to one side, and drill down into the links from the Product page.

Features (1 of 8): “You can look, but don’t touch AND DON’T LOOK CLOSELY!”

Page: http://www.versionone.com/Product/Product_Planning.asp

Finally, if you follow one of the links from this page, you get to a page that contains some actual, concrete, info about the product. There’s even some screenshots!

Oh. BUT. You are “not allowed” to actually see the screenshots. They’ve been deliberately blurred-out a low-resolution, so that text is literally unreadable and there is NO WAY to judge the product. (NB: this is *after* you’ve clicked on the almost-full-size thumbnails in the page). They are then further blurred (to no purpose except to fit the Web Designer’s fetish for popup images) and embedded in the page.

Overall impression: this company knows it’s own product is not fit for purpose, and will do anything to stop the customer from finding that out until AFTER they’ve paid their money. Whatever you do DO NOT BUY VersionOne’s project-management software.

Final thoughts: First one is free

A decent usability person – or a really good web designer – would make huge sweeping changes to that site.

A flippant starter, something I’d personally try immediately (today): move the “see it; drive it; try it” buttons that hide in top-right of the site to CENTER STAGE, both on the Product page and the Google Landing page.

AND … I’d add a fourth button: “Buy it”.

What? There’s no “buy” link on this site? Yep. I think that eloquently sums up what a poor job this site does of MAKING MONEY FOR THE COMPANY.

(NB: and I *absolutely* would instigate A/B tests to prove – day by day, hour by hour – that my changes were having a noticeable effect on increasing sales to the site. If you don’t do that, then you’re just pissing into the wind. You have no idea, afterwards, whether your changes “worked”. See Sergio Zyman‘s book for more…)

Where do these terrible sites come from?

I believe that these often-amateurish websites come from one of two sources (possibly both):

1. Expensive “Web Design” agency that only cared about making it “beautiful” without understanding a single thing about the reality of sales. In the example I run through below, dead giveaways include: Popup images that are only 15% larger than the thumbnails that trigger them; grey-on-white text; very small font-sizes. All those are characteristic of visual designers who know nothing about product sales.

2. A marketing team that’s worked for big corporates (multinational, public companies) and thinks that the most important thing in their job is to “clone” the website of “a real company – you know, like Microsoft”, and pretend to “be like the big boys”. They have no idea why those websites look the way they do, and don’t bother to ask themselves; they just blindly clone it. In the example below, dead giveaways include: 12 pages to describe a simple product where 3 would have been more than sufficient; hiding information at all costs; never committing to a list of features; using “freeform text” instead of simple “bullet points” to describe the product.

Filed under : agile, dev-process, entrepreneurship, programming, startup advice

2 Comments »

From the IGN walkthrough:

“If you have trouble grabbing the beam, just keep trying—we promise it works, but lots of readers have told us it’s not always easy.”

I’m a pretty good AC player, but after 10 minutes of trying to do that one standing jump, I gave up and stopped playing for a long time in frustration.

When game developers talk about “games should be so easy that all players can complete them; no-one should ever have to give up / fail to complete a game because something is too hard”, I usually disagree.

But in this instance, where the game is extremely, excessively difficult on something that the designer obviously intended to be extremely simple – and where the player has spent hours being taught that this will be easy – you have something different going on. It’s a failure of the control scheme; in fact, it’s a bug.

It’s a side-effect of the heuristics that AC uses to decide “what the player is trying to do” – heuristics that are far from perfect, while being very good.

In the first game, it took me a long time to get past the intro – no, really – because if you *try* to jump over gaps, then you fail. The heuristics were so heavily weighted towards “allowing” you to jump off buildings that running over a small gap became very difficult – until you learnt that the character “automatically” jumps small distances.

On the whole, I’m very impressed by the AC2 heuristics – compare it to Mirror’s Edge (a beautiful game, but feels a lot less fluid). I find them a bit too simplistic – I would love another 25% or so of user-control, and another 50% of precision on directional control – but (as ME shows) they got closer to perfect than any other game so far.

BUT … what do you do about a bug like this, one severe enough to make me stop playing the game entirely?

They had a huge QA team already (this is Ubisoft, after all), and such a vast amount of content in this game (multiple entire cities, modelled in fine detail), that there’s no way they could be sure to catch this bug.

Or is there?

This is the raison d’etre for a whole segment of in-game analytics / metrics: data-mining to discover undiscovered bugs.

Good metrics for game designers are VERY hard to describe, and IME the vast majority of the industry doesn’t know how to carefully hand-pick the few numbers they really need out of the millions of stats availalbe. Here’s a good example of how to pick well.

If the game reported

“the quest-point at which people stopped playing”

…then you *might* discover this bug. But it’s too coarse-grained.

If the game reported either/both:

“the segment on the map where people stopped playing”
“the segment on the map where people spent most-time during a mission”

…then you’d quickly and easily discover this bug. By “segment” I mean, essentially, a small patch of polygons approximately 6′x6′. This is relatively easy to measure algorithmically using greedy-polygon grabbing and hashing – although it would take a little care to make sure the measurement of the value didn’t take much CPU time (it could easily be pre-compiled for any given map, of course).

I’m not 100% of the “stopped playing” part – this is a console game, and while that info would be useful, it would mostly stop evenly distributed over quest-end points. Where it was more / less likely, it would be obvious just from knowledge of the story. ALTHOUGH: still well worth doing *in case* there were anomalies there – that should set off alarm bells.

However, the “spent most time during a mission” is more cut-and-dried.

This probe gives you a set of local maxima. It’s categoriesed by mission, making it one level finer than doing it over the entire world-map (which is too much, too uncategorised info), and it’s also coarse enough to correlate closely with user-behaviour (it merges results mission-by-mission; recurring bugs are very likely to show up by people doing the same mission and getting stuck at the same point).

The mission-based merge of results also has a nice side-effect: it tends to iron-out any anomalous results due to people wandering around the open-world game.

So. With a little bit of probing, using probes that you could/should have invented at the start of development (i.e. without knowledge of exact bugs that would occur) this bug could be ironed out. The three remaining questions are:

1. does Ubisoft do this level of automated-bug-detection,
2. do their designers bother to look at the anomaly-date,
3. and if so … why hasn’t the game been patched?

Filed under : computer games, design, dev-process, games design

3 Comments »

In a few months time, I’ll be in Austin, TX, sitting on a panel at SXSW … judging people’s ideas for new computer games. I’m going to make an offer here, now, to help people entering future competitions (FYI: it’s too late for SXSW 2010).

This is the fourth time I’ve been a reviewer or judge for a game-design competition/panel/etc, and I’m noticing some recurring themes. This is interesting, since everything I’ve judged has been completely different (different countries, different audiences, different rules).

Recurring themes of game-design competitions

One theme in particular is that a large percentage (circa 30%) of entries are depressingly bad; it seems that many of the wannabe-game-designers in the world are just plain lazy.

Another theme is that when someone has a good idea, they often don’t realise how good it is. They end up spending one sentence (or, if you’re lucky, two sentences) talking about the interesting part, and the next 500 words spewing out meaningless drivel that applies to every game ever made.

e.g. “you will have different choices to make in this game, there will be puzzles, and when you finish a puzzle you will get a reward, rewards will be used to unlock more levels, and to finish the game you have to get to the last level, which will be harder than the earlier levels, and … ”

… and: STFU. You’re boring. Do you think that I’ve never played a computer game before? Or do you just think I’m so stupid that I can’t remember what they’re like?

Some tragic outcomes

NB: this is just one example of what goes wrong with competition entries; I could give you countless more…

Some of the judging I’ve done was at the start of a competition, where the teams then spent the next 3+ months full-time actually building their games. On those occasions where a team was let through because we saw something special in their core idea, despite them waffling about a million other things, the team tended to make the EXACT SAME MISTAKE during production. They would spend 10% of their time on the cool idea, and 1% on each of 90 irrelevant distractions. They never won (surprise!).

For the times when we just judge ideas, not actual games, my distinct impression is that a lot of “good” ideas get thrown out because they’re submerged in so much rubbish that the judges either don’t see them … or assume the above is going to happen, and so they want to give the attention to other, more focussed teams.

So…

So, I’m offering anyone (anyone!) the chance to get some free feedback on their game idea, in the mindset of a competition judge. Maybe you’ll discover holes in your pitch, maybe you’ll discover ways to improve your core game … maybe it won’t help you at all :).

Details here: Got an idea for a new Game?

Filed under : computer games, conferences, dev-process, games design, games industry

Comments Off

The problem

It’s a great piece of openness to put your bug lists in the public domain. It makes it easier for your customers and partners to make decisions that save you time because they can see what’s coming and when (and save you money in reduced support requests). It saves you money in that you get free QA / testing from your users.

The downside is that it exposes to the world the places where you are especially incompetent, lazy, or just plain self-centred.

This is a recurring theme I’ve seen with corporates looking at both Open Source and also Web 2.0:

We say we’re the best, but secretly I believe we’re the worst; if we expose ourselves to the public, people will ridicule our mediocrity, and refuse to do business with us.

Also … I will probably get fired because my colleagues and my boss will finally realise what a clusterfuck I preside over on a daily basis

Eclipse, and a tale of two bugs

I was going to log two high-impact bugs that Eclipse has had for several years. Then I did a search on that area of Eclipse, and realised that the current Eclipse maintainers don’t give a **** about this whole section of the IDE – some of the core bugs we see every day were logged in 2001, and are still open:

https://bugs.eclipse.org/bugs/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=syntax+coloring

What you find when you do some basic research

If you go looking through the bug history for some of the more “obvious” bugs there, you often find little gems of passive-aggressiveness from maintainers. That’s an exceptionally effective way of making sure people stop helping and supporting any Open-Source project…

You’ll also find endless re-logging of the same old bugs from 10 years ago, revolving around the basic problem that Eclipse lets you set everything you could possibly imagine … EXCEPT the colours that it prints text in.

(all IDEs let you set the colours; most dont give you enough control over the other parts; Eclipse fails on the basic challenge, and succeeds on the advanced challenge)

This wouldn’t be so bad, except that its default is very bright with low-contrast – i.e. very hard to read on laptops when outside, and bad to read for long periods of time. As of about 5 years ago, you are finally “allowed” to set the colours yourself – except that the app breaks if you do, because they “didn’t bother” to allow you to change the colours on 20% or so of things.

Final thoughts

The next time someone – especially at a corporate – resists openness and transparency … in any form … ask yourself this:

What have they got to hide?

Often, once you ask yourself that question of the right person at the right time, it very quickly becomes obvious what they’re hiding (if not why). A little more digging, and you can pry open the can of worms, and see what trouble they’ve been up to…

(Incidentally (and unsurprisingly), in the face of the point-blank refusal of Eclipse developers to make basic usability concessions across the board, I didn’t bother logging either of the two bugs I’d found)

Filed under : MMOG development, agile, dev-process, programming, startup advice, web 2.0

3 Comments »

Slides for our panel arehere: “Killing mmo tech sacred cows.pdf”.

Final panel was myself (moderating) and speakers: Bill Dalton (Bioware), Rick Lambright (Gazillion), Joe Ludwig (Valve), Marty Poulin (Shady Logic).

PLEASE NOTE: WE DON’T REALLY ADVOCATE EXTREMIST RESPONSES TO TECHNICAL QUESTIONS; THIS WAS JUST A BIT OF FUN. (Mostly).

Filed under : MMOG development, computer games, conferences, dev-process, massively multiplayer, network programming

4 Comments »

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

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.

Filed under : dev-process, games design, iphone

1 Comment »

(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?

Filed under : computer games, design, dev-process, devdiary, games design, iphone

6 Comments »

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

Filed under : advocacy, dev-process, entrepreneurship, games industry, startup advice

16 Comments »

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.

Filed under : bitching, dev-process, fixing your desktop, iphone, programming

10 Comments »

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!

Filed under : agile, dev-process, programming, web 2.0

14 Comments »

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?
(more…)

Filed under : computer games, design, dev-process, games design, games industry, massively multiplayer

51 Comments »

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.)
(more…)

Filed under : dev-process, entrepreneurship, games design, games industry, startup advice

5 Comments »

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)

Filed under : dev-process, iphone, programming

0 Comment »

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.

Filed under : dev-process, programming, recruiting, startup advice

0 Comment »

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…

Filed under : dev-process, iphone, massively multiplayer, mmo signup processes, programming

1 Comment »

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)

Filed under : agile, dev-process, games industry

0 Comment »

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 :).

Filed under : Web 0.1, computer games, dev-process, mmo signup processes

3 Comments »

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)

Filed under : community, computer games, databases, design, dev-process, games design, games industry, massively multiplayer, network programming, programming, recruiting

0 Comment »

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.

Filed under : computer games, conferences, dev-process, security

0 Comment »

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.

Filed under : dev-process, facebook, games design, games industry, web 2.0

12 Comments »