Slashdot Mirror
Is Bughunting Still A Way Into the Games Industry?
Edge Online is reprinting an article from last month's issue of the British gaming magazine. In the article, Bug Hunt, they look at the role of the modern QA tester. While once a good way to make yourself known to the company's HR staff, it's more and more simply a summer gig between classes for college students. They also discuss the hard working conditions, soul-crushing scheduling, and the public misconception that what a QA tester does involves the word 'play'. From the article: "Anyone with any experience of the QA process will deny the slightest resemblance between testing a game and playing one for pleasure: finding bugs is unmistakably work, and, by common consensus, very dull and repetitive work at that. On top of this, pay is often poor, job security frail, working conditions extreme and recognition hard to come by. So why do it?"
I'm currently a programmer in the industry (Activision studio). I spent nearly a year doing QA work, making sure to get the right connections by talking to the designers and programmers for the projects I was working on. I helped shape the game, gave constructive feedback, and hunted down bugs like no other. It got noticed, the development team passed my name along, and here I am, sitting in my dream job.
This was a timeframe of under two years... so at the very least, it can certainly still be done.
Just a few days ago Mythic announced a couple of job openings in customer support on the Dark Age of Camelot news site. They say the jobs are open now because they promoted two people in the CS department to development.
If people can go straight from customer support to development then I can't imagine they would have any qualms with moving QA people into development.
My only political goal is to see to it that no political party achieves its goals.
Agreed! Except, you don't even have to work on a big name mod. If you can go to game companies and show that you know how to mod the engine that they use, that's going to get you farther than you'd guess. When applying to companies that use proprietary engines, showing that you can mod one of the big engines (Doom 3, Unreal 3, or HL2) is great.
You don't need to be John Carmack to work in the game industry, you just need to be bright and write solid code. Having something that's polished is more important than having something that's really popular - at least for the purpose of getting your foot in the door at a game company.
Showing a high quality mod is usually more impressive to companies than having a low quality home-brewed engine.
Shameless plug: Infinity Ward is hiring! http://www.infinityward.com/jobs.htm
the original poster listed 3 examples, but if you hadn't noticed, there are thousands and thousands of mods that have been either made or are being made.
as the owner of game company, i would hire a modder that has actually 'created' content or worked on a game engine over a qa tester that 'thinks' they know how to make games any day of the week.
big difference:
- modders typically have an actual marketable skill - whether it be 3d modeling / mapping / programming / scripting whereas qa testers don't for the most part.
Gekido's Lair
I've been in the game industry as a Game Tester for nearly 4 years and I've seen a vast amount of people get into the industry without needing to go through Quality Assurance. Designers have been hired because they had good story writing and communication skills, level designers have come in because their own home made levels did well within the gaming community (Eg, Unreal Level editing). Artists and Programmers coming in because they make optimized and well thought out models.
If someone really wants to get into the game industry, all they need to do is be good at something, rather than being someone who is soso in all aspects of making a game. I'm not saying they need to be a prodigy, but simply having a basic know how on how to create what they are doing and understanding how it was done fully, instead of slapping it togther haphazardly and making it look pretty. Eg, there is a huge amount of people that make StarTrek 3D models out there. Most of which are quiet nice to look at, but when you look at it from a technical stand point, they over used polygons where it isn't needed, and/or they are unable to make the model again without a lot of trial and error. You need to be able to make a 3D model with the most amount of detail with the least amount of polygons. If you can do that, you've learnt a lot of useful tricks that most 3D "artists" will never learn.
The best advice I can give to anyone, is _JOIN_ a mod project as a programmer or artist or level editor, and get your fingers into as many pies within that project as possible. Communicate well with the rest of the team, and hopefully the project will get out the door and you can add it to your resume, which will look very good, much better that people coming out of these new game courses from University...
Also, join multiple mod projects, because not all of them will succeed, many will go down in flames due to the rest of the team not pulling their weight. But take note, _JOIN_ a mod project, don't try and start your own with no prior experience, it will be a waste of time, and really doesn't look that great on a resume.
Programmers, take a look at the "Demoscene". If you really want to make great games, then you need to know a lot of the little tricks for optimizing code, the demoscene will help you with that. www.scene.org is a good place to start, have a look at what other people have created. I know a lot of the veteran programmers respect people that come from the demoscene, more than codemonkeys coming from University. Demoscene programmers tend to be very adaptable, and will normally get to work on the more interesting stuff when on projects.
Level designers, pick a game and make levels for it. Eg, Unreal, FarCry, Quake, etc. But make levels and get them out to the community. Its fun to waste 4 months making sure every tree in your level is in exactly the right place but it doesn't serve any use in the game industry, that's what artists will be asked to do. Your job as level designer is to make fun, functional levels that work well within an engine. What you should teach yourself how to optimize your level, such as object culling, VIS, PVS, level layout etc. Also study what makes other game levels fun. You need to know exactly what makes a level good, you should be able to answer this question when asked. Your opinion is not a valid answer, you need evidence to back it up. Once you have mastered one level editing tool, start dabbling in others. You may not like it at first, but it will come in handy down the line should you ever get hired and you have to work on in-house tools to make levels.
Artists, try all sorts of different styles of modeling, don't just make spaceships or manga characters. Show that you are versatile. Show that you can make 3D models with few polygons as possible and they look awesome. Make a few character models and import them into a game, such as a Quake3 character, or a monster for a mod project. It may be even a better idea to find someone who has drawn a charac
Robin Walker, Design Manager at Valve, co-wrote the original Teamfortress. I think there are a lot of people at Valve who come from a modding background. Iikka Keranen (or Kernen as he's listed on Valve's site, for one reason or another) used to make maps, textures and small mods for Quake and Quake II, and even wrote a lighting program for Quake. He's now a level designer at Valve.
Modding will most likely remain a good way of getting into the industry. I would imagine that some members of the Black Mesa team will get job offers once they release it, if not earlier.
I'm not going to deny that QA is difficult. I started at Access Software and stuck with QA through almost five years at Microsoft Game Studios before saying "fsck it" because of the stress and leaving games for a bit to try my hand at coding.
During my time as a programmer, I learned two things. First, even just spending time testing games helped me learn enough about coding in a performance-critical environment that I was able to carry many of those lessons over into "the real world;" and second, as much as I enjoyed making things, I enjoyed breaking them even more.
So I've returned to QA. Sure, QA is often the scapegoat in case anything goes wrong; QA often has to work shifts that would make sweatshop workers quit; QA rarely receives the recognition due or the compensation necessary...but QA is also one of the most rewarding careers in terms of variety and challenge. Every day, I receive a build and wonder what's wrong with it this time and how can I break it.
When I report something to a developer and see them seethe for an hour on end trying to figure out how they're going to fix it...it makes my heart smile. Those are the moments I live for.
That's why I test.
RomSteady - I came, I saw, I tested. GamerTag: RomSteady / http://www.romsteady.net
The problem is that most QA guys are more interested in hitting their daily/weekly quotas instead of spending the time it takes to root out serious issues that need to be fixed. For example - I'm an artist, and I'm pretty sure I'm able to notice when something is misaligned or off by a few pixels - to me, QA would be a hell of a lot more useful if they would track down a bug on a screen that crashes 1 out of every 4 times as opposed to sending me 35 bugs that are the *exact same issue* but spread across several screens.
Several years ago, just before I left my 'proper job' to work in the games industry I was involved in a pretty disastrous software project. The project and companies involved shall remain nameless, but basics of the story will be familiar to alot of people.
We had a small in-house team (9-10 coders) and the business decided to embark on a project which was way outside of the teams' capacity. After several weeks of protesting that the project was too big for us to deliver in anywhere near the drop dead dates we were given management finally relented and brought in a development consultancy to supplement our small internal team. This consultancy (who will also remain nameless) brought with them a small army of mostly incompetent coders and a giant army of business analysts, architects, project managers and other varieties of monkey trained in various levels of sales and management speak. Needless to say the consultancy left the internal team todo most of the coding work and spent alot of time making presentations, sending long e-mails, creating complex charts of various kinds and then left the delayed, feature barren, burning carcass of of the project behind and pocketed alot of cash.
The one thing that the consultancy brought with them that actually helped was a team of sub-contracted QA staff who were located off-site at the consultancy's office, some miles away. I was even younger and stupider then than I am now and at first I complained bitterly about the 2 page bug reports that I began to receive from them on a regular basis. These reports would contain a massive amount of detail for even the most trivial bug, complete (often 100%) repro cases for bugs which were incredibly complex and (IMO at the time) were never going to be found by normal users. The reports often also contained references to specific areas of the functional specs that we had written at the start of each project which our implementation was not entirely adhering to.
Now that I am less young, less stupid and work in the game industry I pine regularly (as my colleagues will no doubt confirm) for those QA people whose bug reports were so clear, complete, accurate and detailed. The bug reports I receive now from game team testers are like drawings on the wall of a cave when compared to the reports described above. They are short, unclear, often completely inaccurate and sometimes the text is not even recognizable as English.
The reason for this massive discrepancy in report quality is glaringly obvious. When I worked at the consultants office for a little while (just prior to leaving that job) I actually sat next to the QA team. The difference between that QA team and all the QA teams I've worked with in games was like night and day. In a word, they were professionals. Most of them were graduates with 5-10 years of work experience, they were obviously well paid (some of them better paid than me I think) and their personal appearance and hygiene put most of the coders to shame. They had analyzed our entire functional spec, without any interaction with the development team and created a complete test plan which they synced up to our development schedule. They had identified a number of complex testing tools which were appropriate for our product, acquired them and were actively using them to find bugs the we could hardly even imagine. They were often able to isolate the causes of problem, when the cause and effect were in totally unrelated parts of the product (functionally speaking).
That's not to say that the game QA teams I've worked with have been all bad, but they're a totally different class of tester than the guys at the consultancy. I suppose that the title of this post is alittle misleading, as I have also worked with the class of tester found in the games industry in other industries, but they are less common and generally in smaller numbers.
Anyway, before I get modded off topic the real point of this post is that I would like to see the kind of testing described above happen more in the industry