Game development and life.
Creation is the state of art.
May 14th, 2009 by Mark Cooke
I’ve been watching some of the NBA finals games via the NBA International League Pass. For about $40 you can get access to all the games of the playoffs and finals when living outside of the US. It’s convenient and works fairly well.
During halftime I was surprised to see the WoW logo.
It was kind of shocking to hear the announcer say the words “World of Warcraft.” That’s the first time I’ve seen a non-sports game being advertised in a sporting event. The game industry has come a long way.
May 11th, 2009 by Mark Cooke
I highly recommend checking out Windosill, an awesome interactive game experience by artist Patrick Smith aka Vectorpark.
The goal is to move the little toy car throughout an interactive environment. I wont say anything else about it because I don’t want to ruin it. The combination of artist work and the response to use touch just feels incredible. It really shows how enjoyable interactivity is the cross section of art and the code that drives the response to that touch and interactivity.
You can play the first half of the game for free. The full experience is $3.
May 5th, 2009 by Mark Cooke
For the past few hours I’ve been slamming my head against the wall trying to get these features working together: background playback of iPod audio, OpenAL playback of in-game events, and microphone recording. Microphone recording is not compatible with iPod audio and that is OK. When I enable the mic midway through program execution all I wanted to do was switch the session category and let the OS kill the music but it wasn’t working. I finally came up with a workaround and am writing this up for anyone else who runs into this issue.
Problem #1: don’t initialize OpenAL before initializing an audio session explicitly. If you do, iPod audio will be killed as OpenAL comes up. I couldn’t find any documentation on how this affects the session category.
To let the iPod continue to play you need to initialize an audio session and set the category to kAudioSessionCategory_UserInterfaceSoundEffects or kAudioSessionCategory_AmbientSound (info here). Make sure you do this first.
Problem #2: the OS will not let you change session categories if you first set your audio session – as above – and then start OpenAL. Why? I have no idea, the error code the API function returns is not a documented error.
I had to completely tear down OpenAL first and then call AudioSessionSetActive(false); to shutdown my initial audio session. Then I was able to change the category, restart the session, and finally restart OpenAL. Yes, this also means that I have to free all of my application’s sounds and reload them. This causes additional time the user has to wait for the sounds to reload. In the end it works but is not pretty.
May 4th, 2009 by Mark Cooke
The Japanese version of Get Dirk Drunk is nearly complete. Entitled “Hebereke-kun” – which translates to something like “piss drunk guy” – the software, art, and website is done. All that is left is to record his voice, which a Japanese friend of mine is going to do, and then submit it to the App Store. I recorded place holder voices for Hebereke-kun myself but a native speaker will do much better. See the website for Hebereke-kun here.
Thanks go to James Kay for localizing the art quickly. As usual he has done a bang up job.
I hope with the drinking culture over here that a salary man drinking game will catch fire! This guy has been playing the game too much:
April 23rd, 2009 by Mark Cooke
About a month ago I was showing one of my friends – a bartender here in Tokyo – some applications on my iPhone. He asked “why is there no cocktail mixing application?” and I had to reply “I dunno!” And so Get Dirk Drunk was born.
What began as a simple cocktail mixing toy turned into the glorious game you see before you. In the game you play as the local bartender. Further explanation is on the website:
Dirk is your average guy out on the town on a Friday night. He has had a tough week slaving away for his corporate overlords and it is time for a drink. That’s where you come in. As the bartender of the local drinking establishment you’ve got to keep mixing drinks and pouring them into Dirk’s mouth to keep him drunk. If he sobers up, you lose!
So be a pal and Get Dirk Drunk!
If it isn’t obvious from the trailer the game has its tongue firmly planted in cheek. I built it in my spare time and it was easy to make time in my schedule as the game involves two things I enjoy: silly, crude humor and drinking.
I wanted to go through the full process of releasing an application – idea, design, development, hiring outsourcing, release preparation, marketing, licensing, etc. – to get more experience in the areas I haven’t had the chance to work in on the large teams I’ve been on. Specifically I wanted to gain more experience in the production side of the business and though this is a tiny minigame going through the process was valuable. It is onward and upwards from here.
Now, be a pal and go and help Get Dirk Drunk! iTunes store link.
(please drink responsibly)
April 11th, 2009 by Mark Cooke
Zombie Apocalypse, the recently announced zombie shooter for PSN and XBLA, is one of the games I have been working on recently. I worked primarily on gameplay, AI, weapon, and player control systems. I’m proud of the results and think it is especially fun when playing with your friends in the up-to-four player simultaneous multiplayer game modes. Congratulations to everyone involved at Nihilistic and Konami for finishing off the project strong.
Check out the video below for a sample of gameplay.
April 10th, 2009 by Mark Cooke
In the “Health & Fitness” section of the Japanese Apple application store the free version of Prescription for Sleep is the most popular application.
The application is much more popular in Japan than it is in the rest of the world currently. I’m not sure why that is given that there are far more iPhones in the US and Europe. Certainly having it localized in Japanese helped immensly but that doesn’t account for its comparatively lower download count in other countries. There may be cultural elements at work here I don’t understand. The idea for the application was conceived by a Japanese person after all and perhaps simply appeals more here.
The application certainly isn’t for everyone but it is nice to see that a good number of users are enjoying it.
April 8th, 2009 by Mark Cooke
On a recent trip to the US I dug up some old items of mine from storage that indicate the beginning of my game developer roots. First, here’s a picture of me at 15 years old along with John Romero, Adrian Carmack, and Shawn Green from id Software. It was taken in 1996 at the Computer Game Developers Conference, or CGDC, which later became the GDC we know and love today.
At the time this was taken I was playing a lot of Doom 2 and it was awesome for those guys to take some time out to chat with an aspiring game developer who looked up to them. I ran into Romero at GDC 2009 and he was just as friendly as ever. Doom 2 is still one of my all time favorite games.
The photocopied check in the upper right is from my first job as an intern at a defunct game developer named Rocket Science Games. That company was in a building on 2nd and Townsend in San Francisco. The same building now houses Secret Level and ngmoco.
Next we move onto early experiments in game design. Below is a map of a pen and paper RPG (geek alert) I created as a kid with a childhood friend of mine. Construction paper for the win!
We were working on that right around the same time I started to teach myself how to program, around 11 years old. The game was called “Catiso”. I don’t remember many of the details unfortunately but I do remember that we had a rulebook to go along with the maps. Hopefully I’ll find that someday. I bet lots of game developers have fun game designs from their youth too. It would be great if someone shared a story in the comments.
Finally, this isn’t related to me but here is a cool video from Romero that was recorded during the creation of Doom. It’s great that he uploaded it – it’s fun to see how small id Software was during the creation of one of the biggest games of all time.
A Visit to id Software from john romero on Vimeo.
April 2nd, 2009 by Mark Cooke
Can you understand how this works?
float InvSqrt (float x)
{
float xhalf = 0.5f*x;
int i = *(int*)&x;
i = 0x5f3759df - (i>>1);
x = *(float*)&i;
x = x*(1.5f - xhalf*x*x);
return x;
}
There are some crazy approximations in that code that take use of the x86 architecture and implementation details of IEEE floating point. It popped up in the open-source Quake 3 code base but apparently has a history going much further back.
An author at Beyond3D spent some time trying to figure out who wrote the code. Here’s the article on his findings. Pretty crazy. And for the record, no, I don’t understand how the math in that function actually works. It is pretty cool though.
March 21st, 2009 by Mark Cooke
Are you working in the game industry already or want to break in? Do you want to be an awesome game tester that is highly valued and earns the respect of the team? You should if you want to do your job well and open up your career to the widest range of advancement possibilities.
Game testing is a great entry point to the industry as it exposes you to all aspects of development. It’s an important job and the gap between a bad or mediocre tester and a kick ass one is huge. Don’t be a mediocre tester. Be the kick ass tester.
Although I did not start my career doing testing – I started out as a programming intern – I do have professional testing experience and even as a lead programmer I often find myself testing code using the techniques that the best testers use (at the end of projects programmers have to test their code extensively before distributing updates to the team). When not testing new code or game features myself I constantly communicate with the testing group on whatever team I am working on.
The five skills listed below is what I believe to be the most important skills for a kick ass game tester to possess. With these skills in hand I guarantee you will be respected by the team for your ability to contribute in a significant way to the quality of your game.
Have a high level understanding about how game design rules affect what happens in games and how programming works. If you don’t have much experience in testing yet this may sound impossible but I do not believe it is. I am not talking about writing 3D engine code or designing 100% of the next big hit. I mean not being completely in the dark about how these people do their jobs and how their work is implemented in games.
To start, play some games that you own already. Don’t just have fun with them though. You’re a professional now – play them while carefully analyzing how the gameplay rules affect the fun factor and balance. Is it an online shooter? How is one character class’s machine gun balanced against another player’s grenade launcher? Is one patently better than the other? Is there a third weapon or player ability that further affects the situation? Apply this to other genres in an appropriate way. This will start to give you a sense of the thought process of designers.
Programming can be harder to get insight too but I recommend learning at leas a cursory amount. If you are in school, take at least one beginning programming class. If you are out of school already, try programming a simple mod for a game created on the Unreal Engine (e.g. Unreal Tournament 3) or on the Source Engine (e.g. Half-Life 2). Having just a high level understanding of how programming works and the kind of problems that programmers face goes a long way in being able to more deeply understand bugs. Sometimes this understanding will result in surprising insight for finding the root cause of a tricky bug.
Be able to connect the dots between seemingly unrelated events. Some bugs are straightforward – when you push the button in level two the game crashes instantly 100% of the time – yet others can be quite obtuse and hard to track down. This is all about not just reporting those obtuse bugs but also being able to analyze what was happening and accurately convey that information to the development team.
This is also related to an important part of bug reporting – providing clear reproduction steps. With your technical understanding of games (see last point) and your ability to carefully analyze the situation you are in an excellent position to help the people fixing the bugs do their job efficiently and thus have a direct effect on the overall quality of the game. If you can do this, developers – especially programmers – will love you.
Vague language has no place in bug reports. Nor does it help when giving gameplay or design feedback. This is a trait important for most jobs in the world but in the world of game testing it is especially important.
Know who you are talking to and how to talk to them. Don’t rely on stereotypes – not all programmers are analytical robots and not all artists or designers are touchy-feely koombiyah singing hippies. Interact with your team frequently and understand who the individuals are and how to best present information to them. You’ll find you are able to contribute to the game more in feedback and that reported bugs get fixed faster. Once again contributing to an overall improvement of the game.
Sometimes you might run into difficult personalities. Sometimes you’ll be on the receiving end of flaring tempers when you report a new bug in the latest beta build. Stay cool and learn to diffuse people. This is a tough skill to master but it is very valuable.
Don’t write a great bug report one day and then a crappy one the next. I’ve known some good testers who did a great job 70% of the time and a crap job the other 30%. The difference between them and the kick ass testers was simply a matter of consistency.
No one can be 100% awesome all of the time (except Chuck Norris) but do your best to follow up any good work with more good work.
Last, but certainly not least, is to continue playing games to keep up with the industry. This is important for everyone. It’s important for testers to get exposure to other titles to understand how other teams have solved game design problems. Using your analytical mind you may find something that helps solve or at least breathe new life into an issue on the game you are working on.
Believe it or not I have known some game testers who do not play games outside of their work. Whether they were jaded or simply uninterested in the industry I’m not sure. What I do know is that these people were unable to contribute at the highest level because of their lack of exposure to what was going on around them.
If you master the skills from the list above you will be helping your team a great deal. Testing has a huge impact on the overall quality of a game. Be the tester that brings out the game’s full potential. Don’t let down customers by contributing to a buggy or broken game getting released.
Bottom line… be kick ass!
And whatever you do, don’t be these guys: