• Advertisement
Sign in to follow this  

could someone explain the process

This topic is 3309 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

of creating a game? Probably sounds like a stupid question but heres my story in a nutshell, I've been working on pc's for about 15 yrs, customizing, building etc etc..but I'm mainly a hardware guy and I never really messed with software until recently. I just started learning python, C# and C++, downloaded XNA and did the 2d and started the 3d tutorials. I kind of understand the basic concept of how everything works together but i'm wondering if someone could explain a little more. for instance take a game like WoW, I know it takes a huge team to create something like that but stripped down to basics what is the process of developing something like that? I'm just not really sure how the constant changing backgrounds, other chars, enemys etc...work from the code. Does that make sense? then on top of that you have music, sound fx and everything else going on in the game. would someone care to elaborate kind of like if you were explaining it to someone who has never built a game before. I'm honestly blown away by some of the things I've seen done in games in recent years, I go way back to the days of pong and atari 2600.

Share this post


Link to post
Share on other sites
Advertisement
You are opening a huge can of worms. =)

I am by no means an expert, but I did work as a programmer for a game developer (not a very good one) for a little over two and a half years. I can tell you what I've gleaned from that experience, but keep in mind that it's just one outlook from a newbie programmer.

A team that makes a game will be divided into a few different disciplines, which include programmers, artists, designers, QA testers, sound effects & composition, and management. Most of these disciplines are self-explanatory, but I'll give a quick rundown anyway.

Artists include concept artists, level artists, character artists, and animators. Sometimes, you have artists that do nothing but textures. You also often have technical artists, which sort of act as liaisons between the programming staff and the art staff. They may also write some small scripts and programs to help the artists streamline their work flow.

Designers are the idea people. However, they usually don't just sit in a room coming up with ideas. They also have to help implement those ideas by writing scripts. More on that later.

The sound guys do all of the sound work, of course.

Managers decide what games get made, and how the projects are scheduled.

The programming team is responsible for tying everything together and make it all work in the form of a functioning game. Just as there are many jobs within the art discipline, there are many functions that programmers need to carry out. Usually, the game is divided into at least two layers: the game-specific code, and the underlying game engine or common libraries (i.e., the reusable code for basic stuff like rendering and audio, that all games use). There is also a suite of tools that need to be programmed: tools for exporting art data from programs like Maya and Max, for exporting sound data, and for designers to use for scripting.

I'm going to talk a lot more about the programming of it, because it sounds like you are interested in how a large game is coded.

Typically, from what I can tell with my limited experience, the game is not hard-coded to know what levels are going to be in the game, or what game objects (players, enemies, power-ups, lights, cameras, etc.) are going to be in those levels, or what assets (meshes, textures, animations, sound effects, etc.) those game objects will need. All of this information comes from external data files.

For instance, you usually have some sort of level description file, one per level, that has a lot of the above information in it. The game reads the level description file, loads all of the necessary art and sound assets, and loads the game objects, and then lets the level run.

The game objects themselves are often created, using some sort of scripting language, by the level designers. It could by Python, it could by Lua, or it could be some custom thing. At our company, we created a point-and-click interface in order to do this. There was a build of the game that they could play on the PC, and at any time during the playing of the game, they could hit a certain button, and the game would pause, and a whole bunch of dialog windows would pop up, allowing them to create new objects, drop them into the scene, move them around, and set their attributes. For instance, if they wanted to make a new enemy (call it a "Destroyer"), there would be a button for that, and when they clicked on the new enemy, they'd see a widget that they could use to move and rotate the enemy and place him in position. Then, there'd be a property sheet that they could use to set attributes like HP, ammo, etc. Then, they'd hit "Save", and the object itself would write out to a file, and that file would basically just contain information saying, "I'm a Destroyer. I am at this position, and I am oriented thusly, and my HP is this, and my ammo is that, and I'm using this mesh, and this animation library, etc." Of course, it wouldn't be in plain English like this, but you get the idea.

The game code itself is responsible for the low-level behavior of these objects. For instance, with the above example, there would typically have to be a Destroyer class of some kind. It will contain all the code defining how a Destroyer enemy behaves. When the game is loading the objects, it will come across the above file we created, it will see that it is for a Destroyer, and so it will instantiate an object of the Destroyer class, passing in all the info about its HP and stuff.

