Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[dragnar]

I know there are a... rather surprising number of game developers on this board. So, what better place to ask for some advice about it? I'm hoping to go into game development after I'm out of college. But so far... well, I really don't know where to start. My classes are helpful and all, but they aren't hands-on enough(I know what a Game Design Document is for example... but couldn't BEGIN to write one). So in short: Any particular advice you all have on getting started? Ways to practice, resources, tutorials... anything would be helpful at this point really.

[LordBucket]

I'm hoping to go into game development after I'm out of college.

If you really want a job in the gaming industry, my advice would be to pick a company that you really want to work for, then go and apply for a job. Any job. Quality Assurance, most likely. But tell them you'll take a job as a janitor if that's what they're hiring. Degrees are nearly worthless, and experience is valuable, but far more valuable is knowing people.

Yes, tell them you're working on your computer science/programming/graphic design/whatever degree. And tell them that your life's goal is to be a game developer. And then tell them that you're so enthusiastic about it that you don't want to wait to finish your degree, you want to be involved in the industry right now in the meantime while you're working on that degree. Hiring managers remember that kind of thing, and whatever value there might be in a degree, or experience, or knowing people, your best bet is to have all three. If you get a job in QA, and six months from now a developer position opens up, who do you think they're going to give it to: someguy they don't know, fresh out college with a piece of paper from some university, or you...who is friendly, cheerful, and has a sixth month track record of being reliable, dependable, and observant of detail?

My experience has been that most hiring decisions are made within the first 10 seconds of an interview. And only human resource depatrtments care about resumes or formal qualifications. Being likable can get you a job. Being enthusiastic can you get you a job. Degrees don't get you jobs. Degrees get you interviews.

By working for a company in some other capacity (QA, etc) you give them the opportunity to get to know you. And you get to know them. Knowing people is extremely valuable in any industry. And, if six months down the road a developer position opens up, odds are good nobody is really going to care if you still need two more years to finish your degree so long as you're enthusiastic, likable, and capable of doing the work.

Any particular advice

1) Identify exactly what you want.
2) Pick a company you like and get your foot in the door in any capacity. QA is a good place to start, as it's often an easy job to get and it's much closer to the developer's chair than janitorial work is. But take the job as a janitor if that's all you can get. Anything you can do to be there, talk to those people, and give them the chance to remember you is likely to help you.
3) Don't worry about formalities or degrees, and if a job listing states that it requires 5 years of experience or something...apply anyway. Human resource departments write job descriptions. Department managers make hiring decisions.
4) Go ahead and keep working on your degree, but don't expect it to make much difference.
5) If you apply and don't get a job, that does not mean no. It means: not right now. Keep checking their job listings. If a new position opens up, reapply. Previous applications are generally trashed, but if you show up a month later still enthusiastic for the company, that will make you stand out.
6) If the company you choose has released modding tools, make a point of being familiar with them before you show up for the interview. For example, if you applied to Blizzard, it would probably look good if you had authored a number of starcraft maps.

[Soulwynd]

As for actual game design you need to realize that a game is nothing more than working with a database in its very core. Whenever a creature move in a game, it's nothing more than grabbing an entity out of an array, if it's an object (as in OO programing) you will most likely have a method to change its value. If you want your game to work fast or handle large numbers, you need to learn every possible shortcut to search operations there are. There are countless hints like that and things you learn to make your game viable.

A few programming hints:

-Double reference anything that is used a lot. Example:
Backpack id 873 has an array the describes what it contains: etc etc etc etc torch8329 etc etc
torch8329 has an integer (or an object reference) that points to where it is: backpack837
So whenever something happens to this torch, you can tell where it is without having to search through every backpack or possible locations. For example, if a player removes a torch from his backpack and holds it, you know from which backpack you need to remove it's reference. This applies to pretty much everything in a game. Double reference anything that is used a lot. The good side is that you don't waste cpu time searching stuff and the bad side is that you eat a bit more memory, but it's worth it.

