« August 2004 | Main | October 2004 »
September 25, 2004
How to give away your games code by accident!
Yesterday one of the guys I work with discovered that a recently released PlayStation2 game has a complete *annotated* source listing on the DVD, sitting as a text file for everyone to see (if they put the DVD into a PC).
This is incredible, the source lists both the games code plus the library code in a format that experienced programmers could easily take and learn from. A kind of involuntary Open Source :-)
I'm not going to name the game here (contact me by email if you want more info). I'm more interested in the incredibly lax checking of the master disk for that particular product. How this can get through to the consumer is a mystery to me (although do I understand the pressures involved at the end of a project)
To get this file onto the DVD there are several things that need to happen.
1. The file must be generated and kept (not always done, it's often discarded as an intermediate file by the compiler)
2. The Lead Programmer needs to place that file into the games disk layout (or whoever does this job) - it would usually reside somewhere unrelated for most projects.
3. The Producer/QA Lead have to not notice the file is there
4. Sony have to not notice the file is there.
Now given that the file was called "SOURCE.TXT" you'd think it might be obvious :-)
Then again, on our most recently released game, I never actually searched through the disk looking for anything inappropriate - mostly because we had the process down to a fine art and it was all automated from a clean directory structure... but you can be damn sure I will be looking for ways to improve our process.
How many people actually get to place files on the disk ? Technically it's just one, but that person relies on other people placing appropriate material in a directory structure that grows and changes over 18 months, and by the end nobody can quite remember which files are needed and which are not!
We've seen in the past that innapropriate material has made it's way onto game disks, and in other cases sourcecode has been stolen, but this is the first time I've seen (first hand) that a company has unwittingly published a version of their source on the gold master and it's made it into the stores!
I'd hate to see the lawyers faces when they find out. I have no idea how this would be dealt with in court, you can just look at the file in a text viewer so there's no 'evilness' on the consumers behalf to look at the source.
If you are responsible for mastering your companies game, take the time to check what you're mastering - make sure there's nothing there thats not meant to be there!
One technique that can be used is to make a utility to list all the files accessed during a series of runs of the game, leaving you with a list of what hasnt been used - then see if anything there seems 'odd'. Games have been removed from the shelves for having 'adult material' lying around, or for containing copyright material (even though the game never accessed the files).
Does anyone know a better way ?
Posted by Zaph at 12:16 PM | Comments (5) | TrackBack
September 21, 2004
You can't plan for everything
So you think your beta testing sometimes has problems ?
Spare a thought for the team making World of Warcraft. The building housing their beta-servers was hit by a tornado on Friday night. They seem confident that things will be back up and running soon, although they include the slightly amusing comment that the hardware is not yet dry enough to be powered up.
WoW is a big project, they've got backups and plans to cope (although perhaps not for this specific scenario!).
What would happen to your project if your building was destroyed ? How long until you'd be back up and running ?
If you are lucky then there is an easy-to-access off-site backup of all the code and data. My guess is that it's probably a week old, but most teams can cope with that. However some games developers aren't that lucky, I know (from experience) that in the past off-site backups were haphazard at best in game development companies, there was an assumption that nothing that bad could ever happen.
And even if the backups were recovered, do they contain everything ?
- Sourcecode - probably
- Artwork - probably
- Source art (XSI/Maya scenes) - less likely for smaller companies
- Music/Audio source ?
- FMV/CGI source ?
- email archives, design documents ?
It's a scary thought that many game developers still haven't grown up and started enforcing a regime that protects them against the unexpected...
Posted by Zaph at 08:27 AM | Comments (1) | TrackBack
September 20, 2004
iPod, iTunes, and assumptions by programmers
This isn't strictly gaming related but it demonstrates another common mistake by developers so it's worth a read (if I do say so myself).
On Saturday my wife gave me an iPod for my birthday - a wonderful present. It's the 4th generation 40gb model, beautifuly designed.
With it comes iTunes, Apples software for ripping CD's and syncing with the iPod.
Here's where the story gets interesting. The iPod can connect via FireWire or USB2, I have both, yet I was unable to get iTunes (or the other Apple software) to recognise the iPod. Eventually I did so on a crappy laptop, just to prove that the iPod worked.
After a few hours of fiddling around I was getting frustrated - I wanted to use my desktop and firewire as the means of updating the iPod. Apples webpages were useless to me, nothing in them helped, but I discovered that most 3rd party freeware/shareware could in fact see the iPod - which made me start to wonder.
One of the unusual things about my PC is that I have no C: drive. My first harddrive is F. I often come across programs (including games) which assume I have a C: drive for them to write to. It's a bad assumption by programmers who think that every PC has a C: as a bootable harddrive. In my case my removable hardware (iPod, CF reader) appear at C: when connected.
I guessed that iTunes was looking for the iPod at drive letters above C: - so I popped in to "My Computer -> Manage -> Storage -> Disk Management" and change the drive letter for the iPod (while it's connected) to I:
and presto, iTunes suddenly realises I do actually have an iPod connected!
This is not documented anywhere on Apples website (although I have submitted feedback for them). I've already found one other person (over at iPodLounge) who had the same symptoms and nobody had been able to help, until he saw my post and discovered the fix worked for him as well.
Programmers are normal people, they make assumptions about things that have held true for many years. For the longest time every PC had a C: - but these days it's not required (WinXP, probably Win2k too). The games industry is just as bad as everyone else, I've had games that failed to install because they couldnt see my C: I've also had problems due to not having a floppy drive in my PC!
If you are making a Windows PC game then you should add to your testing regime the testing of an installation which has no C: - most of you will be fine but you can never be too careful.
Posted by Zaph at 08:16 AM | Comments (4) | TrackBack
September 14, 2004
GBA Movie player v2
I just ordered myself the 3rd party GBA Movie Player from Lik Sang. I have no real idea how good it is, but for US$25 I don't think I can really go too far wrong.
This thing will play movies (after converting to a special format) direct from a compact-flash card, it can also be used for ebooks and mp3's. And one of the coolest things is that it has a NES emulator that can play ROMs of up to 192kb, and supposedly also homebrew games of up to 192kb.
Other GBA news, I picked up Mario vs Donkey Kong today, and I've got my eyes fixed on Metal Slug Advance which is getting release soon. (I often order GBA stuff from Lik Sang because there is no region encoding on the GBA, which means all versions work - they just might not link together properly)
Posted by Zaph at 04:31 PM | Comments (4) | TrackBack
September 12, 2004
Burnout 3, rewards and game design
Yesterday I bought an Xbox and Burnout3. I was originally going to get B3 for the PS2, but bit the bullet and picked up an Xbox because of some upcoming games I'm interested in.
Burnout3:Takedown has an example of really smart game design in it, something that we (developers/designers) often overlook while making pretty graphics and big explosions.
Rewards, thats what I'm talking about. In Burnout3 unlocking 'stuff' is basically done with points and money, both of which can be earned by anyone who plays the game. You don't have to be a great player - you just have to play. Sure there's stuff that requires you win an event to unlock it, but theres a mass of stuff for the newcomer to unlock just through playing (even without winning).
It's all about rewarding the player before they stop playing. Sid Meier is one of the great proponents of this, I've heard him talk about reward schemes which keep the player hooked. Sids games are the best in the world at this, he really knows how to keep a player coming back to the game even when they should be in bed/at work/etc. Bruce Shelley is another who knows the importance of rewards (of course he worked with Sid for years, so it's not suprising).
Burnout3 does this nicely aswell. Rewards of new cars or new races every 5-10 minutes. These keep you playing in the short term because theres likely to be something new in the next 5-10 minutes, and it's what stops you turning the machine off. At the same time the loading screens show you distant rewards, along with information about how to attain them (e.g. earn $5,000,000 in crash mode). These longer term rewards are what keeps you coming back to turn the machine back on.
Take a look at your favourite (most addictive) games and ask yourself if they fit this pattern or not, you'll often find the best games are doing this without you even realising it's going on.
Posted by Zaph at 09:40 AM | Comments (1) | TrackBack
September 10, 2004
Games Development Teaching
A little more info on the Games Development Teaching conference/forum in October here in Melbourne, 19-21 October.
The Games Development Teaching - An Industry-Education Forum is brought to you by the Game Developers' Association of Australia, and supported by Multimedia Victoria.
The purpose of the Forum is to bring together industry and education to share current information and knowledge about Victoria's electronic games industry.
The objective is to improve the skills base of the industry, and expand Victoria's electronic games industry.
The Forum runs over 3 days - October 19, 20 and 21, 2004. It will be held at the training centre of the GDAA, Level 8, 14 Queens Road, Melbourne.
The event is obviously targetted at the Education industry. It is free to attend, but registration is required (see the website).
I'll be speaking for two sessions:
The first is on Day two at 12:50pm, speaking about the practical realities of game development.
The second session is also on Day 2, at 1:30pm jointly with Mark Morrison - a case study of a large-scale game development project (Transformers)
If you have any suggestions of things that you think are important for me to talk about (in either session) then please let me know (either as a comment on this blog or send me an email)
Posted by Zaph at 03:53 PM | Comments (0) | TrackBack
September 08, 2004
Speaking at upcoming Game Dev. Teaching conference
In October I'll be speaking at the Game Development Teaching conference in Melbourne. I've got two sessions, the first is on Day two at 12:50pm, speaking about the practical realities of game development.
The second is also on Day 2, at 1:30pm jointly with Mark Morrison - a case study of a large-scale game development project (Transformers)
Check out the website for more information.
Posted by Zaph at 10:55 AM | Comments (0) | TrackBack
September 04, 2004
Tribes Vengance open beta comments
Today the public beta for Tribes Vengance became available at fileplanet (note, you can download from many sources, but need to get a key from the Fileplanet link).
Anyway, I grabbed the 480mb download and thought I'd have a play, since it's made by our mates at Irrational Games Aussie studio.
First up, let me say the beta is fun - but I want to focus on an issue it raised for me.
I don't think the user interface was ready for a public (open) beta.
There are several bugs and difficulties in the beta that make it hard even for a seasoned gamer like me to do simple things like change my name! There are options that are usable but do not work - these should be greyed out for the public. Dropdown lists that dont actually display the list, and other things that must seem minor to the developers but are major for the public (and their potential customers).
Don't get me wrong, I know it's a beta - but if you are going public with a beta you need to make sure they can use it without getting frustrated before they play! I'm less concerned about the game totally locking up my machine (once) than I am about my inability to change my name even though it appears I should be able to do so.
We (game developers) make this kind of mistake all the time, we are too close to our work to realise that some 'trivial' things (like UI) are actually critically important to the end user - even in a Beta. It doesn't matter if the UI isn't final, just make sure the bits turned on work properly and turn off all the other bits. Nobody is going to get upset if you change the UI for the final release (unless you break it!)
Another example of this is the Evil Genius demo which came out a couple of days ago. Because of the counter-intuitive User Interface almost everyone I know has thought the demo is broken at the point you need to interrogate the spy. The reason ? Evil Genius expects you to right-click on a particular thing, yet gives you a mouse cursor that makes you think a left-click would work. How sad that this has lead to numerous forum posts about a broken game - even though the game does tell have a help screen that says you need to right click, it's just counter-intuituve and it leaves you with a bad taste for what could still be a great game.
I've seen gameplayers throw down a controller in disgust at a non-intuitive user interface, and since we're trying to get people to play the game it's sad that something else (in our eyes) can turn them away.
I'll wrap up with this:
Tribes:Vengance rocks. I'll be playing the crap out of the Beta, I'll be buying it, I'll recover from my afternoons frustration and continue :-) You'll find me on the GameArena servers (username: Zaph, no longer Player 3 !)
Posted by Zaph at 06:43 PM | Comments (0) | TrackBack
September 03, 2004
MovableType 3.1, MT-Blacklist
I've upgraded to MovableType 3.1, and at the same time I've added the excellent spam-blocking MT-Blacklist plugin (2.0e) - now I just have to wait to see if it is working :-)
If you see something wrong please let me know ASAP!
Posted by Zaph at 09:15 AM | Comments (0) | TrackBack
September 02, 2004
Open source for game developers ?
While reading this article on slashdot today I actually posted a reply because I think some people don't understand the difference between Open Source and all the other things that go into developing a game.
In this specific case I wanted to point out that making an open source racing game over the net does not automatically excempt the authors from obeying the law. The rights to cars, drivers, racing tracks, logos, etc are all owned by their respective owners, and their rights must be observed. You cannot go out and make an F1 open source game and expect to get away with it, nor can you make an OS Shrek game, or even a "My dinner with Andre" game.
But thats a distraction from the real question, which was: "Is Open Source an advantage for game developers"
Simple answer: Yes
In fact I've used open source in games - our most recent (Transformers) used an open source JPEG library (properly credited in the manual). We've also used other open source in the past (usually stuff that has absolutely no licensing requirements so that the lawyers are kept happy)
There are some wonderful OS bits and pieces out there that can be used to further games development, but since the sourcecode is such a small part of games development (monetarily speaking) it does not solve the question of cost, which is what many OS advocates assume it fixes.
The cost of making a game can be roughly broken down into (in no particular order):
- Code
- Art (often more expensive than the code)
- Sound (nobody spends enough on this)
- QA
- Project Management
- Licensing (sometimes the most expensive part)
- Marketing (usually the most expensive part)
- Admin
- General business running costs (rent, power, water, beer&chips, etc)
While code isn't cheap (we have ~25 programmers) it is by no means the most expensive part - in fact even if the code was free the overall development costs may only drop by a small percentage (it does depend on the platform and title obviously).
Don't expect Open Source to magically solve all your money problems, but DO look around to see whats out there, especially if you are a startup company with limited resources - sometimes the wheel has already been invented. Just make sure you hand the licensing agreement to your lawyers.
Edit: The guys at Motor-sim do understand the legalities of using licensed stuff :-) but I suspect many readers wouldn't realise the issues.
Posted by Zaph at 08:46 AM | Comments (1) | TrackBack