• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
  • entries
  • comments
  • views

About this blog

Programmer gone Recruiter Sharing Advice

Entries in this blog

Marc Mencher
Unless you're making a text-only game, you'll need to apply some form of Newtonian physics to pretty much every action that occurs on the screen. Computer and video games apply the laws of physics so that objects "behave" as they do in the normal world. This means that programmers need to know the physical science equations to apply them accurately and appropriately to the game code. (Even objects in an "alternate" or cartoon universe have to follow the rules of physics to be believable.)

The online book description for Physics for Game Development states, "Colliding billiard balls. Missile trajectories. Cornering dynamics in speeding cars... By applying the laws of physics, you can realistically model nearly everything in games that bounces around, flies, rolls, slides, or isn't sitting still, to create compelling, believable content for computer games, simulations, and animation."

Game elements that require application of physics include things we take for granted in the real world, like elasticity, light, sound, reactions and interactions, and especially gravity.

  • Gravity - This basic principle is at the core of motion in our world; all falling objects respond to the force of gravity according to the laws of physics. Falling objects accelerate according to certain equations but all objects fall at the same rate, unless they are affected by air resistance. Likewise, if a game character jumps in the air, that character must come back down to earth according to the rules of gravity. (Even the girl in Leisure Suit Larry fell back down at some point . . . )
  • Motion - A game in which things don't move is going to be pretty boring. Even old school side scrollers have at least some type of motion on the screen, even if it's rolling terrain and limited pixel animations. The more you understand physics and programming, the more efficiently and you'll be able to add realism to your game--which means the more you can do with limited funds.
  • Elasticity - Things bounce, stretch and snap back to their original form depending on how they react to the force effecting change are--in other words, depending on how "elastic" they are. This principle can be applied to create realism in an MMO, humor in a cartoon-based world and action in a super-hero type of game.
  • Light - There are laws about how a beam of light will reflect off an object or how it will bend or refract when going through something transparent. Not only will application of these rules affect the overall realism in your game, they will also affect the game's visual appearance. Myst explored the use of these principles to great effect. Modern MMOs like Guild Wars 2 and action games like Call of Duty set a very high standard for the dramatic use of physics in this area.
  • Sound - Sound characteristics like echoes or the Doppler effect (the effect of relative motion on sound waves) are applications of physical laws on sound. While we know that there's no sound in space, we accept the convention of explosions, collisions and engines in our entertainment media. Lack of sound would not only hamper the storytelling (and the drama) but it would mean that a lot of talented sound engineers don't have anything to do!

    [1] Pertaining to the laws developed by Sir Isaac Newton (1642-1727)
    2 http://www.amazon.com/dp/0596000065/?tag=stackoverfl08-20

    • Collision detection - Used to determine how two solid objects interact in the envrionment. This could be as simple as whether your avatar walks through a fence or over it, whether you go around an NPC or through her, and whether you can shoot through rocks or not (applied as "line of sight.")
    • Particle systems - A common aspect of computer games are explosions. Early computer games used the simple expediency of repeating the same explosion in each circumstance. However, in the real world, explosions vary depending on the terrain, altitude of the explosion and the type of solid bodies that come in contact with the explosion. A particle system model allows a variety of other physical phenomena to be simulated, including smoke, moving water, precipitation, and so forth. An environment's realism is limited by processor power, the knowledge of the programmers and of course, time and money available to make it fancy.
    • Ragdoll physics - A procedural animation and simulation technique that displays the movement of a character when it drops to the ground, usually when it's killed. The character's body is a series of rigid bones connected with hinges at the joints; simulations model what happens to the body as it collapses to the ground. More sophisticated physics models of creature movement and collision interactions require greater level of computing power and a more accurate simulation of physical principles and elements. Programmers need to understand how physical principles in the environment affect anatomy--and they also need to be able to communicate really well with artists!
    • Cartoon physics - We're all familiar with hapless characters who fun off a cliff and continue to move horizontally until they realize that oh no! there's not more ground and down they go. Sonic the Hedgehog moves at superspeed, characters survive being crushed by a heavy safe and just about any object can endure the classic "squash and stretch" process. These physical anomalies are intended to provide humor and create improbable situations for superheroes. While we don't necessarily want to see them in Call of Duty, we would feel cheated if they didn't show up in a cartoon or superhero-based game.

      The bottom line is that while you might be able achieve these important (and expected) game elements without a knowledge of physics, the quality and believability of your product would probably not support a high level of art, action and story without them. Without the appropriate application of physics in a computer or video game, you might as well be attacking creeping coins or going through a maze of twisty little passages. As Alice said, "What is the use of a book without pictures . . .?"
      [sup]3[/sup] Carroll, Lewis. Alice's Adventures in Wonderland
