FrankK

2nd Edition for life, baby. Alas, how would the troubled citizens of Shadyvale fare in the land of 4th edition will have to wait until we can give video games truly epic level budgets.

This is a good suggestion. I think I even read on here one of the top Obsidian guys saying that having a resume of mods would be a huge advantage over people that might even have more age or experience on you but don't have mods to their credit. <{POST_SNAPBACK}> Mods show a dedication and love of making games. That dedication and love of games is the only way to survive in this industry. If you are an artist, mods will definately help you understand how to make art for video games (like poly and texture budgets) If you are a designer, you will need to come up with creative solutions to implement your 'vision' sometimes. It also allows potential employers to see how well your vision survives from idea to implementation. If you are a programmer you'll need to integrate your code with an existing codebase and do so optimally (nobody wants a mod running at half the fps of the original game). There's also room to show creativity in your solutions here. Artists can also get hired based on a killer portfolio provided poly/texture budgets are withing expectations of what the company is looking for AND the quality is there. It's also extremely competative, at least as much as design.

Focus on C++, i haven't seen a C-based codebase that wasn't a legacy engine in a while. The only area where anything other than C++ would help is for tools. We use C# for our toolset needs on NWN2, for instance. That may change, but taking a snapshot of the industry at this point would yield 95% of the games being developed in C++. Assembly is always nice to know, but being an expert isn't that important. We've run tests against assembler and the latest compilers are pretty hard to beat. You can beat them, of course, but the savings is minimal and should only be used where needed. This means you won't be called upon to write much assembler these days. The exception used to be hardware shaders, but those have since gone the route of HLSL making it less important to remember the not-so distant days of shader assembly. I do believe that shader assembly is still important to analyze the output of HLSL compilers since they are relatively new and there is every possibility for not-what-you-intended assembly of the HLSL code.

The sticky about programming should answer most questions about what to do to give yourself a chance at becoming a game programmer.

WoW has a dead spot in the 40s that can be very difficult to overcome (lack of content options for characters level 45-50 is an issue). I suspect this is when many people re-roll or give up. The first 30 levels got a lot of love (heavily played in the beta) and go by fast enough that I don't mind playing them. Levels 50+ are a blast. The quests and challenges slowly increase and the zones you frequent are really good stuff. If you can make it to 50, I suggest finding a group of regulars to do the dungeons/quests and you will not regret it.

I played Fable with very low expectations, not being a huge fan of Black and White and other games from the developer. I only picked it up after seeing some gameplay at E3 and some gameplay movies on IGN. I figured I might enjoy it. I did. Is it short? Yeah. But plenty of replay. The story is hardly epic, but the mechanics of the gameplay are pretty solid. I'm interested in the PC version, but my list o' stuff to play is getting a bit long. If you never played the XBox version, I think the PC version may be worth a gander.

It has been my experience that the US has had a shortage of experienced software developers for quite some time. We receive about 10x as many applicants for entry-level positions as we do for experienced developer positions and many of those applying for experienced developers are marginally experienced.

There's a sticky that talks about schools, etc. Physics and math (calculus level at the least) with help. A lot.

I went to grad school as a teaching assistant and it was a highly rewarding experience that I think helped me later on in my career (the teaching part that is, the classes were pretty much more of the same--I imagine research assistantship is probably a more intellectually challenging avenue).

We generally don't discount rejected candidates because many times they weren't rejected because we didn't think they could do the job. It's not uncommon to have simply found someone who is a better fit for the position. So we don't discourage resubmission. We accept both recommendations and blind submissions. A candidate is usually evaluated by the leads of the project and the ownership of the company--so while a referral can help get the interview, it's not a shoe in for the job. Industry wide is a crapshoot. Honestly, many companies have their different philosophies on hiring. In general, I think most encourage you to resubmit provided you have an updated resume that reflects more experience or new skills or a new demo/mod.

These positions have been filled as of 7/7/04.

Replace UT2K4 with BF:V and you pretty much have Wendesday and Friday night at the Obsidian Ranch pegged--except Friday is pants optional.

The location is pretty imporant, so keep in mind that in California we do pay a lot more for real estate and in taxes (successfully Saves against rant). However, a lot of things are very convenient out here as well (access to mountains, ocean, culture, and 'other culture'). However, with the number of companies strewn along the highway from Calabasas to San Diego, your odds of remaining employed are better than say, Madison WI, where your choice is Raven or nothing. You will generally make slightly more (10% or so) living in a higher cost of living region. As far as 60 hour weeks go, some companies require it. Some positions require it. I've worked for companies that encourage 40 hour weeks, except in the event a milestone is in danger--or the 'crunch' is on. You will never avoid the 100 hour weeks near the end--every project insists THIS WILL BE THE ONE to avoid the crunch,but even with the most careful planning, the team's passion for wanting to make the best game possible will be stronger than their desire to catch their favorite TV shows (thank you TiVO). Summary: You will make less money and work more hours. No way to sugar coat that. Otherwise, it's a lot like working outside the industy. Except you work with geeks. Making games. No suits. With the occasional span of months where you forget where you live or who you live with because the office IS your life and home. It really comes down to work satisfaction--I don't regret taking a HUGE salary cut to get into the industry (about 4.5 years later, I'm still below what I was making, but not too far below) . What's money when your miserable for 8 hours a day?

Generally, salaries are slightly lower than 'out-of-industry' salaries. A programmer that has a good resume and several years in the industry won't be starving, that's for sure. Out-of-industry experience and salary history won't really earn you much when applying, hence you can be making 60k writing accounting apps for a consulting firm, but you will likely need to take much less to 'break in'. It's a reality that we make less, though, and most people don't do this for the money. It's not bad cash, but you can make more doing something else.

Well, there's two types of agreements. Valve is self-funded, I am pretty sure. So they will finish when they finish and collect money from Half-Life 2 sales almost instantly. Most developers work based on milestones and payment for milestones. The time between the start of a project and the ship of a project is divided into chunks (usually monthly). The developer agrees to deliver the game to the publisher with x amount of content and features implemented for each milestone and the publisher pays them some money. The royalties on a publisher-funded title generally pay out at higher sales numbers, but your project is funded by the publisher, so as long as the publisher can pay you and you meet your milestones, you don't go hungry. Less risk for the developer, more risk for the publisher.