Jump to content
  • Advertisement
Sign in to follow this  
michaelnwani

I would like someone to drop some knowledge on my bad self

This topic is 2395 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 apologize if I should be looking elsewhere first,

I'd like it if someone could give me, or provide me with a link, as to what goes into the game programming development process in the big industry. We'll use for example, Epic Games. The languages the company uses to say, create Gears of War, how engines are made (like UE3 and Havok), the modeling and stuff. Is the modeling done by an art team and then the coders have to manipulate the character movements the right way? Even videos would be great.


Any and all input would be greatly appreciated.

Share this post


Link to post
Share on other sites
Advertisement
([size="1"]I'm not a professional game developer, just a hobbyist / indie dev. I'm also not a 3D modeler[size="1"], I'm a programmer)
Gears of War was originally a tech demo for the Unreal Engine. It was created with Unreal Engine 3, and was written in C++ and (presumably) Unreal Script.

3D modelling is usually done by... *bum-bu-da-bum* 3D modellers! Not the 2D artists, or the concept artists, but artists who specialize in 3D modelling. They have people come along and then texture the 3D modelling (model skinners) and people come along and rig a skeleton to it (riggers) and animate the 3D modellers (animators). Companies sometimes require 3D modellers to be able to do all four of those things (or at least more then one), and I'd guess they'd love it even more when you can even create the concept art, and then model, texture, rig, and animate it (perhaps through motion capturing).

Engines are made by experience, from first having built games. You should always write games, not engines, otherwise you'd probably end up making crappy engines that can't be used easily to make games (unless, ofcourse, your end result *is* to write engines and not making games).

Many famous game engines have been refined by constantly using them to make commercial games. A famous example of this is the Source Engine (Valve Software, used in the Halflife series, Left 4 Dead series, Portal series, Team Fortress series, Day of Defeat series, etc... each game in each series helped to expand the engine... which was originally licensed from id Software's Quake engine)

Share this post


Link to post
Share on other sites
This varies a lot; different companies work different ways, and different games have wildly different requirements. Any chance you can narrow down your request a bit? Or maybe provide some background on what you'd like to know about and why? (e.g. if you're curious vs. writing a research paper, etc.)

Share this post


Link to post
Share on other sites

This varies a lot; different companies work different ways, and different games have wildly different requirements. Any chance you can narrow down your request a bit? Or maybe provide some background on what you'd like to know about and why? (e.g. if you're curious vs. writing a research paper, etc.)


What I'd like to know is out of pure curiosity. Since I'm a computer engineering major sophomore in college and my dream job would be to be a programmer for a big name company that I absolutely love, like Bethesda. Epic, Valve, Blizzard, etc.

I just wanted to know what their processes are like in creating their iconic games as far as the meat of the games coding goes, like is it mostly C++? I'm very aware my question is a broad one... so for an example I wanted to know the processes that went through the likes of Gears of War for me to get an understanding, from start to finish really if that's cool.

Share this post


Link to post
Share on other sites