Marc Mencher
Hiring Managers: Vetting Game Programmers
[size=2]By: Marc Mencher - Game Programmer gone GameRecruiter rolleyes.gif

So you're in that blue sky brain-storming session and there are a ton of awesome ideas up on the board, and then someone says, "This
is GREAT! Now we need someone who can make it work like that." Yep, you need a programmer. And not just any programmer. You need someone who can push the envelope, work with all the teams and fit into and grow with your company's culture. That's the moment your Quest begins . . .

There's a lot of "ebb 'n flow" these days and a lot of open jobs. A lot of people are getting hands-on experience, thanks to the ease of making small social games. Their work is easier to see but harder to vet. There are programmers at big companies whose projects are either ending or whose companies are downsizing (or closing), but there may be relocation issues that have to be considered in addition to salaries.

To increase the odds of making the best hire for your company, you want to develop a basic "vetting" system that looks at traditional and non-traditional aspects of your potential new programmer.

[color=rgb(0,0,255)]Step 1: The Job Description[/color]

Before you write the job description, be sure you have a good understanding of what various job titles mean. Terms like developer, programmer and engineer aren't always interchangeable. A QA person might be called an engineer at one company, while developer might refer to someone other than a programmer. Some programmers prefer engineer because it sounds less like a drudge position. If need be, include a sentence or two that describes what the title means at your company.

Figure out what you want your new hire to do, then write a job description that clearly states you're required and preferred criteria. Aim for something between "as long as you're breathing" and "must have a Masters Degree in everything." (Hint: It's pretty easy to spot a job req that's been customized for someone you've already decided to hire.)

Here are some things to look for:

  • Deep interest in gaming, both as a programmer AND a player. This used to be designated as "avid gamer" but what does "avid gamer" mean any more? Of course candidates are going to tell you they're avid gamers!
  • Wide variety of gaming genres (ok, at least two!) If you make MMOs or FPS games only, specify that you want someone whose
    interest and passion is in your genre.
  • Want someone with corporate-culture experience? These days, that's different from "must have shipped an AAA game" because small companies can ship AAA titles too.

    Let candidates know if some kind of testing will be administered. If you have questions about the legality of testing, check with your HR department, and if they don't know, get the info from someone who does, like your state's employment agency. Surprising an interviewee with an on-the-spot test (the formal kind) can be grounds for action, and not the good kind.

    Be clear about your interview agenda. Will candidates be asked to undergo both "personal" and "technical" interviews?

    Do you want to see a demo of the candidate's work? Do you want to see it online by yourself? Ask for a CD or URL. Because of proprietary software and NDAs, be willing to look at open source work and/or game modding.

    Does your formal application allow for an attached resume, or will the candidate be required to fill it out? Will the candidate be asked to provide a salary history? Letting interviewees know this in advance saves you time and helps reduce the normal anxiety that comes with interviewing. (It
    also tells you if the candidate can read and follow directions.)

    [color=rgb(0,0,255)]Step 2: The Resume[/color]

    Read the resume before the interview. This may sound sort of "duh" but looking at the resume in front of the candidate sends a message (intentional or otherwise) that this interview is either inconvenient or a pro forma exercise so the company can hire the person it REALLY wants. Reading the resume in advance gives you a chance to come up with specific questions.

    Check out the companies listed on the resume. How long has the candidate worked at the past few companies? Are any of them start-ups? Do you really want someone who has moved quickly up the ranks and name-drops like crazy but has no real experience?

    [color=rgb(0,0,255)]Step 3a: The Interview[/color]

    If someone in HR is doing the initial interview (other than having the candidate fill out paperwork,) be sure you've reviewed the job reqs with that staff member, and provided some initial questions you'd like them to ask the candidate. Letting someone with no technical background and/or real
    industry knowledge conduct the initial interview might let a fast-talking candidate in the door and a good one get away.

    Everyone who's participating in the interview should be prepared (i.e., has a copy of the resume and has seen the website or CD). If you're including "peer" interviews for the candidate, be sure your staff knows that their job is NOT to scare the candidate way.

    You know the drill: be prepared, be prompt (and if you might get called away to an emergency, let the candidate know before you start the
    interview), don't take calls (unless there's a pending emergency). Be focused and ready to listen. As a courtesy, if you're deathly ill, stay home and let a colleague conduct the interview, or make arrangements to do it via Skype or some kind of video conferencing.

    Having a member of the team with whom the potential hire will be working, preferably the team lead, as part of the interview process is always a good move. While there are many skilled programmers who can fill your job, getting one whose personality meshes well with your other programmers is
    always a bonus and in some cases, a must.) Remember that these people will be working very closely with each other, often in frustrating circumstances (the dreaded crunch time, for instance), and an argumentative or disruptive team member can cause a hit to productivity. Personality and work ethic is just as important as skill set, especially when you've got a small team, a tight schedule and no money to spare.

    [color=rgb(0,0,255)]Step 3b: Interview Testing[/color]

    Assuming you're cleared for testing, use simple programming or logic tests. Asking very specific questions, like hex and terminology definitions, isn't the most effective way to evaluate a programmer's ability to code because rote answers don't tell you how the candidate programmer THINKS.
    Recent grads will probably be able to answer "arcane" questions because the info is fresh in their heads but is that what you really need? Good
    programmers like to solve puzzles, riddles and mysteries rather than apply canned solutions. The right candidate will have some basic problem-solving skills in addition to specific programming knowledge.

    Propose a simple programming issue and ask the candidate how s/he would handle it. Maybe a brain teaser or a suggestion for a modification to
    your product, which has the added benefit of showing you how well the candidate prepared for the interview. A good type of coding question is one that has several answers; ask your prospective hire to give you the most optimized solution. You can quickly gauge how well he/she thinks and solves problems based on the answer. Someone who consistently picks the most obvious but less optimized answers is good for entry level positions, but if you're hiring for senior positions, you'll want people who can think on their feet, understand the need for optimization and have good reasoning behind
    their choices.

    Here's an example of a good question:
    Every number between 1 and 100 has been inserted into an array of 99 integers in random order, with a random number missing. What's the most optimized and memory-efficient way of figuring out which number is missing?

