Interactive Media GmbH

My role in the project:

• 
  Programmer for particle systems and user interface (menus)
  
• 
  Music composition and production
  

Graphics meets Games Interactive Virtual Lobby

About the project:

• 
  Virtual walkthrough launcher application for the Showfloor games at Eurographics
  
• 
  Hundertwasser-style application, with “games” hidden behind each door
  
• 
  Special “on-demand” project requested by Dr. Michael Wimmer of the Institute of Computer Graphics
  

My role in the project:

• 
  Testing and debugging
  
• 
  Content (texturing, some modelling)
  

Metal Hazard

About the project:

• 
  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
  

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)
  

Risks:

• 
  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
  
• 
  Handling: Scaling down the feature, finding a cheaper replacement that does the same job as well
  

• 
  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.
  

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.

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
  
• 
  Story with depth
  
• 
  Well balanced Character Development statistics system
  
• 
  Likeable characters
  

What I disliked

• 
  Graphics performance in relation to graphics quality (back then…)
  
• 
  Despite the gameplay freedom, the story was completely linear except for the last level
  
• 
  Sequel was poor in comparison…
  

How it could be improved

• 
  Environment manipulation that actually affects gameplay
  
• 
  Branching story
  

Broken Sword series (known as “Baphomets Fluch” in german), PC

What I liked

• 
  Beatifully drawn backgrounds and characters (for the first 2 games)
  
• 
  Dynamic music that adapts to what happens on-screen, recorded by a real orchestra
  
• 
  Witty dialogue
  
• 
  Likeable characters
  

What I disliked

• 
  Despite the witty dialogue, the game was rather wordy
  
• 
  The 3D incarnations (third and fourth game) were rather weak
  

How they could be improved

• 
  Utilizing 3D technology to actually create beautiful environments, instead of using 3D as a “checklist feature” only for the game box
  
• 
  Better skippable dialogue and cutscenes
  

Xenogears, Playstation

What I liked

• 
  Just one example of the many japanese RPGs that I like
  
• 
  Deep story with religious critical undertones that almost prevented it from being released in the USA
  
• 
  Likeable characters
  
• 
  Well balanced combat system
  
• 
  Incredible music, despite running on the PSX-Synthesizer
  

What I disliked

• 
  Cutscenes are not lipsynced, at least in the US version
  
• 
  Second disc feels rushed, much less effort done on presentation
  

How it could be improved

• 
  More polish put into the cutscenes
  
• 
  Orchestrally recorded soundtrack
  

- Please list your favorite industry references (Programming, Graphics, etc.), such as books or websites, and why you liked them.

• 
  GameDev.net – good forum and articles for reference
  
• 
  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.

1 month solution

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?

Issue:

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.

Possible solution:

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.

Issue:

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.

Possible solution:

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.

Issue:

Output on a TV is different from output on a monitor. Or more generally spoken: output devices differ.

Possible solution:

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.

Issue:

Input devices also differ. A control scheme for one platform might not work at all for another.

Possible solution:

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.

Issue:

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.

Possible solution:

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?

Ogre3D

Wrote a simple game prototype for our EU Gametools demogame (see first question) before actual programming of the custom engine

Ageia PhysX

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.

FMOD

Used for various small projects before I wrote my own audio framework using DirectSound.

Ogg/Vorbis

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.

Download 37.34 Kb.

Share with your friends: