EQII is looking for more Coders!

Hey guys! Good news! We are going to be hiring more programmers for EQII. We have already made a hire from the community and having people that are passionate about our game working on it is good for everyone!

Below you will find links to the job posting on SOE's webpage. If you have any questions feel free to PM me. Even if you have not programmed C++ in some time but have a programming background and are passionate about EQII you should apply!

Also please include a cover letter that clearly states that you play this game and a little bit about your play style.

Here are the links for the EQII positions:

Client/Graphics Programmer:
https://rn12.ultipro.com/SON1002/jobboard/JobDetails.aspx?__ID=193

Senior Generalist Engineer:
https://rn12.ultipro.com/SON1002/jobboard/JobDetails.aspx?__ID=194

Generalist Engineer:
https://rn12.ultipro.com/SON1002/jobboard/JobDetails.aspx?__ID=195

Sounds tempting but I'm not in the US.

By the way nice to see that part of the job of the graphics programmer would be optimisation.

Darn if I was a programmer but sadly I am a 3D generalist not a code-monkey. Looks like I am going to keep on my Player Studio work. Best of luck with your programmers.

I am a programmer. Unfortunately, all of my programming experience is academic (as in gained through attendance at a university, not as in irrelevant - although I guess, in this case, that meaning could apply as well ), not professional.

Glad to see you are hiring - but I think the 8000 mile commute could be tricky

One of the reasons they look for experience is roughly the difference between a physicist/chemist, a mechanical engineer specializing in engine design, and a mechanic:

• The physicist/chemist can work out the formulas and models describing the most efficient airflow for a turbocharger system.
• The engineer can work out the absolute best design for the piping and manifolds to give you the best turbocharger system around that'll fit in the engine compartment available.
• The mechanic can tell you you don't want to do it that way, because the way the piping and everything will have to be laid out you're going to have to dismantle the entire air-intake system and pull the intake manifolds just to get enough access to change the oil filter every 3 months.

I didn't say they were wrong for doing so, nor did I imply that I did not understand their reasons for doing so. I just was identifying that as the disqualifying factor for me (and also saying that kinda sucks for me).

If you've got some common sense and some experience designing for more than the immediate problem, I'd still go for the generalist engineer position. You might end up being the best of the lot. I've boggled at just how little actual ability I've seen from interview candidates claiming 8+ years experience.

This. When working on some hobbies and recruiting programmers, you'd be surprised at how much people think they know versus how much they actually know. It's one thing to have 8+ years experience, but if you learned nothing in those 8 years, your knowledge may be outdated.

For example, take the advent of C++11. A hobby I was working on had heavy in-house library usage. C++11 came out (as C++0x), and that in-house library could be replaced with STL, which has had major improvements to speed since its inception in 2003, in later Microsoft compilers (which they were using).

Because they were taught to make in-house libraries in most of their programming classes in 2003-2005, they assumed it was the best way to go all the time, and when some new programming concept was introduced (such as STL or boost, though STL does pretty much everything boost does now), they stuck to their guns instead of learning as they go. The programmers I have seen also are also foreign to performance issues in general when working with people who claimed experience or education (though I have normally seen better, more complete results from educated people whereas those that work on solely experience cut corners).

A generalist engineer, from the description, sounds like a client/server performance, optimization, and bugfixing job to me as well as flexible enough to code new systems into the game client and server. In the case of EQ2, this would mean making the code that fits the requirements of the designers' vision and finishing it with optimal precision.

If that sounds right up your alley, apply!

holy crom I would so love to fulfill my lifetime dream of coding on a video game. But 25 years experience in business coding wouldn't be a great resume for hardcore C/C++



I unfortunately went the VB.NET route. Although I have debugged C++.

I hope you get some good folks.

I smell a 64 bit client coming...

I have no professional experience, and little academic experience. I am assuming I will probably be turned down.

In EQNext? Ok, maybe. Maybe likely.

The most likely case though, in my opinion, is that multi-core experience is important from the server side of things...

With the tools available today, do you even need to think that much about multi-core or do the toolkits do the heavy lifting for you?

Also yes people joke about EQ2 being a single-core client with no awareness of a second core. This is not for lack of trying. Wherever possible, tasks have been moved to the second core, but it's extremely difficult to do on such an old codebase.

Generally that is true, but you still have to 'write thread safe' objects etc. Also generally speaking the easiest quickest way to write C/C++ is not thread safe. Certain functions etc. The compiler handles most of the 'heavy lifting'.

Actually the reason I believe a 64bit client is for multiple reasons...

First off, they have stated recently that they are starting to reach the limits of what the current client is capable of doing without running into memory issues (and not using newer features such as compute shaders to alleviate the problem).

Secondly, World of Warcraft and other newer MMOs are starting to use 64bit clients.

Third, the installed base of x64 is much larger and only growing larger. Much like what happened to EQ1 and the Voodoo cards, eventually the client has to be modified and move on from old systems that are dying off from the userbase. This guarantees the long term continuance of the game as Smedley stated he wants to occur.

The tools will do some of the boilerplate for you, but the hard part is the thinking and the attitude that goes into designing things to work with many threads manipulating the same objects at the same time. You can get an idea from http://www.cs.cornell.edu/Courses/cs3110/2012fa/recitations/rec16.html of how it can get complicated. NB: this example's why condition variables are usually done in a system library. Most developers would stop at the third or maybe get as far as the fourth implementation, leaving either nasty bugs that don't show up in development or QA and wind up causing zone crashes in production (google for "heisenbug") or code that has 24 threads (one for each person in a raid) all trying to hog 100% of the server's CPU at the same time and causing the encounter to lag out.

yesssssss...soon enough all the narcs, nocs, & moles shall be in place & the takeover shall be complete... >|

If the studios were in Austin I would probably apply, but I think moving to CA makes it a clear pass for me. But I do wish good luck to those that do apply.