Hello, I am interested in looking for a job as a developer. Everyone I have talked to says that I need to make a game first. That''s fine, in fact, it sounds great! But, I''d like to know the quality expected of the game. I mean, I have a tetris game, but I doubt that it would qulify as a good demo of my skills. Also, for anyone out there who has done something like this, how long did it take you to make your demo and what was it? Thanks!

Make it feel complete (scoring, game over, fully implemented game rules, etc.)

Demonstrate as many concepts as you can in the demo in a well composed way.

My only real demo was a space shootemup that took around 3 months to complete. I had adapted it to work with both OpenGL and Glide (3Dfx was popular back then in '98). It had scoring, texture mapping, lighting, a minor HUD, minor AI, sound effects, lens flare (from a nearby sun), explosions, strike flashes, and collision detection between craft. All the graphic effects were very minor, but made the point. It was single player only.

My only real complaint was that the AI was too maneuverable and the AI flight patterns weren't gamey enough. It was too hard to get an enemy lined up to fire at it because they were so determined to get behind you. The best way to win was to command your squad to attack a single target and just watch their backs, conducting them to attack a different target if they get in a dangerous position.

Here's the OpenGL version - might work, might not.

Got me an interview (at Totally Games, the makers of TIE Fighter WOOT!), but not the job. And that's ok.


[edited by - Waverider on June 25, 2003 5:09:14 PM]

Thanks for the advice. I checked out that game of yours. It was pretty cool. How many other games had you made before that one? Also, you said three months of programming. How intensive was it? I mean did you have another job at the time? Anyone else want to post a reply?

Thanks. I was on a hiatus from my other job to try to get into game programming, and actually, this demo had a previous incarnation that took around 3 more months to get going. That demo also got me an interview, at the makers of Descent. However, looking back on that very first demo, I couldn't believe it got me an interview.

It might have helped that I sent my resume overnight registered. That gets their attention.

As far as other games that I've done, I re-programmed Gauntlet on an old machine a long time ago because I was so disappointed with what I ordered in the mail. THAT was a good exercise ('90). I also programmed Risk. Very cheaply, but it worked. I had to plan out the layout of the countries on graph paper (I actually traced the board onto small-square graph paper. Boy, that was a long time ago - '86 I think).

In college, I think I spent more time figuring out how 3D programming would work than anything. And when I finally got my hands on a computer on '93, and a compiler with OpenGL in '96, all my plans came out at once.

I also goofed around with the Doom wad files and wrote a BSP splitter.

[edited by - Waverider on June 27, 2003 5:01:41 PM]

quote: Original post by Waverider
It might have helped that I sent my resume overnight registered. That gets their attention.

Is this recommended to do. I to am gathering all the tips i can on getting a game programming job.

Anything you can do to get noticed.

It worked for me back in '98. I don't know of any of the recent trendy things to do today, but in my opinion, the bother of sending a resume registered overnight still shows a deeper interest than a resume that looks like it was just sent to many places in the random hope of getting a reply.

Also, include a cover letter showing your knowledge of the company and an initial take on why you think you would be a good fit for the company (whether by your contributions or what you are hoping to learn and what direction you are hoping to go with it that serves the company, etc.)

[edited by - Waverider on June 27, 2003 1:57:36 PM]

1) Don''t crash.
2) Clearly document what works, what to do to try the game out, and what your requirements are (CPU, specific graphics etc).
3) Don''t crash.
4) Include the source. No, they won''t steal your source. If it''s any good, they''ll hire you. If it''s not any good, they won''t hire you, and then why would they take your no-good source?
5) Don''t crash.

-------------------
4) Include the source. No, they won't steal your source. If it's any good, they'll hire you. If it's not any good, they won't hire you, and then why would they take your no-good source?
-------------------

really? I didn't think I should. not cuz they will steal it but just..umm I dunno. So it's standard practice to submit source? (even if it's izzo huge 130++ files??) I figured if it works and they can play the game/demo it's fine without source.

please let me know.
thanks



[edited by - quack on June 27, 2003 4:49:19 PM]

There might be some merit in including it, if only to let them see how you arrange your structures and give them an idea about how you design your code.

You could at least include it with your demo. They might look at it, they might not. And if they are curious, it will be there for them to look through.

Still, I imagine existing teams speak together about how their code is arranged. It would be hard to glean from source code how well the author could work on a team and adapt to new methods. If the source code is particularly bad, though, that might be an indicator.

> There might be some merit in including it

More than just style. I remember looking at a new recruit's source to see if he was the true author of the source (if cut & pasted, then a note about its origin and how it works), showed that he fully understood it, and that the overall code was organized into separately debuggable modules. Document a lot; not every sentence, but each function should have a small box explaining what it does and each file should have a header with a succinct description of its uses in the application, its limitations and assumptions, and yes, the known bugs / ugly hacks (if any).

It is then used as a basis for the interview: why did you chose FMODC instead of DirectSound? You used a callback mechanism based here, but not there, why? How would you make this part faster?

Remember that job hunting is an _exclusion_ process; HR people are 'cleaning' the pile for the R&D to prune even more, and for the actual team members to analyze. A good resume, letter and portfolio gets you through HR, the demo gets you through R&D and the code & technical interview gets you through your destined team. That's why knowing people at the team level gives you a head start; network; network; network.

-cb

Edit: fixed missing chars (bad keyboard).


[edited by - cbenoi1 on June 27, 2003 8:40:31 PM]