Jump to content
  • Advertisement
Sign in to follow this  

advice for focussing my studies

This topic is 4139 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've been doing alot of reading on the gamut of the individual modules of what goes into building a game from the ground up. Its a little overwhelming to be honest. I work best in small chunks of knowledge to put something together piece by piece, so to play to my strengths I though I'd list the things that intrigue me in developing a game. In the hopes that I ca nbetter organize my study habits. I've already chosen a language (C#) and 1: I love programming. Few things make me as happy as a source file compiling without errors and executing how I predicted. 2: As fascinating as all the math behind renderring is as well as getting all the media pieces fitting together into a cohesive box of buttons looking like fun..it doesn't seem like my cup of tea. 2a:I prefer using the engine to build my worlds and stories. 3: I enjoy problem solving. When looking at a possable job in the industry, I'd like something where I still have to come up with ways of getting things to work as opposed to simply putting already working pieces glues together. 4: Envisioning and comming up with a plan to make it happen are both great fun to me when it comes to the stories behind games. 5: AI is also fascinating, but not something I want to keep dreaming up day after day. 6: I love making tools! My first program was actually a python script to parse damage from an everquest2 combat log file and print damage done/damge done over time/damage done relative to other people attacking the creature. Basically a dps parser. One of the first things that popped into my head when I realized just how much I wanted to be involved in making games was how do gm's intereact with the game world to fix issues? How do devs build and test new player usable items/creatures/zones/etc. ? Reading over what I've listed, I know that engine programmer isn't something I'd enjoy doing overall. I want to take a crack at building my own game engine one day, but not something I'm aspiring to. Its something more out of "I want to understand it better so I'll build it" mind set. What sort of industry position (besides the designer ideal, which while also something I could live happily doing, it would bea 2nd choice) is a game programmer that builds worlds, systems, and objects but doesn't put together the underlying way those objects exist to the machine? With those most interested notions listed, what subjects stand out as "need to know as much as possable asap" and "is good to know, but can wait `till you run into it or you've at least have a thorough understanding of something else first" ? Thanks for your time.

Share this post

Link to post
Share on other sites

First, let me say your list of interests was well thought out. Few people are as clear about their strengths and weaknesses, interests and disinterests, as you are. So congratulations for that. Ok, on to the fun part.

There are roughly 3 types of Game Programmers currently seen in the industry in larger companies. (these are less seen in smaller companies as people often take on multiple roles)

1. Engine Programmer
2. Gameplay Programmer
3. Tools Programmer

The engine programmer is usually responsible for some component(s) of the underlying game system. This is often graphics, audio, networking, database, physics, user input, etc...These people bear the heaviest burden as their workload is largely at the whim of the technical director. Also, their work is arguably some of the most tedious, intricate, and problematic, as their work is often part of company libraries which are used on multiple game titles, and as a result get the most exposure, and must support the layer upon layer of crap that's stacked on top of their platform foundation.

The reward for these people comes from solving the really difficult problems, the love of programming, and not necessarily with seeing the "game unfold" or for making fellow workers or players happy. They do their jobs because they enjoy the work.

Above the engine programmer is the gameplay programmer. These people tend to work more on game-specific problems and systems. For an RTS game it could be AI, fog of war systems, HUD interaction, unit management, combat, etc...And depending on how strongly branded a company is, these often get brought into the engine at some point. But the main issue is, the work they do is much more closely tied to the gameplay and style of a game. As a result, they often answer to the Creative Director and or Lead Designer in addition to the technical director.

For these people, the magic of game development is in seeing their work come to life in-game. Additionally, they thrive on player feedback, and seeing people enjoy their games.

Finally, there's the tools programmer. In many ways these are the newcomers to the scene, and as a result their roles aren't as well defined. Ultimately, however, the job of a Tools Programmer is to make the lives of everyone else easier - be it the artists, designers, or even the producer. Tasks for the tools programmer is often development of a game world editor, asset management tools, import/export code for the various modeling packages and game file formats, data converters & compression, and game balancing tools.

Tools Programmers often work as the intermediaries between the artist, designers, and programmers. Their knowledge of modeling packages allows them to bring the artists closer to the game, while helping the engine team better understand the needs of the artists. As well, their relationship with the designers helps them deliver tools which allow the designers to do their job more quickly, and thus open up the realm of possibilities within a game. Tools programmers often report to the Lead Designer/Creative Director, or even the Art Director, and may have limited exposure to the Technical Director.

For tools programmers, the job is about satisfying their fellow workers, and reveling in their ability to make the game possible, through improved tools and decreased turnaround time on asset creation, integration, and the development of design tools which helps bring the game to life in front of the designer.

Now, looking over your list again...this is what I see...

1. Any programming job
2. Gameplay/Tools Programming
3. Any programming job
4. Gameplay/Tools
5. Gameplay
6. Tools

And then reading over your blurb after the list, I'd say your primary area of emphasis should be in Tool development.

Necessary skills for tool development are:

* Integration/Extension of Asset Creation tools (Maya, SoftImage|XSI, 3D Studio Max)

* Development of World Editors (User Interface, Rendering (transforms & projection), Terrain Manipulation, Object Manipulation, etc...)

* Windows Applications (C++ & MFC or C# and WinForms)

* Localization Tools (Unicode and other Character encoding formats)

So, I'd recommend getting one of the programming books on the Maya API and MELScript. Also, work on making a level editor for a popular, well documented game file format. And Finally, learn/brush up on your C# and WinForms programming including your ability to use each of the main control types and to be able to override them to add unique functionality.

For Localization, get familiar with character encoding and Unicode. Work on displaying multiple languages and character sets within an application window. Write a story, and have friends translate it or use a service such as babalfish, etc...then use the Windows Locale system to display the story in whatever language the OS is set to use.

For more information, simply check out Gamasutra, GDNet, and GameJobs and see what skills their looking for in their Tools Programmer Positions. Then do what is necessary to obtain those skills. Tackle the hard problems and you'll have an impression reel of demos and tools to show off.


Share this post

Link to post
Share on other sites
Your responces are always full of great info jw, thank you. Now I've got a narrower field of subjects to stack on my plate and chew on before I branch out again looking for more input.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!