Now, as you are probably aware, games run in a loop. Input is taken & processed, objects are updated, and then a frame is rendered, and then the loop starts all over again.

Well, here's what happens. The scene that is currently loaded has a list of it's objects, right? Well, each object will have an update method, and so the first step is to call the update method of each of the objects in the scene. During this step, you can do pretty much anything you want, depending on the object. If it's an object that is controlled by the player, for instance, then it will check to see if any buttons have been pressed. It may respond to those button pressed by changing its state or its velocity. If the object has velocity, it will update its position. If the object is collidible, it may check to see if it has collided with any other objects in the scene. If it has, it may respond to that collision (for instance, if it collided with a bullet, it may respond by reducing its own HP). This is called the "Update Step" or the "Update Loop".

After that is done, and all of the objects are updated and in their new positions and in their new states and all that, its time to draw the frame. However, before anything is actually drawn to the screen, the game will typically compile a huge list of everything that needs to be drawn. This is often called a Render List. It does this because often times it is efficient to sort the list a certain way and render the items in that order. For example, its often expensive to change what texture you are using, so if you sort the list by texture, you'll get more efficient results. Because of z-buffering, there is no need to sort by distance. However, an exception to this is with objects that have transparency -- those objects must be drawn from back to front. So, you can see why it is important to compile a list of objects to be drawn first, and then sort them how you need to, and THEN draw them.

Also, keep in mind that there may be more than one list. If you are playing a 4-player split-screen game, then there will be 4 view ports on the screen, each of which could be displaying the same object. So, typically, you will create a separate render list for each of these view ports (one per active camera is a good rule of thumb).

So there is this pre-render step, which I'll just call the "Render List" step. Each game object class will typically have an AddToList method, or something like that. So, you call this method for each object once per list, passing the correct list to the function, so that the game object can decide if it needs to add anything to that list or not (it may decide not to if the object is not a visual object, or if the object isn't in the view of the camera associated with that list).

So, once all of the objects have had an opportunity to add stuff (meshes, or whatever) to each of the Render Lists, the Render Lists are sorted like I mentioned, and then they are actually rendered to the screen.

Hope this helps.






Share this post


Link to post
Share on other sites
Wow, that was a great response. thanks, that helps. I was really curious as to how everything works together. just the thought of having a character being able to moves pretty much anywhere in a 360 degree ares and see all those areas from a dozen different angles is just mind blowing to me. I was playing God of war on the PS2 last night and started really thinking about how everything works together
and it just amazes me for some reason

I guess things will start to make more sense as I get more into it, thanks again for the reply

Share this post


Link to post
Share on other sites
Quote:
Original post by CDProp
Designers are the idea people. However, they usually don't just sit in a room coming up with ideas.

To expand on that. It's a common misconception that the game designer is the idea person (the person who came up with the idea of the game being worked on). More often, the origin of the game concept isn't with the designer. The company executives may have licensed some IP, or the concept may begin with a desire to make a sequel to an existing game property, or with a desire to utilize existing technology. Or it could be an idea that the team brainstormed together.

The designer's job is to flesh out the basic concept into a detailed vision of the game, and to communicate that detailed vision effectively to the team. In addition, the designer is a good listener, embracing suggestions from the team into the design.

To the OP: there is a lot of information out there about the process of building a game. See http://www.sloperama.com/advice/lesson10.htm ("How the game development/production process works") if you still need to know more.

Share this post


Link to post
Share on other sites
Quote:
Original post by Tom Sloper
Quote:
Original post by CDProp
Designers are the idea people. However, they usually don't just sit in a room coming up with ideas.



The designer's job is to flesh out the basic concept into a detailed vision of the game, and to communicate that detailed vision effectively to the team. In addition, the designer is a good listener, embracing suggestions from the team into the design.


So I.E: They start with "Guy wants revenge for blah." and make it into "Guy wants revenge for blah. Slightly before blah happens you are introduced to game controls. This includes doing _____ because_____ Blah is caused by So and so who looks something along the lines of >.> an sounds like RAWR!....etc

