Talk:How to get started

From DmWiki

Note: Creation of 3D meshes and texture is not a programmer job, unless you are a hobbyist, you might want to rethink this part, do you mean creating loaders for quake/doom level and meshes? --Daniel MD 21:51, 7 Jul 2005 (CDT)

Note: This is a 'how to get started with Game Development' guide, not a how to step into a 100% coding job with no experience in any for of 3d objects or textures. How can you code 3d if you do not create and under stand 3d objects. --FearTec 22:50, 7 Jul 2005

Note : There is talk page for these discussions and they shouldn't go into the actual page :) I think getting a bit of oil between your fingers by actually creating a bit of content is essential --Anubis 05:41, 8 Jul 2005 (CDT)

OK I am new to wiki so sorry about that,
Look I don't disagree with you, but a do it all project is a hobbyist project, if you are going to :take a job in even a small indie companies as the lead programmer or engine programmer you are not :going to be developing content.
So maybe it would be better to come up with two paths for game dev the hobbyst/indie and the :professional path.
I will work on that--Daniel MD 09:42, 8 Jul 2005 (CDT)
Even a professional games programmer should have some (small) experience in creating models and textures. This is just good as it allows him to understand things from the artists' point of view. Programmers, not artists, are responsible for taking what the artists create and assembling it into the actual game, so I think this is essential. Reedbeta 11:01, 8 Jul 2005 (CDT)
I'm with Reedbeta here. As an example : Many people working at Id said that one reason why John Carmack is actually a good programmer (for ::real... not because some kiddo said so) is that he writes software with his content creators in mind. Apparently
many people can come up with some fancy algorithm but it takes experience to design your technology in a way that is comfortable for
people who might not have your background on things. This kind of epxerience can only be gained if you actually know what an artist is doing
and _how_ he is doing it. Btw, there was a discussion on procedural techinques in the forum the other day... so content creation isn't
limited to working with 3DMax but can also mean : Get something good looking on the screen. --Anubis 11:25, 8 Jul 2005 (CDT)

Another comment on this page is that it contains some instances of what i called "personalized entries" over in the forum. It would be cool if we could remove much of the first person speach from this and other entries. --Anubis 11:25, 8 Jul 2005 (CDT)


You are getting me way wrong, or maybe i am missing the purpose of the getting started page... of course that any good programmer should have experience in developing and understanding 3D packages, like 3DS MAX, Maya, etc... and the file formats they output, heck he might even have to develop plug-ins for these packages.

From my point of view this page is for people that want to learn how to program a whole game by themselves so maybe we could establish some paths like:

Engine programmers:

  1. Learn C++
  2. Learn doing your own 3D functions (3D math)
  3. Learn D3D or OpenGL or any helper library (D3DX)
  4. Learn Loader formats (Quake3, Doom3, etc...)

etc...

Tools programmer:

  1. Learn C++
  2. Learn a 3D package (3ds MAX, Maya, etc)
  3. Learn a 3D package API (MAXscript, MEL, etc...)
  4. Create a Level Editor
  5. Create a Shader Editor

etc...

Texture Artist:

  1. Learn photoshop
  2. Learn 3D package
  3. Learn BodyPaint 3D

etc...

3D artist:

  1. Learn 3D package
  2. Learn Photoshop
  3. Learn zBrush
  4. Talk to the Engine programmer to learn polygon Budget

etc... This is just an illustrative point, not a finished list.

I think the way you are doing stuff is to much mixing, sooner or later you are going to have to specialize or admit that you are doing it all (Indie style/Hobbyist), and even then it is nice to have a structure of the steps by step tools/skills that are necessary to go to the next level.

There can be teams of only one, and in that case he will have to be the artist, programmer, handy men, but there are also indie teams of 2-4-8-12 people and in that case you have defined roles on the team.--Daniel MD 12:05, 8 Jul 2005 (CDT)


This article is getting pretty long. It seems to me it might be a bit much to ask beginners to digest all at once. Maybe we should think about trying to wittle down the content here to its very essentials, and/or moving some out to separate articles. Reedbeta 10:35, 14 Jul 2005 (CDT)

I agree completely. Let's just help them work out what they need to learn and send them the right way Ed Mack 11:37, 14 Jul 2005 (CDT)

I say it should b divided. "How to get started should with..." should probably be a category and inside we can have programming, 3d modeling, concept artist, sound effects, etc... bladder 20:34, 14 Jul 2005 (CDT)
Or, take out the "differnet paths topic" and change this one to how to get started with programming, because that what it was originally written for, I should've chosen a different title when submitting it to the wiki. bladder 20:34, 14 Jul 2005 (CDT)
I like the idea of making this a category and having different articles for the different areas. Additionally, the sections "Ones and Zeros" and "Communicating with the Computer" can probably be cut down to a single paragraph each, it's really not necessary to have so much detail here (we can point people to programming tutorials/books that will teach them this stuff). Reedbeta 20:38, 14 Jul 2005 (CDT)

I have re-written this page as I see fit. It now follows my flow of helping them find a language to learn (focusing on what is handy for them), helping them get setup and then helping them to learn about it all. Any comments? BTW, I moved the pascal advocacy stuff to a pascal page Ed Mack

DevMaster navigation