New prototype I’ve been playing around with…
Category: dev-process
One of Unity’s dirty secrets is that (out of the box) it’s plain awful as a prototyping tool. You can fix that, but it requires quite a lot of work. I’m going to start publishing my fixes one by one. Here’s the first: a test-bed for making custom meshes.
Slides from my talk last night at Unity Brighton.
Three parts:
- First: introduction / overview of Entity Systems, and why you care (as a “person who makes games”)
- Second: Progress so far: screenshots of the Unity Editor with explanation of the new features I’ve added
- Third: Challenges and solutions I’ve encountered so far
WordPress, HTML, the web etc – don’t support “presentations” yet. No, I’m not creating a fake Slideshare account just so you can wait ages for a non-bookmarkable slide viewer to (slowly) load. Until then … we have PDF. Enjoy!
Background
Every Saturday, thousands of indie / hobbyist game developers publish screenshots of their in-progress games. Unlike most forms of marketing, this is:
- honest / genuinely representative (it’s actual content)
- interesting (show’s the dev’s intentions)
- exciting (pictures of games are usually more fun than words)
i.e. … it’s an amazing marketing tool.
But many game developers are screwing this up. A year ago, I posted a long list of advice, tips, and explanations – worth reading. But some devs are still misunderstanding / screwing this up. So, what should you do?
Entity Systems in Unity… some examples of the problems
This is a new series of blog posts, where I’m going to document specific ways + concrete examples in which Unity fails (sometimes spectacularly) as an “ECS” game engine.
I like Unity; but the core architecture (which is very old) is a half-assed ECS, and if we’re to upgrade it into a really good, modern, architecture … we first need to understand exactly where it’s failing, and why.
So, let’s start with Selecting Things…
Background
Game
A 2-player card game where each player normally draws a card each turn, and then plays one or more cards. Sometimes (e.g. when discarding because “too many cards in hand”) they have to select more than one card at once.
Initial version of game will be 1-player versus computer. Very soon: want to upgrade to OPTIONAL 2-players on-screen, with one using the mouse, other using gamepad. Ultimately, want to also add over-the-internet multiplayer (which ends up interfacing with the codebase in a very similar way to the original 1-player-vs-computer, so we can ignore for now).
Code Situation
Player taps card. Now … we must inform many other scripts and independent systems, so they can choose to eg.
- ignore (if invalid for current state of game)
- react (e.g. zoom to display the card more clearly)
- “select” internally (side-effects include: deselect other things)
- advance the game (if it was waiting-for-input)
- ..etc
Problem
What/where do you send the “player clicked on a card; can some piece(s) of code PLEASE deal with this??!!?” ?
Addendum
In Unity, only the low-level “card” object can sensibly detect it has been clicked on.
Both Unity’s Physics (old) and EventSystem (new) effectively force this via their core design. Both require you to attach scripts to the physical objects that will be clicked.
In practice, this is bad for OOP (and bad for ECS too). When there’s e.g. 100 cards all of which must be separately clickable, your code is really in the wrong place. You don’t want cards (which sometimes are in a deck, sometimes on the table, sometimes “virtual” (perhaps in a virtual, unopened booster pack etc)) … to be containing all the GAME logic required to know what to do when they’re touched!
Classic Entity System / ECS solution
- Create a SelectedByPlayer component
- Add it to the card
- Sit back, and relax. Code that cares about input will scan “get me all SelectedByPlayer components” on each frame, and react accordingly
Everything works automatically; any System/Processor that’s “waiting for a selection”, or “making render changes when selections add/remove”, etc … will pick up what it needs, with no work.
You can add new input-handling routines simply by adding them. That’s all. No other changes needed.
Attempting to solve this in Unity
UNITY 4.6/5.0
Maybe … NB: I’ve only just started using the new GUI/EventSystem in Unity 4.6+ .. create a custom Input event, and a custom InputModule that can understand that, and then put all the code for ALL affected systems/processors into one monolithic ugly, hard-to-maintain script from Hell.
I suspect that this code will be quite maintainable w.r.t. adding new Input hardware in future – e.g. allowing mouse vs gamepad. But it’s going to suck at the rest, all the business-logic and handling. Which is going to be > 95% of the maintenance cost.
You get one small benefit: you can separate-out different inputs (click versus drag). Sadly, in reality: 95% of game actions will be simple clicks. This is one of those “the code architecture sounded great in academic situation, but reality is so unbalanced, it works out less well in practice” situations.
This is a classic OOP solution, and has the downsides. The only significant benefit I can think of is that it’s a “known” Hell: if you’ve done a lot of OOP game coding, you’ll be familiar with the pain you’re going to run into.
UNITY CLASSIC
Make a new class “CardClickManager” whose sole purpose is to reference all the possible bits of OOP code that “might” need to react, and which has to be updated by hand EVERY TIME you modify, add, or remove some input-handling code ANYWHERE else in the codebase.
Pretty much the same as above, except it:
- … is even more simplistic (no event-dispatch systems)
- … making it even harder to maintain + debug
- … is slightly more proprietary
Conclusions / Improving Unity
So far, I cannot think of any sane, maintainable solution here other than “suck it down and use OOP, and suffer forever”, or “throw away Unity GameObject/Component, and implement a proper ECS”.
That’s fine, though. That’s the point of these posts – to hilight situations where there’s no good middle-ground, where we must create the data-centric, cleanly-separated architecture of a modern ECS.
Counter-ideas very welcome! Comment away, guys…
Ask 10 game developers if you should use more script code or less, and you will get 11 different answers. They are all correct: it’s very situation-specific. Use of scripting languages is highly dependent on the humans and the practical / project-management issues.
Why?
Inspired by Markus / @notch, and how he got MineCraft going in the early days, I’m live-prototyping a game idea I’ve been thinking about for ages. It’s about exploring a landscape … where cities affect dungeons, and dungeons affect cities.
(this is stress-relief for me, an “evenings and weekends” project. By day, I’m helping Schools teach children to program, but that’s HARD (no investors, lots of costs – at the moment, I get paid nothing))
July 2014
Current build focusses on the “City building” interface. Initially, you won’t be building cities, you’ll be building small camps / trading forts, etc. So this lets me play with the interface, the scale, the rendering, etc. Make sure it’s fun.
Create something – but take screenshots! Because there’s no “save” yet. Super-early prototype.
Long term gameplay
- Explore a huge landscape in FPS
- Any location, “create a camp”, and it switches to the isometric view you see in current demo. Build yourself a home/fort/etc.
- Fast-travel between locations, but this triggers “random encounter” events … or run between locations manually.
- Turn-based / DungeonMaster style dungeons are randomly generated near to each camp. Explore the dungeons for resources and to level-up.
Unlike e.g. Skyrim … when you find an interesting location, you can’t fast-travel to it. You have to build a camp next to it, and fast-travel to that. But your camp can be overrun/destroyed/stolen while you’re away.
So … you’ll be building (and maintaining) a lot of bases around the world. I want to be sure that base-building is easy and fun, even after you’ve done it lots of times already, before progressing with the rest!
(I’m trying to make it “repeatably fun” by having the landscape HUGELY affect your base design)
In 2014, I’ll be making a new game in Unity that makes intensive use of an Entity System.
This will give me lots of ammo for a new post exploring the pros and cons of Unity’s “partial” Entity System architecture. I’ve been thinking about this a lot for the last couple of years, but I’ve been unhappy with the draft posts, and didn’t publish them.
Over the next couple of months, I’d love to hear from all of you the challenges, confusions, problems, and questions you have about this. I’m not promising quick answers – but it will help shape the blog posts I write, and as soon as I have a good enough set of answers, I’ll start posting them :).
I maintain a medium-sized open-source project. I welcome bugs and ideas via GitHub’s excellent “Issues” tab.
Some Issues are well-written, others are not. Strangely: Issues get resolved fastest are often the shortest – as little as 2 or 3 sentences. Doing it “right” is easier than I expected…
How slow is making iPhone apps using native code?
You have to write HTML5, right, if you want FAST app development on iPhone? Or Unity? Or cocos2d?
Right?
Or … write it in Objective-C … a beginner-friendly “native” language: 2 hrs and 15 mins to create the artwork, design the game, code it in native Objective-C, debug it, and push to iPhone devices
NB: first half shows: “Collect the fish, avoid the dynamite, grow bigger!”
Second half shows: “if you hit dynamite, you shrink; when you’re tiny, if you hit dynamite, you’re fishfood :(”
For the love of … WHY?
Because I entered a voluntary “48-hour game jam” (you have one weekend to make a game), and last time I went to the Apple shop for a repair, they dislodged my network card. It fell out, internally, and it’s not user-fixable (believe me, I tried – even specialist screwdrivers aren’t enough :( ).
So I did something else with my weekend. But a few hours before the competition deadline, I figured “what the heck; what could I do in a couple of hours?” … with some encouragement from The Mighty Git.
The code?
222 lines of code, including comments, blank lines – and code that I commented out because I replaced it with other code.
That’s all it takes for a working, playable, iPhone game.
…and the art?
You can’t see it from the video, but the art is resolution-independent – as your whale gets bigger, it re-renders, so that all the curves ALWAYS have razor-sharp edges. No effort required on my part.
I did all the artwork in Inkscape (free image editor for vector images), and saved as SVG (web-standard for vector images).
Then, courtesy of the open-source SVGKit project (renders vector images on iOS, because Apple doesn’t add support to their libaries – shame), and the following few lines of code:
self.sivWhale = [[SVGKImageView alloc] initWithSVGKImage:[SVGKImage imageNamed:@"whale-1.svg"]];
sivWhale.frame = CGRectMake( 0, 0, sivWhale.frame.size.width * sivWhale.scaleMultiplier.width, sivWhale.frame.size.height * sivWhale.scaleMultiplier.height );
sivWhale.center = CGPointMake( self.view.frame.size.width/2.0f, 0.75f * self.view.frame.size.height );
[self.view addSubview:sivWhale];
If that looks rather like using a built-in UIImage and UIImageView … it’s because it’s intended to. SVGKit adds a new type of image – SVGKImage – that’s almost the same as an Apple UIImage, except it’s better (it’s resolution independent). And the SVGKImageView does for SVGKImage what UIImageView does for UIImage…
Want the code?
Sadly, the version of SVGKit I used here has some bugs in it – it’s live at: https://github.com/adamgit/SVGKit/tree/transforms – but until it’s been tested and fixed by the SVGKit maintainers, it won’t appear on the main SVGKit project page.
So, feel free to use that link and play with it – but be warned: it’s NOT as stable as the main SVGKit. Yet.
I haven’t shipped anything with Unity; last time I used it was early in 2.x, and it was painful enough that I never used it in a live project. I’ve re-eval’d every 6 months or so.
Now I’m onto Unity 3.5, and using it in several real projects that are due to ship this year … positive experience so far. I haven’t run anything on an iPad3 yet (that’s the next thing to try), but it’s treating me a lot better than Unity 2 did.
A few surprises along the way…
There’s still no decent “official” tutorials
There’s some video (yuck), and the first tutorial on the official tutorials page says (in slightly more words) “this is not a tutorial” in the opening paragraphs. Great! WTF?
I did find some basic ones (great for getting you into using of 3D objects *and* scripting together, at the same time) here: http://catlikecoding.com/unity/tutorials/
…and friends and colleagues provided a long list of recommended video-tutorials which I’ve been working through. Some sites have some great “beginner” tutorials, but they peter out in quality as they get more complex. Typically, the videos get more and more long-winded, boring, and a huge waste of time (many sites seem to have a hard-on for 2-hr videos, often for stuff that – if it had been a real tutorial – would have taken 30 minutes to digest. I guess they sell more advertising this way?).
The editor is very clear, self-consistent, and stable
Compared to early Unity 2.x (last time I used it), and compared to most 3D editors, Unity’s editor is very logical, consistent, and simple once you’ve had a 3-minute intro (good luck finding one; best to find a human and ask them to show you).
Overall … compared to most game tools I’ve used over the years … a delight to use. Although I’ve not hit it with any huge scenes yet (that’s where the real test will come; how often will it crash? how badly?)
Also: hasn’t crashed on me at all. Although there’s some occasional glaring bugs even in simple scenes (which is worrying) – e.g. one time, the scene playback engine corrupted itself and started “leaking” settings, which is allegedly impossible – on the whole, it’s decent quality.
(transparent) PNGs aren’t supported
2012, and Unity still can’t (fully) read PNG files. Wow.
(using PNG’s saved from Photoshop – but Unity’s crappy PNG importer screws-up the alpha. Depressing. Back in 2005 I thought we’d seen the last of the world’s “apps with only partially working PNG loaders”. Apparently not)
Javascript and C# sit very happily side by side
This is important for one project I’m working on, where we’ve got a mix of coders with diferrent backgrounds. All of them know ONE OF the Unity languages (C#, Javascript primarily … some other more odd ones too), but there’s no single language that EVERYONE knows. So far, Unity’s had zero complaints about us mixing and matching the script languages.
(I’m prototyping a new game (working title: “ChessQuest”) – original post here)
Major changes:
- Enemies have health, and can be killed by touching them
- Performance is another 30% faster (should be running OK on most phones now?)
- Enemies have a direction indicator (not necessary right now, but it’ll become important in a later version…)
Download link
Spotted this (the notion “DevOps”) courtesy of Matthew Weigel, a term I’d fortunately missed-out on.
It seems to come down to: Software Developers (programmers who write apps that a company sells) and Ops people (sysadmins who manage servers) don’t talk enough and don’t respect each other; this cause problems when they need to work together. Good start.
But I was feeling a gut feel of “you’ve spotted a problem, but this is a real ugly way to solve it”, and feeling guilty for thinking that, when I got down to this line in Wikipedia’s article:
“Developers apply configuration changes manually to their workstations and do not document each necessary step”
WTF? What kind of amateur morons are you hiring as “developers”? Your problem here is *nothing* to do with “DevOps” – it’s that you have a hiring manager (maybe your CTO / Tech Director?) who’s been promoted way above their competency and is allowing people to do the kind of practices that would get them fired from many of the good programming teams.
Fix the right problem, guys :).
Incidentally – and this will be a long tangent about the nature of a TD / Tech Director – … my “gut feel” negativity about the whole thing came from my experience that any TD working in large-scale “online” games *must be* a qualified SysAdmin. If they’re not, they’re not a TD – they’re a technical developer who hasn’t (yet) enough experience to be elevated to a TD role; they are incapable (through no fault of their own – simply lack of training / experience) of fulfilling the essential needs of a TD. They cannot provide the over-arching technical caretaking, because they don’t understand one enormous chunk of the problem.
I say this from personal experience in MMO dev, where people with no sysadmin experience stuck out like a sore thumb. Many network programmers on game-teams had no sysadmin experience (which in the long term is unforgivable – any network coder should be urgently scrambling to learn + practice sysadmin as fast as they can, since it’s essential to so much of the code they write) – and it showed, every time. In the short term, of course, a network coder may be 4 months away from having practiced enough sysadmin. In the medium term, maybe they’ve done “some” but not enough to be an expert on it – normally they’re fine, but sometimes they make a stupid mistake (e.g. being unaware of just how much memcached can do for you).
And that’s where the TD-who-knows-sysadmin is needed. Just like the TD is supposed to do in all situations – be the shallow expert of many trades, able to hilight problems no-one else has noticed, or use their usually out-dated yet still useful experience to suggest old ways of solving new problems that current methods fail to fix. And at least be able to point people in the right direction.
…but, of course, I was once (long ago) trained in this at IBM, and later spent many years in hardcore sysadmin both paid and unpaid (at the most extreme, tracking and logging bugs against the linux kernel) so I’m biased. But I’ve found it enormously helpful in MMO development that I know exactly how these servers will *actually* run – and the many tricks available to shortcut weeks or months of code that you don’t have to write.
Google keeps improving Android. Android version 2.2 is one of the most important releases ever – it speeds up the whole phone (every game, every app, runs noticeably faster), along with bugfixes and new features.
Sony Ericsson has caused much hate among consumers by shipping their flagship phones with OS 1.6, even when 2.1 was already available, and then being very, very slow to “allow” their customers to upgrade (the upgrade is essentially free, Google doesn’t charge for it).
So far, no news at all.
But this week, Sony’s official Twitter account posted this, along with possibly the world’s worst excuse from a mobile company:
There will be further system updates for the X10 handsets however there will not be any more updates to the Android platform.
…
We believe the features included in the Android 2.1 phone are on par with, and in many cases better than, a vanilla installation of 2.2 #X10
i.e. “that expensive phone you bought in the last 9 months will never run many of the new apps on the Android marketplace. We believe you should be grateful because it’s a really pretty phone, and who cares about apps / games / etc anyway? iPhone? What the hell is an iPhone?”
The sweet stench of cow-manure
Let’s put this into perspective…
When you write apps for Android, before you even write the first line of code, you have to choose the minimum OS version that your app will work with. The older the version, the fewer the features that you have access to. Also, the more bugs you’ll have to workaround (even Google has bugs :)).
So, you leave out some features, maybe. But there’s more: many of the features of newer versions are things that are invisible to the user, but which make development quicker, easier, or less error-prone.
i.e. going with an older OS means that the developer has to pay more, work harder, for less reward, producing an inferior product. It’s not very tempting!
And Google just released Android 2.3, so 2.2 isn’t even the “current” version any more, it’s the “old” version.
…net result: lots of developers will be making Android 2.2 the “minimum” version. Sony is actively “locking-out” their customers from using the phone they own to download and purchase (a percentage of) new apps. Today, that percentage is small – but it will get bigger every day, and Sony has declared they will “never” fix the problem.
2.2? Why not 2.1? Why not 2.0?
There’s lots of improvements in 2.2 that make developers lives easier or less expensive, but there’s a single “flagship” featuer that overules everything else. This one feature can easily cut 20% of the cost of development.
2.2 has improvements to the Java VM, that make *all* apps run faster. c.f. my own experiments, where my space-invaders game ran approx 20%-30% faster, just because I upgraded the OS.
That saved me possibly weeks or months of coding that I would otherwise have spent hand-tuning the code to increase performance. Performance isn’t everything, but … the wide variety of Android handsets means that even relatively simple apps may struggle to run at decent speed on some of the handsets out there.
Of course, if I don’t use *any* of the other features, I could still release this app on 2.1 … but all the people with 2.1 would be getting an inferior experience, and many would complain and rate the app down. It’s probably less damaging – and more profitable – for me to simply ban people with “old” versions of Android from using the app at all. That way, they don’t get disappointed, and won’t be able to down-rate it.
UPDATE: updated August 2011, with more detailed / idiot-proof instructions – and a couple of shortcuts. NB: when you’ve done this install once, and checked the relevant bits into your Source Control, it becomes *very* fast/easy to re-install – it’s only long-winded the first time.
I thought I’d blogged this before – the install process from Google is appalling, and I wrote up detailed instructions for colleagues about a year ago. Sadly, looks like I never published the post. I just did a fresh install on OS X (January 2011) and the process *still* is riddled with flaws. I get the impression Google won’t fix it anytime soon.
NB: the biggest single problem here is: Version Control. Someone at Google appears to believe that version control is “unimportant” and that developers should “not be expected to make reproducible builds of their software”.
But … even if you’re a sloppy programmer who doesn’t do proper version control, you probably STILL don’t want to use Google’s auto-installer. It can’t cope with basic stuff like “internet connection drops for a few seconds while ADSL re-dials” – things that your web-browser deals with perfectly. e.g. as of Jan 2011, the Android auto-installer managed to crash Eclipse just because of a blip in net connection. Pathetic, really.
(not to mention the hassle of re-downloading hundreds of meg of data over and over again for every PC in your office … this document will let you download most of it once only, and install it multiple times)
I don’t have a perfect solution, but here’s a guide for how to (mostly) un-**** the installation process for Android development.
Developing for Android: Essentials
The main IDE for Android is the (mostly excellent) Eclipse – with some custom plugins built by Google/Android folks. Once it’s up and running, it’s definitely the best free solution. To make this work, you need:
- Eclipse IDE … *any* flavour
- Android plugin for Eclipse (called “ADT”)
- The version-independent Android SDK (called “android-sdk”)
- A specific OS-version of Android (e.g. current latest is v2.3)
- NB: plus you need a “platform tools”, which you download/install in the same way, but is an extra file/feature
FYI: the first item is from Eclipse, the last 3 are all from Google. Although Google keeps trying to kick you in the teeth, you can workaround their foolishness relatively easily for the middle two items. The big problem is the last item. More on that later.
Installing Eclipse on OS X
What follows comes mostly from: http://eclipse.org
Once a year, I call-out Eclipse.org for the appalling user-experience of downloading and installing their software. They’ve had a decade to get this right, and they still get it so wrong.
As of Jan 2011: there’s been a big improvement recently – you can now find the download link quite easily. At http://eclipse.org/ there is an enormous “DOWNLOAD ECLIPSE” button in the top right of the page, in bright yellow. This is excellent.
Sadly, the download link DOES NOT DOWNLOAD ECLIPSE … instead it takes you to a screen that demands you choose the “correct” version out of 12 offered to you, with literally no help at all. The majority of users want one of only 3 versions from that screen. In fact, I suspect 99% of people that come via the front page only want one version.
Furthermore, there is *still* no download for OS X. There is *part of* a version for OS X, but no-one has done the 5-10 minutes of setup that would make it install correctly on OS X forever more. Instead, you have to manually muck about with your computer, your administrator account etc. FAIL.
1 of 4: download the “Eclipse IDE for Java Developers” file.
Unzip it. Unzip it *again*, because they decided to use archaic Unix compression instead of ZIP.
Now you have a new folder, called “eclipse”. You have to put this somewhere. There is (officially) no official location for this … good luck getting support if you put it in a “bad” place.
Most people drag/drop this folder to their Applications folder in Finder. This kind-of works, but again because the Eclipse team haven’t spent a few minutes making an OS X manifest (could have done this any time in the past few years!), the “Eclipse.app” file is broken. If you drag/drop that file to anywhere, it will stop working.
Instead, you have to manually create a shell script to run Eclipse. I’m not even going to go into it – if you want an Eclipse.app icon in the right place on OS X, Google for tutorials on how to make a working Alias specifically for this app (working around the broken one from Eclipse.org). Or … just live with the fact you have to navigate to the “eclipse” folder before you can start the application.
Download the necessary plugins for Android
What follows comes mostly from: http://developer.android.com
Immediate FAIL from Google: the download page lists *ONE* download file, out of the *FOUR* that are absolutely required in order to do Android development. There is no mention of the others :(. How am I supposed to install the software if you won’t give me the links? Your crummy auto-installer is no subsitute.
2 of 4: At least it will get you the SDK, so download that directly
… from the main download page
If you dig around the site, read through 3 sets of instructions that all tell you not to download anything, and keep bullying you into using the crappy auto-downloader instead, you’ll eventually find a file something like:
3 of 4: ADT ZIP file
(Jan 2011:) ADT-8.0.1.zip (if you google for “ADT-8” or “ADT-9” you might find future versions on the site, since Google refuses to put them in a sensible place anywhere). Alternatively, the latest version should always appear at the “magic URL”: http://dl-ssl.google.com/android/eclipse/site.xml.
(Aug 2011:) currently it’s on version 12 …
(usually, this download link is hidden in the section “Troubleshooting ADT Installation”. The Magic URL … I’ve never seen anywhere. You have to know how Eclipse works in order to deduce it. For the record, other companies (including Eclipse’s maintainers) put a webpage at the parent of that URL, to help normal users. This one just does a 404 Not Found)
Finally, you need the bit that Google *really* doesn’t want to give you: a specific version of Android OS to develop against. You need to find the URL for a “repository.xml”. In this case, you can see it flash up briefly when the auto-installer is refreshing the repository (the part that does this is called “the Android SDK and AVD Managers”). You can try that URL:
4 of 4: http://dl-ssl.google.com/android/repository/repository.xml
Google could easily have provided this URL in the docs, since it is the “official” index for downloading the other files you need, but for some reason they chose not to.
There’s 2 ways to avoid Google’s broken auto-installer (which you shouldn’t be using anyway, unless you don’t care about updating your own Android apps in future).
1. Create a local “fake” repository by manually reading an XML file and downloading each file by hand.
This used to work – in 2010, I used this successfully. In 2011, it refused to work. Something critical has changed in Eclipse so that it doesn’t recognize fake repositories – or I just couldn’t reverse-engineer the format correctly any more
2. OR: … download the files you want, and later manually copy them into the folder where Google requires them to be copied.
NB: the auto-installer often fails / timesout / dies when trying to do this. This is all it needs to do, but it’s rubbish. I’ve found that doing it by hand is usually less error-prone, tragically.
To download the files, you need the URL’s of each version of Android you want to support. Google refuses to put these in a webpage (why? Who knows?), but it’s not hard: open the XML link above – your browser should be able to view it directly:
http://dl-ssl.google.com/android/repository/repository.xml (opens fine in Firefox)
Scroll down – it’s a human-readable file – skipping the huge license. You’ll see a lot of “sdk-platform” sections – each of these is a single verison of Android, and contains one URL for you. e.g.:
<sdk:platform>
<sdk:version>1.1</sdk:version>
<sdk:api-level>2</sdk:api-level>
<sdk:revision>1</sdk:revision>
<sdk:description>Android SDK Platform 1.1_r1</sdk:description>
<sdk:desc-url>http://developer.android.com/sdk/android-1.1.html</sdk:desc-url>
<sdk:obsolete/>
<sdk:archives>
<sdk:archive os="windows" arch="any">
<sdk:size>46828615</sdk:size>
<sdk:checksum type="sha1">a4060f29ed39fc929c302836d488998c53c3002e</sdk:checksum>
<sdk:url>android-1.1_r1-windows.zip</sdk:url></sdk:archive>
<sdk:archive os="macosx" arch="any"><sdk:size>45584305</sdk:size>
<sdk:checksum type="sha1">e21dbcff45b7356657449ebb3c7e941be2bb5ebe</sdk:checksum>
<sdk:url>android-1.1_r1-macosx.zip</sdk:url>
</sdk:archive>
<sdk:archive os="linux" arch="any">
<sdk:size>45476658</sdk:size>
<sdk:checksum type="sha1">c054d25c9b4c6251fa49c2f9c54336998679d3fe</sdk:checksum>
<sdk:url>android-1.1_r1-linux.zip</sdk:url>
</sdk:archive>
</sdk:archives>
</sdk:platform>
For each one you want to download, look for the highlighted bit above. That gives you a filename – if there’s no OS X section, take the linux section instead.
You then append that filename to the URL you used to get the repository, i.e.:
“http://dl-ssl.google.com/android/repository/” + “[filename you picked above]”
I’m afraid you have to do this for each version of Android you want to build against – but for most people, that means “just the most recent few versions”.
5 of 4: another ZIP you need: “Platform tools”
You will *ALSO* need – while you’re at it – to grab an “Android SDK Platform-tools”. Google doesn’t mention this as a separate stage, because their auto-installer treats it as part of the 4-of-4 items above.
It’s another file with the URL stored in the same repository.xml from the above step.
However, it lives right at the bottom of the XML file, in a section that looks like this (there’s only one of them – no choices to make – just grab it):
<sdk:platform-tool>
<sdk:revision>06</sdk:revision>
<sdk:description>Android SDK Platform-tools, revision 6</sdk:description>
<sdk:desc-url>http://developer.android.com/sdk/</sdk:desc-url>
<sdk:archives>
<sdk:archive os="linux" arch="any">
<sdk:size>15398275</sdk:size>
<sdk:checksum type="sha1">292732c6a86971b95ca61ba8bf84cd9d6c2285c3</sdk:checksum>
<sdk:url>platform-tools_r06-linux.zip</sdk:url>
</sdk:archive>
<sdk:archive os="macosx" arch="any"><sdk:size>15127727</sdk:size>
<sdk:checksum type="sha1">86c958b461b6244e74b4e0489ea7cef9a681d882</sdk:checksum>
<sdk:url>platform-tools_r06-macosx.zip</sdk:url>
</sdk:archive>
<sdk:archive os="windows" arch="any">
<sdk:size>16589948</sdk:size>
<sdk:checksum type="sha1">14acb6271c71dce94bba879496cd66e09ae144af</sdk:checksum>
<sdk:url>platform-tools_r06-windows.zip</sdk:url>
</sdk:archive>
</sdk:archives>
</sdk:platform-tool>
Installing ADT (the “eclipse plugin for Android”)
If you downloaded this directly, as detailed above, then Google’s post-install instructions are weak. The download ZIP also has no install instructions with it. Here’s a short version:
- Unzip the ADT file (Google is happy with ZIP, unlike Eclipse)
- Create a “magic” folder for Eclipse somewhere, which is where you’ll store all your Android SDK’s, ADT plugins, etc. Create a sub-folder “local repositories”
- Move the ADT folder into “local repositories” (you will probably want to upgrade this later, so you need to be able to find it easily)
- (NB: sad design flaw of the auto-updater – it’s hardcoded that you MUST give each repository a unique “name”, even when this makes no sense to the developer)
- … NB: as of August 2011 … what follows is pieced together from Google’s incoherent documentation – you won’t find these steps written clearly + correctly anywhere on the developer.android.com website :(
- [aug 2011]: “Start Eclipse, then select Help > Install New Software….”
- [aug 2011]: “Click Add, in the top-right corner.”
- [aug 2011]: In the Add Site dialog, click Local (not “Archive”, as per Google’s instructions – Archive causes other problems later on)
- [aug 2011]: Browse and select the folder you unzipped/created/moved in step 3
- [aug 2011]: “Enter a name for the local update site (e.g., “ADT Plugin”) in the “Name” field.”
- [aug 2011]: “Click OK”
- [aug 2011]: “In the Available Software dialog, select the checkbox next to Developer Tools and click Next.”
- [aug 2011]: “In the next window, you’ll see a list of the tools to be downloaded. Click Next.”
- [aug 2011]: “Read and accept the license agreements, then click Finish. ”
- [aug 2011]: …Google doesn’t admit this, but some of the ADT components aren’t signed, which is a security hole. Eclipse rightly says: “Dude, are you sure you want to install unsafe software?”. You have no alternative, though – until Google re-builds the plugin to be properly signed, you just have to accept it.
- [aug 2011]: “When the installation completes, restart Eclipse.”
Jan 2011: Bizarrely, at this point the auto-updater hangs for a few minutes, randomly contacting internet sites for stuff that I expressly did NOT attempt to install. I’m not sure if this is a bug in the current Eclipse, that it “hi-jacks” the plugin-install process and tries to update the rest of Eclipse, or if it’s a “feature” of the Android plugin – that it secretly triggers additional installs from the internet.
Installing the SDK
In Google’s docs, there’s a whole page for installing the SDK.
It does not – at any point – tell you how to install the SDK.
Instead, that information is inside the page for installing the ADT plugin for Eclipse.
Genius!
To save you navigating their bizarre instructions, I’ll copy/paste them here. First, however, you need to create a local install directory for the SDK (they forget this step, of course). Put it somewhere that you’ll never accidentally modify or delete – if you do, Android apps will stop building in Eclipse until you manually fix everything again. Given how tortuous the main instructions are, I’ve seen smart people diagnose the problem but have massive trouble figuring out exactly how to rectify it.
Anyway, once you’ve picked a location, unzip your SDK zip file into that folder, and proceed with Google’s instructions:
1. Select Window > Preferences… to open the Preferences panel (Mac OS X: Eclipse > Preferences).
2. Select Android from the left panel.
3. For the SDK Location in the main panel, click Browse… and locate the directory that was created when you unzipped (Google words this badly – it MUST be the folder that came out of the ZIP – Eclipse will check the contents of the folder, and reject if you select its parent folder, or one of its children)
4. Click Apply, then OK.
Installing the “Android Platform versions”
This is the install part that matches the “4 of 4” download part above.
Take each ZIP file you downloaded, and unzip it.
e.g.:
- android-3.2_r01-linux.zip
This will give you an *incorrectly named* folder, e.g:
- android-3.2_r01/
…you *may* need to manually rename this using the “<sdk:api-level>13</sdk:api-level>” tag that was in the original repository.xml where you got the download URL from. Each downloadable ZIP file had a different – unique – api-level tag.
The new format (I’m not sure this is required, but it’s what the installer does, so I recommend doing it):
- android-13/
Finally (!) … find the folder where you unzipped the SDK earlier. That will have files/folders very similar to the following:
- add-ons/
- platforms/
- tools/
- SDK Readme.txt
Take your (possibly renamed) folder – in my case “android-13/” – and move it into the “platforms” subfolder.
The ADT Eclipse plugin will automatically discover this when you restart.
…go through the same process for each Android Platform version you downloaded.
Shortcut: if you’ve done this before, with a previous version of Eclipse / ADT / Android … you can just take the sub-folders of “platforms/” from your previous install, and copy/paste them into the “platforms/” sub-folder of your nw SDK version. Easy.
Installing the “Android Platform Tools”
…this works in exactly the same way as the “Android Platform versions” above, except it goes in a different folder.
In this case, you need to take the zip file, unzip it, and rename the output folder to precisely:
- platform-tools/
…then copy/paste it directly into the SDK folder. There shouldn’t be a “platform-tools/” folder to start with – this is how Eclipse/ADT knows whether or not you’ve “installed” it: it just looks for a folder with that name.
OPTIONAL: Downloading + Installing the Android SDK documentation
UPDATE: sorry, I missed this out originally.
Again, just like with the “Android Platform Tools”, you have to manually grab the URL for this from the repository.xml
The piece of XML in the repository.xml you need is:
<sdk:doc>
<sdk:api-level>13</sdk:api-level>
<sdk:codename/>
<sdk:revision>01</sdk:revision>
<sdk:description>Android SDK Docs for Android API 13, revision 1</sdk:description>
<sdk:desc-url>http://developer.android.com/sdk/</sdk:desc-url>
<sdk:archives>
<sdk:archive os="any" arch="any">
<sdk:size>103791308</sdk:size>
<sdk:checksum type="sha1">5dadb3b30e1f837716f8a5ef840e31abddf69b38</sdk:checksum>
<sdk:url>docs-3.2_r01-linux.zip</sdk:url>
</sdk:archive>
</sdk:archives>
</sdk:doc>
…then take the zip file, unzip it, and rename the output folder to precisely:
- docs/
…then copy/paste it directly into the SDK folder.
Done!
Phew! Finally! You should now be set for Android development!
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
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.
“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:
- does Ubisoft do this level of automated-bug-detection,
- do their designers bother to look at the anomaly-date,
- and if so … why hasn’t the game been patched?
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?
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:
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)
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).