The designers also are expected to know a decent amount about what is required of each team, they should know coding and what is involved in making sounds and making your objects move by animation, right? This is my view on what game designers do and exactly why I have wanted to become one.

Right now I'm working on a project with a friend who is leagues ahead of me. His focus is programing and I believe he specifically wants to focus on AI. While this has been my dream for years I only recently started getting an idea of how much I need to learn(this only gets me more excited and impatient to learn more) and how ahead of me my friend has gotten by doing simple projects and trial and error. I came to this site and trolled for a bit (hold on the point is coming up I swear!) and this topic seemed like the perfect place to ask for help.

Now I probably should have just made a new topic but it felt out of place. So if anyone would be willing to help give me a shove in the right direction of what I can do to catch up to my friend and answer a few questions that are most likely seen as silly to most (Such as: is my phobia of idea theft moronic or should I really hold onto it like a secret until it is almost a completed project?) I'd really appreciate it if we could talk over aim or something similar so I can ask questions as they flow into my mind. I feel like i'm pointed in the right direction but the idea of me leading teams(even if the teams consist of 1 person each) end in the teams laughing at me due to my lack of know-how amongst other things.

Share this post


Link to post
Share on other sites
writing up a few games with python and say pygame would be a great idea. its such a clean little setup for developing games. you would gain tons of experience just fooling around with it.

Share this post


Link to post
Share on other sites
"myf" wrote:

>The designers also are expected to know a decent amount about what is required of each team, they should know coding and what is involved in making sounds and making your objects move by animation, right?

A designer should have an idea of how those other staff members work, but he doesn't have to be able to do their jobs in their place. It would be awesome if he could, but most folks aren't that multi-skilled. That said, if you could do at least one of those tasks, you'd have more value for the team than merely that of idea guy.

>is my phobia of idea theft moronic

Yes. Your ideas are surprisingly valueless and untheftworthy.

>the idea of me leading teams(even if the teams consist of 1 person each) end in the teams laughing at me

Which is why you need to work your way slowly, patiently, and diligently into that position of trust. Read:
http://www.sloperama.com/advice/lesson7.htm
http://www.sloperama.com/advice/lesson14.htm
http://www.sloperama.com/advice/idea.htm
http://www.sloperama.com/advice/lesson10.htm
http://www.sloperama.com/advice/lesson47.htm

Your buddy is doing it right. He tries doing stuff, rather than stymieing himself into inaction with fears, doubts, and paranoia.

Share this post


Link to post
Share on other sites
Quote:
Original post by Myforumnamewastaken I feel like i'm pointed in the right direction but the idea of me leading teams(even if the teams consist of 1 person each) end in the teams laughing at me due to my lack of know-how amongst other things.


I think there's a common misconception that designers "make the game", and hence are in charge. As far as I'm aware designers work alongside artists and programmers, and have no authority over them. I think part of this stems from the "My Idea -> My Game" mentality.

If you're not the producer (sitting above tech, art, and design directors), and you're not bankrolling the game, you don't really have any authority.

I've seen a few projects ruined by megalomaniac designers being completley inflexible and demanding that programmers and artists do what the designer wants.

Share this post


Link to post
Share on other sites
Quote:
Original post by Tom Sloper
"is my phobia of idea theft moronic"

Yes. Your ideas are unsurprisingly valueless and untheftworthy.


There is very little value in an idea without the ability to back it up with realization. I fixed this quote, but great post Tom.

Share this post


Link to post
Share on other sites
Quote:
Original post by M2tM
Quote:
Original post by Tom Sloper
"is my phobia of idea theft moronic"

Yes. Your ideas are unsurprisingly valueless and untheftworthy.


There is very little value in an idea without the ability to back it up with realization. I fixed this quote, but great post Tom.


Unsurprising to you; surprising to many of the people who are worried about it. :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Zahlman
Quote:
Original post by M2tM
Quote:
Original post by Tom Sloper
"is my phobia of idea theft moronic"

Yes. Your ideas are unsurprisingly valueless and untheftworthy.


There is very little value in an idea without the ability to back it up with realization. I fixed this quote, but great post Tom.


Unsurprising to you; surprising to many of the people who are worried about it. :)


Haha, so true. Everything's relative I suppose. ;)

Share this post


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

  • Advertisement