« September 2004 | Main | November 2004 »
October 24, 2004
Massively Multiplayer
I've been playing City of Heroes for the last week or so, having a great time. One of the things that interests me is how the game manages players of differing levels in the same world. Usually you don't seem to come across creatures more than a few levels above you due to the places your missions take you - but yesterday while running around looking for some action some mechanical thing crashed to the ground in front of me (dead) and it was the last thing I saw before a nearby battle (of true superheroes) claimed me as an innocent bystander, killed with one single shot that wasn't particularly meant for me!
So far the game has been most entertaining, no noticable lag issues (that hurt playability) despite me connecting from Australia. The populace are extremely friendly - the superheroes involved in the battle that claimed my life popped over and resurrected me once it was safe to do so.
Whether the game holds my interest beyond a couple of months (at which point it begins to be more expensive than a traditional game) remains to be seen, and that probably depends on whether my friends keep playing (the game is made for teams, you shouldn't play it alone)
Posted by Zaph at 04:55 PM | Comments (1) | TrackBack
October 21, 2004
Games Development Teaching & optimisation
I've spent the last two days at the Games Development Teaching forum here in Melbourne. It has been very enlightning to talk to some of the people running Games Dev courses and seeing the gap of knowledge that exists between education and industry, and how we are going to address that gap.
One of the most disturbing things I heard (for me, as a programmer) was that one institution had been told to stop teaching optimisation techniques because "compilers do it all for you" (not just in game-dev, but throughout CompSci). This came up because I'd just been talking about the need for games programmers to have a good understanding of optimisation, and to NEVER trust the compiler to do it all for you!
MSVC++ is a pretty good optimising compiler, as is Intels Win32 compiler. I can understand why people might think that this means all compilers are good (even though they are nothing compared to the human brain). However when you enter the world of gcc you discover that it's not a great optimising compiler, and then you head down to console-specific compilers which are lucky just to compile the code correctly (since their hardware target has only existed a few years). The console games industry lives at the bottom level of this rung, while the compilers do a good job getting the games to run they cannot be trusted to make optimisation decisions for you 100% of the time.
In the games industry we deal in nanoseconds and manually optimising code is the only way to do this (in hand with tools like vtune and similar) - It worries me that I see new programmers who don't know things as simple as moving lines of code outside a loop to improve performance, because somebody else assumed the compiler would do it for them.
Posted by Zaph at 08:45 AM | Comments (0) | TrackBack
October 11, 2004
Writing better software (Alan Cox)
Alan Cox gave a talk in Wales about writing better software. He has some great things in there to think about and compare to the way you make software (whether you are a programmer or not, it's still good reading)
I found it quite pleasing that we are doing at least a few things right - but still plenty of room for improvement. The video of the talk is also available for download
Also, another link I was pointed to during the week, the famous Donald Knuth has the pre-fascicles for Art of Programming Volume 4 available for download on his webpage. Great reading for programmer-types.
Posted by Zaph at 01:27 PM | Comments (0) | TrackBack
October 10, 2004
using the internet to improve my iTrip
My wife bought me an iPod for my birthday last month. A wonderful present, I love the thing - much better than my RioVolt MP3 CD player that I was previously using.
I mostly use the iPod in the car, with a cassette adaptor, however my wifes car doesnt have a tape player... so I went and bought an iTrip today. This thing broadcasts your iPod on the FM band over a very small distance.
Since I'll be using it around town and also when venturing up to Yackandandah to visit my dad, I thought it would be good to set it to a radio frequency that suits all those areas.
So, I turn on the computer and start Googling around... lo-and-behold I discover that the Australian Broadcasting Authority has a webpage that has a list of all FM stations in Australia, sorted by frequency.
You have to love it when an organisation puts the exact info you want into an easy-to-read freely available format :-)
The list even has latitude and longitude information, so if I could be bothered I could write a little program to pick the frequency based on the places I visit (from my GPS) :-)
Posted by Zaph at 11:45 AM | Comments (0) | TrackBack
October 08, 2004
Terminology that isn't obvious
A few weeks ago I installed MT-Blacklist to this Blog, it's been doing a great job blocking spam-comments. However today I ran into a small problem, there was a trackback entry from Jason Della Rocca's IGDA blog 'Reality Panic' which it asked me to check (it was a link to this article). I was shown the entry, and asked if I wanted to 'de-spam' it. Since it wasn't spam, I said yes. Now you can see whats coming, in this context 'de-spam' meant remove as spam, whereas I thought it meant to mark it as not-spam. Doh!
Why do we create words like this where the meaning is not clear to everyone ? Instead of saying 'despam' it could have easily said 'mark as spam and delete'.
I see this in games as well, words either being chosen poorly or invented for the purposes of the game. I'm sure you can think of lots of examples yourself. I suspect that most projects do not employ someone to actively check all the strings in the game for context and content.
Recently, on our current project, I created a Bugzilla component called "String Approval" (or something like that). The idea is that any string displayed in the game gets entered into that component and at some point before we ship it will be approved/changed/deleted by someone qualified to do so. This is going to help us create a game that is more easily understood by the public, and it will also help with translations (if the meaning is clear, the translations are easier and less prone to error).
Posted by Zaph at 08:43 AM | Comments (2) | TrackBack
October 04, 2004
Everybodies code sucks
A good friend of mine, Jon, who was there in my formative years as a professional programmer, has just blogged a great link by Dave Astel: Why your code sucks. Basically there are a bunch of reasons that peoples code can be considered as sucking (read Daves blog for the details)
How does this relate to games development ? Pretty much all game code sucks :-) Although I have come across some amazingly beautiful snippets of code, the majority is poorly put together, badly documented, hard to test, not working, etc.
I can hear the cries now of "deadline pressures", "performance issues" and other reasons as to why code sucks - but thats no reason not to strive for a better programming world.
Let me say this first, My code sucks. I'm a self-taught programmer for the most part (Uni taught me lots, but by then I had been programming for 5-6 years and had bad habits!). I've also stopped programming full-time since becoming a producer, so my code is even more hacky than before :-)
I have a book on my bookshelf, "Games for your TI99/4A" which contains my first ever published games (back in 1983/4) - a quick scan of the source code in that book reminds me how far I've come, but also to remind me that code I think is fantastic will, in hindsight, turn out to suck :-)
As a Producer I get to see things from a different viewpoint. Bad code has terrible consequences for a team (even if the individual can't see it). I've seen code thrown away because nobody could understand it, I've seen duplication of code and effort by programmers who didn't communicate and realise they were writing the same functionality. Worst of all (IMHO) is the code that cannot be debugged by anyone other than the original author, and cannot even be tested because the work it does is unknown.
Then again, there are real-world considerations to be made. We're in a business, we need to make money to survive and that means finishing a project. Finding the balance between 'perfect' code and 'damaging' code is difficult and almost impossible to define. Show any good programmer a reasonable sized block of code and they will be able to show you how to improve it. The question is a balance of resources between creating the initial code, making it less and less sucky, and getting on with the next bit of code so that the game gets finished and you get paid.
One of the things I like to see is the occasional (and appropriately timed) rewriting of important sections of code in a game. This is usually limited to 2-3 weeks work (for one person) and the condition is that it must replace the existing code with the same functionality (very important). We don't do this very often, but when we do it's usually a great move and pays for itself many times over.
I'm proud of my sucky code (there's code in our systems that I wrote 4-5 years ago that has no right to still be alive). I am even prouder when someone gets the chance to go over the code and improve it, bringing it into the 21st century with all the trimmings of professional code development.
Those people that are better disciplined than I are able to start their first version of their code in a much better state, and everyone is better for it, but it's worth remembering that it's always going to suck :-)
Don't get too attached to your code, accept that it's the idea behind the code thats cool and elegant - the implementation can always be improved.
Posted by Zaph at 08:36 PM | Comments (3) | TrackBack
October 01, 2004
GBA Movie Player - review
I received my GBA Movie Player from Lik Sang. A few people have asked about it so here's a quick review.
Keep in mind, this thing only costs US$25 :-)
Physically it's a flimsy plastic box, but it holds together and fits snugly in the GBA.
The software is a little flakey, but it works. I converted a recent episode of The Simpsons and damn it looks good (animation works really well). The framerate is ~8-10fps at a guess, the audio is reasonably good. The Simpsons was a 21 minute show, which looked great at 50mb, so I could probably fit 8-10 episodes on a 512mb CF card.
I then converted StarLego - which was mastered at ~8fps originally, and at a similar resolution to the player - and damn it looks great (and the THX logo on a GBA gives you a laugh)
Audio-sync is a problem, but the designers seem to have understood that and put in the ability to skip/pause the audio for 1/10th of a second in each direction. A few presses of this will fix the audio sync problem (wish I had that feature on my DVD player!)
I've read that converting the audio and video separately can achieve better results, but I have not tried this yet.
The photo viewer is nice, you convert to BMP then display. Some of my images came out green with the included software but I'll bet you can just convert in other packages.
The NES emulator does not come with the device, you just grab the latest PocketNES freeware and use that! very very cool, and a great way to get some old-school games onto your GBA. The device cannot write to the CF so high-scores cannot be saved. You can play NES roms up to 192kb. Sadly you can't play GBA roms, even if they are small enough (although I bet theres a way to get around that using PocketNES as a launcher, I might try one day!)
Even the text viewer is good - not that I'd use the device for that, but the feature works well and the font is quite readable.
So, if you happen to be making an order at Lik Sang and also have a CF card (128mb+) handy, then it might be worth the US$25 to pick up the GBA Movie Player for a little bit of fun! - I can't think of a serious application for it, it's mostly the geek factor of showing movies playing on your GBA (although 10 episodes of The Simpsons could be handy on holidays!)
Posted by Zaph at 08:34 AM | Comments (0) | TrackBack