Questionnaire Thanks for taking the time to fill this out! It’ll help us to get a better understanding of you as a programmer and person. We will then follow up on this with an interview to discuss your answers. Some questions may seem a bit vague, but they are intentionally so.
- List all games or other relevant projects you’ve worked on with a detailed description of your tasks (if you haven’t done so in your CV already)
EU Gametools Project demogame “Penta-G” (tentative title)
Entry for the Computer Graphics 2/3 Lab at the Institute of Computer Graphics at TU Vienna, in the year 2002
Winner of the Best Game award of that lab that year
My role in the project
Lead programmer (engine, game code, effects)
Music composition and sound effects
- For a “budget” (PC, Retails at 15-20 €,$) FPS game with middleware (graphics engine, physics engine – both available to you) for the casual pc gamer, which programming tasks are most relevant to the development of the game and how much time would you plan for each of the tasks? Any risks involved? How could they be handled?
Most relevant tasks:
Exploring (i.e. “learning”) the middleware (4 personweeks)
Programming the gameplay and game logic built on the middleware (8-12 personweeks)
As necessary by the game’s needs, adding new features that the middleware does not provide (1-2 weeks per feature, depending on the feature)
Establishing a good tool chain that aids the workflow (2-4 personweeks – also dependent on what the middleware provides for the tool chain)
Making sure the technical requirements are scalable enough so that they suit the common casual gamer, who, opposite to a hardcore gamer, oftentimes does not possess highend hardware (at least 1 personmonth)
This also means thorough testing and debugging so that the game simply “runs (almost) everywhere” (also 1 personmonth)
Risk: Middleware could be unsuitable or lacking features, in which case these features will have to be implemented on top of the middleware, which, depending on the middleware, can be a daunting task.
Handling: Thorough inspection of the middleware used, and proper usage of middleware developer support (as offered by the maker)
Risk: A feature required might increase the technical requirements in a way that the target audience of casual gamers would not meet these requirements, for instance, a high-end graphical effect
Risk: The middleware could turn out to have (known or unknown) issues that might complicate both the process of implementation of the game as well as testing and debugging
Handling: Try to avoid these issues by working around them, utilizing middleware developer support
Risk: A feature might take longer to implement than anticipated or planned
Handling: Better planning, or if it already “happened”, put more personal resources (overtime) into finishing on deadline. More people could also help if these people do not require too much time getting into the project, but this is always an extra risk.
- For an action based car racing game with 6 cars on the track, what AI models and
algorithms would you suggest for the opponent cars? The target platforms also includes PS2, so consider CPU usage and state a processing time budget for the AI that you believe to be reasonable or necessary (something like”x% of a 60Hz Frame on PS2 will/should be used for AI”). For an action based car racing game (opposite to a more simulation based one), I would suggest an AI model that is computationally simple, but challenging (focus on “plausibility” over “realism”).
Since computational requirements are an issue, I would suggest a finite state-machine-driven behaviour model where opponent cars have more complex behaviour (i.e. trying to overtake, or trying to push the player off the track) when close to the player’s car, while they will do not much more than simply staying “on track” when they are not close to the player. The states could also include further influences like “aggressiveness” or “car is damaged”, which would then modify into which state the AI transitions.
With such a simple AI model, it is not necessary to invest massive time into AI, so around 10% of a typical PS2 frame should suffice. In an action based car racing game, graphics as well as car physics are probably the main areas of focus and those should take the most processing time.
- Please provide a codesample which you consider well structured and programmed using a good style. (See attachment codesample.zip)
- What are your favourite games? What do you like in them, what do you dislike? Any ideas how they could be improved? In general, I like most story-driven games, which means my favourites genres tend to be adventures and roleplaying-games. Here are some examples:
Deus Ex, PC
What I liked:
A lot of freedom in an RPG-First-Person-Shooter genre mix; spiritual successor to System Shock 2, another one of my favourites
Gamasutra – news and articles reaching beyond graphics (also game design, visual arts, audio, business)
NVIDIA and ATI developer websites – lots of example sources and tools/SDKs
GameDeveloper Magazine – occasionally contains interesting articles, despite being rather thin. Especially the Postmortems are an interesting read. Used to get it as part of my IGDA membership, now I occasionally buy the e-version.
GPU Gems series of books – some nice state-of-the-art articles on exploiting current-generation GPUs
Game Programming Gems series – also some nice articles, serves as a good inspiration to solve some problems that arise during game development.
- The problem is finding the path in a 3D FPS environment. Enemy soldiers should be able to walk through the landscape without colliding with any obstacles. Provide 3 different suggestions considering you’d have 1 day / 1 week / 1 month time to implement a solution.
1 day solution
I would consider it near impossible to do thorough and general pathfinding solution in 1 day, but considering some game-specific factors like “landscape” (versus “indoor”), I would suggest enclosing obstacles in bounding spheres and implement an agent based approach, where each soldier would consider their path in front of them in their game-timer-advancing-function, and “slide around” these bounding spheres in order to reach the goal. This solution depends on the way the landscape and the obstacles are laid out, of course, as soldiers might run into “dead ends”.
1 week solution
For a one week solution, I would implement a waypoint graph based approach that calculates a path along the edges of the waypoint graph using algorithms like A* or similar ones. The waypoints can be either set manually by the level creators, or precalculated.
In 1 month a dynamic solution should be possible, where obstacles actually can move/change, and enemies are capable of “blind pathfinding”, i.e. they only know of their direction surroundings. This could be done as a mixture of the above two solutions: an agent-based approach where each soldier autonomically tries to get to the goal, aided by support information such as the waypoint graph. Local small dynamic Obstacles can be avoided locally by “going around them” like in the 1-day Solution, and large scale obstacles (that are static) can be precalculated or manually set into the waypoint graph.
- Consider a game that is developed for multiple platforms and simultaneous release, what sort of issues do you anticipate will arise compared to just developing the game on one platform? What kinds of processes or procedures would you put in place to solve/prevent these issues?
The target platforms vastly diverge in technical capabilities (CPU, RAM, Video RAM, Storage). It is impossible to get all the technical features for the highest spec version into the lowest spec version.
If the technical features are not gameplay-relevant, it might be possible to find a way to do a cheaper version of it that can be done on the lower spec hardware (i.e. resolution changes, or similar approaches).
For gameplay-relevant technical features, the lower spec versions might also need a redesign in certain areas.
One of the target platforms offers hardware that the others don’t (i.e. a second screen, unusual input devices, etc.), and it is desirable to actually make use of these features on that target platform.
This is essentially the opposite issue of the first one. On certain game genres, the kind of usage of the additional hardware a platform supports might be “natural” and logical, but if there is no such luck, either a new gameplay twist or feature has to be added for that specific version that makes use of the extra hardware, or the extra hardware isn’t used at all.
Output on a TV is different from output on a monitor. Or more generally spoken: output devices differ.
This can be both an issue an opportunity. On a TV or handheld screen, because of the limited resolution (depending on the platform), one might be able to scale down some content (texture resolution, etc.) in order to invest the freed resources into other things. On the other hand one cannot expect to deliver the same fidelity a high res monitor supports to smaller screens. One process that can prevent ugly surprises could be that testing on actual target hardware is performed frequently.
Input devices also differ. A control scheme for one platform might not work at all for another.
Each platform needs to reconsider the user interface design, which includes both the visual user interface (menus, on-screen-displays), as well as the control scheme.
Each platform is handled by a separate team, which aids parallelism, but introduces the issue that some work one team does might have already been done by another, basically reinventing the wheel. Or one practical issue might have already been solved by another team, resulting in waste of time resources.
Frequent communication between the different teams. Or more generally speaking, I would say communication is probably one of the most important things in any kind of project, both within a team, as well as externally.
- What middleware experience do you have? What specific tasks did you use it for?
Wrote a simple game prototype for our EU Gametools demogame (see first question) before actual programming of the custom engine
Used in our Gametools demogame for physics and collision. We used the static and dynamic actor types, as well as kinematic actors and character controllers, with Geometric Primitive/Triangle Mesh/Convex Mesh interaction.
Used for various small projects before I wrote my own audio framework using DirectSound.
Used in my own audio framework.
- What sort of work environment (team size, working hours, meeting frequency, etc.) work optimally for you? How do you like to be managed? I have worked in team sizes from 2 to 10 before, in private (work contract) and university (research and study) projects, as well as on my own. I think that these team sizes of up to 8-10 people work best for me. I think that good teamwork helps productivity.
This directly leads over to meeting frequency: I believe that meetings should be done “as frequently as needed, but as rare as possible”, meaning that meetings should occur often enough so that everyone involved in a project sees and hears the others frequently enough to stay up-to-date, but they shouldn’t occur so often as to harm productivity. Depending on the phase of the project, I think that meetings should be held at once a week, and probably daily in critical phases.
As for working hours, I tend to work until rather late, depending on the project. I have no problem investing more time into projects that are of high urgency.
- What strengths do you have as a programmer and as a person that you would contribute to Sproing and making great games? What are your weaknesses? I think my biggest strength is that I spend a lot of power and motivation into things (be it programming projects or other things) that I am enthusiastic about; graphics and game programming is one of those things.
As a programmer, one of my strengths is my capability to adapt. While I do have my own programming code style in private projects, I have worked in projects where the coding style was given in a document provided by the project leader, to which I had no problems adapting.
Another strength I believe is worth mentioning is that while my main focus is the area of programming, I am also deeply interested in all the other processes and disciplines involved in game development, be it visual art, audio, game design, business. One of the things that impresses me about the game industry is that this is probably one of the most interdisciplinary areas to work in.
One weakness I would tell about myself is that I tend to be overly motivated, and thus neglecting sleep; which can, when done for longer periods of time, affect concentration and health. I have sometimes programmed new shaders or features at 5 am till morning when I was very motivated.
Another weakness that people tend to tell me that I have is that I can be rather direct in conflict situations. I tend to prefer to resolve and clear up such situations by directly talking to someone about the issue, rather than trying to cover it up so that it may deescalate in a future situation. This is a weakness because sometimes, when covering it up, the issue resolves by itself, so the direct way is not always necessary.
- What do you think are the biggest challenges for the games industry in the next few years? What kind of strategy do you think Sproing (or a company like Sproing) could use to prosper? Aside from providing great games, I think one of the challenges is both attracting new kinds of gamers that never considered gaming a legimite pastime, as well as re-attracting old gamers who thought they grew out of games.
The first group is probably the largest group, and the challenge is to convince them that games are a legitimate medium for entertainment like any other. The second group is the kind of people who know classic games, but “grew out” of gaming. For both groups, the challenge is to trigger that playing urge that I think everyone innately possesses.
One of the concepts that can be used to attract nongamers would be casual games, or even game concepts that do not even feel like actual games (like the Brain Training games for the Nintendo DS). While the “hardcore gamer” market with its many almost repetitive game concepts can still be interesting, I think those are too “hardcore” to attract new gamers.
I think one strategy for Sproing could be to continue to run these two tracks – casual games and traditional games, and maybe gradually blurring the distinction between these two so that casual gamers might try out games that are not quite as casual. And with game concepts that attract not just already-gamers, but not-yet-gamers too, I think companies like Sproing could build up a larger potential audience.
That’s it! Thanks for filling out the questionnaire! In case you didn’t provide us with this information already, please make sure we’ve reiceived your full CV, as well as a letter describing why you would like to work at Sproing and what you believe you can add to our team.