A weak answer would be to create 100 flags, then loop through the array and log each number, and subsequently loop through the flags to find the missing one. A stronger answer would be to loop through the array and add them all up into a single integer, then subtract the answer from 5050
(the sum of all the numbers between 1 and 100). An even stronger answer would be to sort the array, then loop through until a number gets skipped.

If you want to ask technical questions, avoid asking hypotheticals like what types of inheritance or global variables appear in a CPP file or polymorphisms or singletons in C++. Instead, present actual situations that are relevant to your product or project (unless, of course, any of those other examples ARE relevant. Bear in mind that the simplest code is, more often than not, the best code. A programmer who loves to pepper the code with unnecessary methods like 'mutable's and 'goto's might not be the best candidate. Likewise, don't ask questions that are overly complicated for your code base. Unless you regularly need inline assembly code, don't ask the hire to describe how to unwrap loops or other overly complicated questions. While it's a great indication of general knowledge, it won't tell you if they'll do a good job.

In some circumstances, you may be looking for someone who can not only move forward with a project's code but also knows how to deal with
legacy issues in a manner that doesn't involve stopping the entire project and starting over from scratch. It's great when the candidate sees this situation as an interesting challenge but you want to avoid the candidate who claims to be able "fix anything."

[color=rgb(0,0,255)]Step 3c: Interview Questions[/color]

Ask the RIGHT questions. Hopefully, the combination of a well-crafted job description and vetted resume has weeded out candidates who aren't right
for the job.

Does the candidate use/play your product regularly? If you make MMOs, you'll be able to determine the level of immersion and investment pretty quickly. If the candidate gets that glazed look and launches into a Very Detailed Account of her avatar and the last raid, that tells you something,

"Beware the lone programmer in a room" is an old industry adage that still rings true. You want someone who will fit into your company's culture and actually likes working with other people. Does the candidate seem like someone who will thrive in a high stress team environment (if that's what you've got) or does the candidate seem like someone who's more interested in showing others "how it's done."

Consider asking some off-the-wall questions like, Do you prefer cats or dogs? Cake or pie? Summer or winter? And why? An industry veteran
interviewing a programmer candidate said, "Tell me a joke." The stunned candidate replied, "Oh. Do you want a funny one? I didn't really prepare anything." That told the interviewer what he needed to know about the candidate's ability to think on his feet.

Ask about a "hot" programming topic that's making the rounds on industry boards and at conventions. Is the candidate passionate about one side or the other? Dismissive? Baffled? (Hopefully the candidate will not say, "Well, does that really have anything to do with this job?") Having a sense of humor is actually pretty important in our industry because it reduces the possibility of melt-down at the worse possible moment.

Ask candidates what they love about programming. (Hint: "An easy way to earn a living" probably isn't what you want to hear. "I love to solve problems" or "I like to make great games" is better.)

What's the biggest thing the candidate worked on that didn't ship? Do they have any idea why it didn't ship? Watch out for indications that the candidate thinks failure was other people's fault. One of the tenets of Agile Development is that failure by one unit is failure by all, so you don't
want to hire someone who's more adept at finger-pointing that accepting responsibility and proposing positive solutions.

Has the candidate worked in an Agile Development environment and if so, how was it? If it seems that the candidate felt it was intrusive, see if you can determine whether the system was poorly administered or the candidate just doesn't like to be interrupted or told what to do.

What was the biggest challenge the candidate has faced as a programmer so far, and how did s/he solve it? (For female programmers, gender bias may be the biggest issue so be sure you stay within the boundaries of what can and can't be asked legally.)

Ask question(s) that give you a sense of how flexible the candidate is, how willing to try new approaches, take suggestions and explain solutions. Odds are you probably won't be happy with some hot shot who thinks that everyone else is too simple-minded to understand what he does. (In fact,
sometimes this is a red flag that the programmer might not be so good at building strong foundations or accepting responsibility when fixes don't hold

If you decide to review the candidate's demo in person, ask what specific portions s/he handled. Obviously, with a small app, it's probably "all the programming" but if it's a big game, the programmer was probably part of a team. Ask about how collaborations worked and whether the
programmer's suggestions for game play improvements were considered. Avoid the programmer who says, "Oh, I write the stuff but I don't play the

Here are some questions on the "lighter" side:

What do you like about gaming?

  • What was the first computer or console game you played?
  • What was your first computer?
  • What's your favorite game and why?
  • What's your favorite book? Movie? TV show?
  • Do you prefer open worlds or well-defined quest lines? Do you think a game should/can have both?
  • What's your favorite character class?
  • How would you briefly describe the mechanics of your favorite game to a non-programmer?
  • Do you usually play games to the end?
  • What's your Beta test experience? (No, you're not looking for a QA person BUT it doesn't hurt to hire a programmer who thinks like a QA person at least a little, as in being able to vet their own work before they hand off a fix as "done.")
  • What's your favorite game of ours and why? (If you've only published one game, they better have played it! And listen for their own words--if they sound like they're parroting what they read about your game, it's entirely possible they haven't actually played it.)
  • If you could work in any other area of our industry, what would it be and why?
  • What makes a game fun for you? (No, you're not hiring a game designer BUT the programmer's job is to make the designer's vision work.)
  • If time and money was no object, give me a quick pitch for a game idea. (No, you're not hiring a marketing person but you want your employees to be well-rounded and be able to communicate with each other.)

    Although there's no single magic formula for hiring the best programmer, you've got a lot of tools at your command that will give you a pretty good sense of which candidate has the right skills and is the best fit for your company.

    Marc Mencher Biography:

    Game Programmer / Technical Producer-turned-Recruiter and Career Coach, Marc Mencher has been in the Game Industry for 27 years. He is the founder and CEO of GameRecruiter www.GameRecruiter.com

    Marc began his career working for Spectrum Holobyte, Microprose and The 3DO Company. While he enjoyed coding, through the experience of developing product and leading teams, he realized that his true passion was helping people plan and manage their careers.

    Marc is the author of "Get in the Game!" an instructional book on building a career in the video game industry. His articles have been featured in a variety of industry publications. He is a speaker at game industry conferences and volunteers as an advisory board member for several colleges. Marc has been interviewed on television and radio as an expert on working in the videogames industry.

    His detailed bio can be found at http://en.wikipedia.org/wiki/Marc_Mencher

    Along with his team of Recruiter / Career Agents, Marc has had the pleasure of representing the game industry's hottest talent, and has helped thousands of people manage their career and obtain strategically important game jobs. Integrity and confidentiality are the cornerstones of his success.

    ? Special Thank You: Kody Kahrizi for participating in this article.

    Kody is a talented game programmer with over 10 years of experience. Specialized in Animation and Gameplay coding. He began his career teaching C++, physics, engine development, software architecture, etc... for Full Sail University's Game Programming degrees. He then joined EA Tiburon working on multiple titles under the EA Sports label. Currently he is a Lead Programmer at WMS.

Sign in to follow this  
Followers 0