-If the language you're using allows for referenced arrays, use them only if it's something you cannot double reference.
Pointing straight to an array element through an integer is faster than use the referenced methods languages provide you. Of course, those methods are usually faster than doing your own search function. Numeric references are also faster than named ones. Using 42 as a reference is better than using 'life universe everything'.

-Start with something simple
Make a mapeditor for rogue-likes that work on the regular console. This will help you learning binary saving/loading of data structures and how to manage databases. Next step would be creating a character you can move around. This will help you learning how you can use a variable in an object to be displayed for the user and how to interact with it. Then come with a light of sight code for him. This will help you learn that matrices and a lot of algebra is used in game programing. Everything happening behind the screen is pure math and even tho it seems horribly complex, once you get a recursive function going, the computer does all the work for you and suddenly, it's not that complex anymore.
After that, start learning opengl and directX, how to make cubes rotate around, how to animate things even if randomly. If you want to get into 3D game making, you should at least know these things, even tho the work can be split in such a way, you might never actually see the 3D part of the code. For an example, someone working with the source (valve) engine doesn't have to worry about how to display his 3d object, the engine does it for him. But it helps to learn how it works and what are the trappings.

-Learn the difference between reactive code and active code.
It's something every programmer should know, but they apparently forget. Every game is essentially a huge loop, you have to make sure it doesn't loop through unneeded things. Learn how synchronized threads and multi-threading works, this can mean the difference between sluggish controls and responsive controls, even on a slower CPU. Just because something goes wrong, it doesn't mean your game has to crash. A thread might have bugged for one reason or another, but if you can catch it and restart it, you can just display an error message and go on with the game. A few more advanced methods include soft software reboot, where you can dump your memory, reload the code and rerun the game/program at the same state it was before, this is essentially crash prevention without dataloss for servers, not even dropping any clients. It also gives a good platform for softrebotting and I should know this, I programmed MUDs for years and nobody even knew my mud had rebooted, everything went on as normal for clients.

-Self-repairing and dynamic loading
Now that you should have a tiny game working, learn that you don't have to load everything at once. Things can be loaded as needed and it can be done in the background as well. The unreal engine is a fair example of that, it loads objects and textures on the fly as needed and not necessarily when you're switching levels. Making good use of threads is important for this. Also learn that just because a file is missing a certain data, it doesn't mean your game has to crash or reject it (Notch should learn this). Always give default behaviors and values for everything, in case you cannot load it. This is specially important for servers, such as mmo servers when you add code and you need a variable that the data files do not have yet, so the code can apply a default behavior to it and then give the variable to the database next time it saves.



And there are probably more hints, but I'm too sleepy to remember every little thing I've learned and every thing I bumped into years ago when I was more active in programming stuff.


Just practice with a small prototype, just for yourself, keep adding things to it, testing methods of doing things and so on. You will quickly pick what works well, what doesn't, and what is faster. Don't be afraid to use shortcuts on your code, any tiny reduction on cpu usage in a function that is repeated thousands of times means a faster game. Learning to use a profiler or a profiled compiler also helps.

[Shades]

If you really want a job in the gaming industry, my advice would be to pick a company that you really want to work for, then go and apply for a job. Any job. Quality Assurance, most likely. But tell them you'll take a job as a janitor if that's what they're hiring. Degrees are nearly worthless, and experience is valuable, but far more valuable is knowing people.