([size="1"]I'm not a professional game developer, just a hobbyist / indie dev. I'm also not a 3D modeler[size="1"], I'm a programmer)
Gears of War was originally a tech demo for the Unreal Engine. It was created with Unreal Engine 3, and was written in C++ and (presumably) Unreal Script.

3D modelling is usually done by... *bum-bu-da-bum* 3D modellers! Not the 2D artists, or the concept artists, but artists who specialize in 3D modelling. They have people come along and then texture the 3D modelling (model skinners) and people come along and rig a skeleton to it (riggers) and animate the 3D modellers (animators). Companies sometimes require 3D modellers to be able to do all four of those things (or at least more then one), and I'd guess they'd love it even more when you can even create the concept art, and then model, texture, rig, and animate it (perhaps through motion capturing).

Engines are made by experience, from first having built games. You should always write games, not engines, otherwise you'd probably end up making crappy engines that can't be used easily to make games (unless, ofcourse, your end result *is* to write engines and not making games).

Many famous game engines have been refined by constantly using them to make commercial games. A famous example of this is the Source Engine (Valve Software, used in the Halflife series, Left 4 Dead series, Portal series, Team Fortress series, Day of Defeat series, etc... each game in each series helped to expand the engine... which was originally licensed from id Software's Quake engine)


As far as I know, 3D modelling is literally creating everything about the games look from scratch right? And so (bare with me here) that's sort of like a blank doll, waiting to be programmed to move around (I'm guessing that's what "animation" is all about). Since I'm a C++ Apprentice (but whatever you throw at me in words I'll get it), how does an engine and a game get built from scratch in code?

Share this post


Link to post
Share on other sites

As far as I know, 3D modelling is literally creating everything about the games look from scratch right?

Not really. Someone else decides how the game looks, and the 3D modelers have to make it look like what they were told to. Plus, 3D modelling is usually different then level/world design. Even though the process of creating levels using a level editor may be similar in concept (using polygons to make something 3D) there's different focuses. Level designers need to know about how players think; what the average player would do when encountered with situation x or y.

For example, recently I read about how some game designers realized that if encountered with two different routes to take, and one was very subtly better lit then the other one, players would subconsciously know that the better lit route was the 'main path' to take. Level designers study that kind of thing. Things like balancing non-mirrored maps in online FPS games, or figuring out exactly how much monsters they can throw at a player to make the player feel adrenaline and rise to the challenge, and how much is too many monsters that make the player feel too pressured and think the game unfair.

3D modelling has more to do with making objects look as realistic (or as aligned with the graphical style of the game as possible) with minimal use of polygons.

And so (bare with me here) that's sort of like a blank doll, waiting to be programmed to move around (I'm guessing that's what "animation" is all about).[/quote]
The programmers don't animate the models. The programmers set up the game so that the people creating content for the game, like the event scripters can, say "Have monster #227 attack", and monster #227 says "Whatever model was set to me, change the animation to 'Attack_animation1'", and the model loads and runs 'Attack_animation1', and that animation tells the model where and how to position the 'bones' of it's virtual skeleton over time, until the animation is completed. Someone else besides the programmer creates the model, someone else besides the programmer creates the animation file that explains how to animate the model.

Yes, at the basic level, the programmer is the one who wrote the code that actual turns that model into something visual and the animation file into movement ingame, but that only needs to be done once; he writes the code that loads the animation files and the model files, and someone else can create all the different models and all the different animations.

Programmers are also the ones that explain how to make an image appear onscreen... but the programmer isn't the one who has to make every single image. It's the same with models and animations.

Since I'm a C++ Apprentice (but whatever you throw at me in words I'll get it), how does an engine and a game get built from scratch in code?
[/quote]
If you are making something from scratch, figure out what your goal actually is. If your goal is, "Make a engine" then go make an engine... but you wont end up with a game. If your goal is, "Make a game", then forget about making your own engine, it just gets in the way. Just focus on making the game itself, and if you write good code, your 'engine' will naturally appear. An 'engine' is really a overused term that means, "The general architecture of the game's code, without the game-specific parts". If you're making a game, then once you complete it you can just remove the game-specific parts and admire the engine you accidentally created while making the game. You can then use that engine as the basis of your next game, if you like, but you'll still find yourself tweaking, enhancing, and changing that engine as you work on the second game.

People think they need to write an engine to create a game. Nope! They need to write a game to create a game. wink.gif

The second part of your question was, how does a game get built from scratch? Well, there are many many many methods that people use. Different people have their preferred methods, and there is alot of studies and arguments about what's the best way.
Personally, as a young programmer myself with only 6 years experience (vs the 10-15 year programmers who really know what they are talking about), I prefer to think about what I want to do, a small piece at a time, and then grow my game bit by bit.
For example, I start by thinking, "My game needs a window. How can I do that?", once I think how to do that, I then go and do it. Sometimes I have to do it three or four times, because my initial idea was flawed. Then I say, "I have a window. My game needs a character onscreen. How can I load an image and get it to move around?", then I go and do that. Weeks and months later, my game has grown so much, that I can say, "I have a character moving around and enemies moving around and levels being loaded. My game needs to let the player cast a spell. How can I make that happen?". While working to implement the next thing and the next thing, I have to often go back and clean up and even rewrite some of the old code to make it cleaner and integrate better with the new code. After you do that enough, you start to think, "How can I write this next piece of code right the first time, so any future pieces of code I add wont require me to rewrite this one?", then you learn to grow your code organically, while thinking about and mentally laying out code that you'll know you'll have to write months down the road, so the code you are currently writing doesn't just fit in with the code that already exists, but will also fit in with the code that will eventually exist. But sometimes you still have to go back and rewrite things anyway, and that's ok too, as long as progress is made and your end goal ('Making a game') is actually eventually reached.

But that's just one way of writing games, and it's probably not the best way. Buy a couple books, do some research, and decide for yourself how you ought to architect your code.

Share this post


Link to post
Share on other sites
A stereotypical games studio might look like:

Gameplay programming team -- Uses high level languages like C++, Lua, Python, UnrealScript, etc... Writes the gameplay, and may also cover things like User Interface, character animation systems, AI, audio, special effects, etc...
Engine programming team -- Uses systems-level languages, like C, C++, etc... Writes the low-level systems required by the gameplay team, like file streaming, 3d rendering, audio, animation playback, physics, etc...
Art team -- contains 3D modellers and texture artists. Uses 3D packages like Max/Maya/ZBrush/etc and 2D packages like Photoshop to build artwork such as characters, environments and props.
Animation team -- contains animators and riggers. Uses 3D packages to animate the artist's 3D models. Works with the gameplay team to hook these animations up to the gameplay code. May also work with motion capture studios as a base for some animations.
Audio team -- creates sound effects and music. Works with the gameplay team to hook these sounds up to the gameplay code.
Technical art team + Tools team -- creates the tools, scripts and plugins required by the content teams (art/design/audio) to automate their workflow and get things done efficiently. Often programs in productivity languages like C#, and scripting languages like Python, JavaScript, MEL, etc...
Design team -- figures out what everyone else is going to build. May also include "hands-on" designers, such as level builders or quest/combat scripters.
Concept art team -- takes the designer's words and turns them into pictures that can guide the art team.
Production team -- makes sure everyone knows what they're building, and that they'll get it done on time.
QA team -- makes sure the things that are actually built match up with what was supposed to be built.

Each of these teams may range in size from 1 person to a few dozen people.


To work in this kind of environment as a programmer, I'd recommend learning C++, C# and Lua.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!