I would disagree with this in that a lot of game companies won't even look at your CV if you don't have a degree of some kind (what kind and how well you did don't seem to matter so much). The exception to this would get QA/Testing which is a common in route into games for most companies. He's right that knowing people is far more valuable though, especially long term.

Bare in mind your pay will be terrible and hours will be long so make sure your working on a game you'll love.

If your south-east uk based I can probably give you some names for a few companies which should be enough to get you into an interview.

[Vicomt]

I would disagree with this in that a lot of game companies won't even look at your CV if you don't have a degree of some kind

So much this. 18+ years of development experience and I barely get interviews. Everyone wants bloody web developers script kiddies these days, not OO framework engineers.

[lastverb]

Everyone wants bloody web developers script kiddies these days, not OO framework engineers.

That's it, and that's why companies make so bad games lately.

[diamok]

Quick comment on degrees and experience -

Every company is totally different, one may want any prospective employee to have a degree in computer science, one may ask for any degree, many companies will hire individuals with degrees in a specific field due to aspects involved in the project they are working on.  For example, in the past a company hired a graduate with a degree in the medical profession, this company was developing a game based around that industry and needed/wanted someone on staff with a direct connection to the field.  In other cases, a company might want you to have worked on a released title, degree, no degree, x # years experience did not matter, just that you worked on a shipped product.  I got my role on Hero's Journey because I played Dungeons and Dragons...honestly, the main factor for being brought into the Hero's Journey project was my experience in creating worlds, characters, stories and Dungeon Mastering for more than 20 years.

Advice would be get your degree, especially if you are already in school.  Having a degree shows discipline and demonstrates the ability to learn and be taught.  One thing all companies have in common, they want things done THEIR way, having a degree will show them you can and are willing to learn how things are done in their house.

Also, while I do not agree with everything LordBucket mentioned, I do agree that taking a job as a non-designer can and will lead to design.  Many of today's designers (realize there can be tens or even hundreds of designers per title) have started as QA guys...before I got out of the industry, that's how I got my start.

Good luck and take care,

[DaveT]

http://sloperama.com/advice/ - This is the standard place that people who post on gamedev.net get routed to

The guy comes across as an arrogant jerk but he really does know what he's talking about.

[dragonshardz]

I'm hoping to go into game development after I'm out of college.

If you really want a job in the gaming industry, my advice would be to pick a company that you really want to work for, then go and apply for a job. Any job. Quality Assurance, most likely. But tell them you'll take a job as a janitor if that's what they're hiring. Degrees are nearly worthless, and experience is valuable, but far more valuable is knowing people.

Yes, tell them you're working on your computer science/programming/graphic design/whatever degree. And tell them that your life's goal is to be a game developer. And then tell them that you're so enthusiastic about it that you don't want to wait to finish your degree, you want to be involved in the industry right now in the meantime while you're working on that degree. Hiring managers remember that kind of thing, and whatever value there might be in a degree, or experience, or knowing people, your best bet is to have all three. If you get a job in QA, and six months from now a developer position opens up, who do you think they're going to give it to: someguy they don't know, fresh out college with a piece of paper from some university, or you...who is friendly, cheerful, and has a sixth month track record of being reliable, dependable, and observant of detail?

My experience has been that most hiring decisions are made within the first 10 seconds of an interview. And only human resource depatrtments care about resumes or formal qualifications. Being likable can get you a job. Being enthusiastic can you get you a job. Degrees don't get you jobs. Degrees get you interviews.

By working for a company in some other capacity (QA, etc) you give them the opportunity to get to know you. And you get to know them. Knowing people is extremely valuable in any industry. And, if six months down the road a developer position opens up, odds are good nobody is really going to care if you still need two more years to finish your degree so long as you're enthusiastic, likable, and capable of doing the work.

So much this. I'm not in the game industry by any means, BUT! I know that there's an open position at Valve for Customer Support people. I am gunning HARD for it - I am meticulously crafting my resume so that it menaces with spikes of awesome. I want to work for Valve as a game design guy, so I need to get my foot in the door NOW.

[dragnar]

I continue to be amazed at how quickly this forum responds to questions. Thanks for the advice everyone, gives me somewhere to get started. Of course, the hard part is actually doing so...

[gimlet]

The sloperama thing is pretty good, this guy http://www-cs-students.stanford.edu/~amitp/gameprog.html has links to some advice too - esp in the top FAQ 5&6 "What do I need to learn once I know how to program? What do I do after school?"

There *used* to be some half-decent online courses for cheap ($100 or so) if you really need the structure to get yourself started/oriented.  I'm way out of touch with that though - look on gamasutra/gamedev/etc to see if that's still a viable help.