Skip to main content

Game Designer : Understanding Programming.

Submitted by Caroo on
Forum

G?day guys. Well I?m currently in the process of making a game design document and folio to get into the game industry. However I come from a more artistic background.

To be a better game designer I think its right that I at least read up on the concept of programming. Basically I want to understand what you guys do.. Even if only to the basic level. Some knowledge is better then no knowledge.

So.. What books could anyone recommend to me for me to read up on? I?m looking for A book that is both relevant to game programming and is understandable by someone who doesn?t have any previous knowledge of programming. It doesn?t have to be in-depth though.

I?m sceptical on wether a book like this even exists. But it can?t hurt to ask.

(( I?m guessing what I?m looking for is a basic book on C++ and direct X ))

Submitted by Jacana on Wed, 29/06/05 - 5:58 PM Permalink

When you say simple I think Idiots Guide to C++, when you say in-depth I think C++ Primer Plus. And those books may give you an idea of what programming is but they still will not give you an idea of what games programming is. I think you are looking for two very different things when you say you want a book that is in-depth but can be understood by a non-programmer.

Maybe you could clarify what it is you want to know about what programmers do.

Submitted by Caroo on Wed, 29/06/05 - 7:32 PM Permalink

Maybe you could clarify what it is you want to know about what programmers do.
[/quote]

Basically what a designer needs to know. The limitations and constraints that he has to work with to make his game design feasible to produce. Making a game idea is easy. Making a game idea that can be feasibly made with the technology you have available is a more complicated matter.

So I?m more or less looking for content that will teach me the limitations of programming.

I?m only guessing.. But I think that encompasses current game engines and the such.

I know this all sounds contradictive. But it could be worse. I could be sticking my head in the sand on the topic of programming.

Submitted by Leto on Tue, 05/07/05 - 7:53 PM Permalink

See the real difficulty with your query is that I really can't concieve of a way to be taught the limitations of programming. It has taken a few years of experience in the real world to gain any sort of intuition in that regard. And what you can and can't do with todays technology might be overcome by a major breakthrough tomorrow.

I would suggest you go ahead and document your concept from beginning to end anyway, without thought to what you might and might not be able to do. That way the vision in your head is clear and you'll find it much easier to answer questions about it. Then talk to some people, whose technical expertise you trust, about your ideas to see how feasible they are.

Don't expect that the first draft of your design document will be the final one. Expect that you'll have to revise it several times before it's in a state where it can be turned into a real game.

Submitted by mcdrewski on Tue, 05/07/05 - 8:34 PM Permalink

By far - the biggest limitation of programming is in getting hazy requirements.

Basically, you need to explain what you want. If you say "auto-following camera", you need to explain how you want it to work if there's an enemy behind and one ahead. what if the camera's behind a tree? what if it's inside a secret room behind a wall?

Think about what you want in detail and your team can tell you which bits aren't possible. Think in hazy terms and your team may make something that's either not very good (but easy to write) or not what you want (and waste time).

Submitted by Caroo on Wed, 06/07/05 - 2:14 AM Permalink

Leto and Mcdrewski:

Thanks for your replys. that helps a good deal. so better to drill forward in the design (and to explain in detail) and to let you programmers tell me what i can and can't do rather then myself telling me so.

One last thing. Your a programmer right and a designer is talking to you, trying to communicate ideas. If given the chance. would you like the designer to have knowledge of all the programming terms and jargon. And if so. Be pacific. (like C++ or visual basic )

I ask these questions becouse i want to be able to communicate best with programmers and basicly all people in a stuido team. i beleave correct and clear communication is the vital part of any project or business.

Submitted by rezn0r on Wed, 06/07/05 - 3:27 AM Permalink

Most game designers I know usually program in scripting languages such as python or lua. This can also be handy to use as a "testbed" to trial their ideas in simple form. Pretty handy.

Scott.

Submitted by mcdrewski on Wed, 06/07/05 - 5:19 AM Permalink

I'd prefer that a designer could program a little bit, or had programmed a little bit, but if not I wouldn't expect them to use the terminology appropriately. ie: If you can't program, don't try to "talk the talk" or it'll probably just confuse things.

Secondly - and this is overly picky on my part, so please no offense meant - if you're looking for excellent communication, then spend a bit of time on your English skills. Your QA department, and your publishers will love you for it. Learn which "your/you're" to use. Learn that the word 'Pacific' refers to an ocean, whereas 'specific' means to be prcise. Spell 'replies', 'because', 'believe', 'basically'...

Disclaimer : I'm a programmer, but I'm working in QA at the moment.

Submitted by Daemin on Wed, 06/07/05 - 8:08 PM Permalink

For the most part I agree with what the others have said above me. You can't get to know the other side of the fence that quickly, however using simple languages, python, lua, ruby (I'd recommend it) would give you a neat little foundation in programming. Plus if need be you could tell your programmers to add one of those scripting engines to the game and do some of the work yourself.

As far as books go I would suggest reading the free Ruby book online (you'll find links to it), and reading through a copy of "Game Architecture and Design" wouldn't hurt. For an artists I would try to stay away from the C++ books because you'll either read a very basic book designed for absolute beginners and then you'll sound like one, or you'll be bored stiff with one of the more advanced books.

Also take a look at BlitzBasic (Blitz Max), a few people have recommended it as a great prototyping tool, and since it's basic an artist, or designer should be able to pick it up and create simple prototypes with ease.

Submitted by Caroo on Wed, 06/07/05 - 8:44 PM Permalink

quote:Originally posted by mcdrewski


Secondly - and this is overly picky on my part, so please no offense meant - if you're looking for excellent communication, then spend a bit of time on your English skills. Your QA department, and your publishers will love you for it. Learn which "your/you're" to use. Learn that the word 'Pacific' refers to an ocean, whereas 'specific' means to be prcise. Spell 'replies', 'because', 'believe', 'basically'...

Disclaimer : I'm a programmer, but I'm working in QA at the moment.

It's not overly picky really. And it's quite true my grammar and spelling is indeed shitty. Now like the rest of the world you would say, "Then just fix it and get better at it" ... And I really wish it were that simple.

You know how there's always one thing in your life that no matter how much you try at it you can only improve at a very slow rate if any at all. For me its grammar and spelling.. Which is quite ironic because dozens of people have told me that I?m quite a good story/screenplay writer. And without trying to boost I myself know that I am.

It?s just one of those things. I guarantee you it's not due to laziness. I took through my posts twice over before posting it and still people can find mistakes.

So yep. It is my undoing so to speak. Half the reason why I draw. So I can express my ideas in other forms.

If I didn?t have that.. I wouldn?t expect for anyone to hire me.

[img]icon_paperclip.gif[/img] Download Attachment: [url="http://www.sumea.com.au/forum/attached/caroo/200575212051_artefact.jpg"]artefact.jpg[/url]
118.23 KB

[img]icon_paperclip.gif[/img] Download Attachment: [url="http://www.sumea.com.au/forum/attached/caroo/200575204220_thebigboss.jpg"]thebigboss.jpg[/url]
124.11?KB

Thats my drawing of the final boss that you have to fight in my concept. it's all in the game design document I'm writing. Im so far upto 40 pages.

Submitted by Caroo on Wed, 06/07/05 - 8:47 PM Permalink

Daemin:

Thank you very much. i'll look into those right away.

Submitted by Jacana on Thu, 07/07/05 - 4:05 AM Permalink

Just a note - spelling can be fixed by spell check. There is little reason for written documents or communication to be incorrect.

Just to add to what Leto said about programming - I have heard people say that as a designer you are not suppose to worry about the limitations of the teams around you. You are suppose to worry about the limitations of your own imagination. If you can dream something up more then likely an artist or programmer can find a way to make it work.

Submitted by Kalescent on Thu, 07/07/05 - 7:13 AM Permalink

What Jacana says about not thinking about the limitations of the team around you is bang on. Its exactly the way i would encourage a gun designer to approach things.
Leave the programming and art to the artists and coders, although some basic understanding would help in expressing your idea - but only as far as in that you could present the problem clearly through meetings and discussion and via your documentation.

A rule would be not to imply formulas or methods of working out a problem. You supply the vision let the professionals in each respective areas provide the feedback on whether or not its feasible or not. Its really all about having the ability to rely and use the power of others in the best way you can.

Submitted by Daemin on Thu, 07/07/05 - 7:36 PM Permalink

HararD, Jacana: It's more so he'd be able to better express his ideas and concept to programmers than to understand what limitations are present in his designs. If the programmers can understand him better because he can speak their langauge then they are more likely to implement what he was envisaging initially.

Submitted by Caroo on Thu, 07/07/05 - 8:00 PM Permalink

Daemin: Bingo mate. Couldn?t say it better myself.

Programmers have spent the time to sit down and learn these complex programs. They have my respect and I trust in there ability.

Artists have slaved away at their work until they finally reached that ever-intangible industry standard. They also have my respect.

I don?t want to know these things to limit myself.. I want to know these things to better communicate and become more versatile to the studio, therefore pulling my fair weight and being the best I can be.

With the want to become a creative and respected designer you kinda want that skill.

Posted by Caroo on
Forum

G?day guys. Well I?m currently in the process of making a game design document and folio to get into the game industry. However I come from a more artistic background.

To be a better game designer I think its right that I at least read up on the concept of programming. Basically I want to understand what you guys do.. Even if only to the basic level. Some knowledge is better then no knowledge.

So.. What books could anyone recommend to me for me to read up on? I?m looking for A book that is both relevant to game programming and is understandable by someone who doesn?t have any previous knowledge of programming. It doesn?t have to be in-depth though.

I?m sceptical on wether a book like this even exists. But it can?t hurt to ask.

(( I?m guessing what I?m looking for is a basic book on C++ and direct X ))


Submitted by Jacana on Wed, 29/06/05 - 5:58 PM Permalink

When you say simple I think Idiots Guide to C++, when you say in-depth I think C++ Primer Plus. And those books may give you an idea of what programming is but they still will not give you an idea of what games programming is. I think you are looking for two very different things when you say you want a book that is in-depth but can be understood by a non-programmer.

Maybe you could clarify what it is you want to know about what programmers do.

Submitted by Caroo on Wed, 29/06/05 - 7:32 PM Permalink

Maybe you could clarify what it is you want to know about what programmers do.
[/quote]

Basically what a designer needs to know. The limitations and constraints that he has to work with to make his game design feasible to produce. Making a game idea is easy. Making a game idea that can be feasibly made with the technology you have available is a more complicated matter.

So I?m more or less looking for content that will teach me the limitations of programming.

I?m only guessing.. But I think that encompasses current game engines and the such.

I know this all sounds contradictive. But it could be worse. I could be sticking my head in the sand on the topic of programming.

Submitted by Leto on Tue, 05/07/05 - 7:53 PM Permalink

See the real difficulty with your query is that I really can't concieve of a way to be taught the limitations of programming. It has taken a few years of experience in the real world to gain any sort of intuition in that regard. And what you can and can't do with todays technology might be overcome by a major breakthrough tomorrow.

I would suggest you go ahead and document your concept from beginning to end anyway, without thought to what you might and might not be able to do. That way the vision in your head is clear and you'll find it much easier to answer questions about it. Then talk to some people, whose technical expertise you trust, about your ideas to see how feasible they are.

Don't expect that the first draft of your design document will be the final one. Expect that you'll have to revise it several times before it's in a state where it can be turned into a real game.

Submitted by mcdrewski on Tue, 05/07/05 - 8:34 PM Permalink

By far - the biggest limitation of programming is in getting hazy requirements.

Basically, you need to explain what you want. If you say "auto-following camera", you need to explain how you want it to work if there's an enemy behind and one ahead. what if the camera's behind a tree? what if it's inside a secret room behind a wall?

Think about what you want in detail and your team can tell you which bits aren't possible. Think in hazy terms and your team may make something that's either not very good (but easy to write) or not what you want (and waste time).

Submitted by Caroo on Wed, 06/07/05 - 2:14 AM Permalink

Leto and Mcdrewski:

Thanks for your replys. that helps a good deal. so better to drill forward in the design (and to explain in detail) and to let you programmers tell me what i can and can't do rather then myself telling me so.

One last thing. Your a programmer right and a designer is talking to you, trying to communicate ideas. If given the chance. would you like the designer to have knowledge of all the programming terms and jargon. And if so. Be pacific. (like C++ or visual basic )

I ask these questions becouse i want to be able to communicate best with programmers and basicly all people in a stuido team. i beleave correct and clear communication is the vital part of any project or business.

Submitted by rezn0r on Wed, 06/07/05 - 3:27 AM Permalink

Most game designers I know usually program in scripting languages such as python or lua. This can also be handy to use as a "testbed" to trial their ideas in simple form. Pretty handy.

Scott.

Submitted by mcdrewski on Wed, 06/07/05 - 5:19 AM Permalink

I'd prefer that a designer could program a little bit, or had programmed a little bit, but if not I wouldn't expect them to use the terminology appropriately. ie: If you can't program, don't try to "talk the talk" or it'll probably just confuse things.

Secondly - and this is overly picky on my part, so please no offense meant - if you're looking for excellent communication, then spend a bit of time on your English skills. Your QA department, and your publishers will love you for it. Learn which "your/you're" to use. Learn that the word 'Pacific' refers to an ocean, whereas 'specific' means to be prcise. Spell 'replies', 'because', 'believe', 'basically'...

Disclaimer : I'm a programmer, but I'm working in QA at the moment.

Submitted by Daemin on Wed, 06/07/05 - 8:08 PM Permalink

For the most part I agree with what the others have said above me. You can't get to know the other side of the fence that quickly, however using simple languages, python, lua, ruby (I'd recommend it) would give you a neat little foundation in programming. Plus if need be you could tell your programmers to add one of those scripting engines to the game and do some of the work yourself.

As far as books go I would suggest reading the free Ruby book online (you'll find links to it), and reading through a copy of "Game Architecture and Design" wouldn't hurt. For an artists I would try to stay away from the C++ books because you'll either read a very basic book designed for absolute beginners and then you'll sound like one, or you'll be bored stiff with one of the more advanced books.

Also take a look at BlitzBasic (Blitz Max), a few people have recommended it as a great prototyping tool, and since it's basic an artist, or designer should be able to pick it up and create simple prototypes with ease.

Submitted by Caroo on Wed, 06/07/05 - 8:44 PM Permalink

quote:Originally posted by mcdrewski


Secondly - and this is overly picky on my part, so please no offense meant - if you're looking for excellent communication, then spend a bit of time on your English skills. Your QA department, and your publishers will love you for it. Learn which "your/you're" to use. Learn that the word 'Pacific' refers to an ocean, whereas 'specific' means to be prcise. Spell 'replies', 'because', 'believe', 'basically'...

Disclaimer : I'm a programmer, but I'm working in QA at the moment.

It's not overly picky really. And it's quite true my grammar and spelling is indeed shitty. Now like the rest of the world you would say, "Then just fix it and get better at it" ... And I really wish it were that simple.

You know how there's always one thing in your life that no matter how much you try at it you can only improve at a very slow rate if any at all. For me its grammar and spelling.. Which is quite ironic because dozens of people have told me that I?m quite a good story/screenplay writer. And without trying to boost I myself know that I am.

It?s just one of those things. I guarantee you it's not due to laziness. I took through my posts twice over before posting it and still people can find mistakes.

So yep. It is my undoing so to speak. Half the reason why I draw. So I can express my ideas in other forms.

If I didn?t have that.. I wouldn?t expect for anyone to hire me.

[img]icon_paperclip.gif[/img] Download Attachment: [url="http://www.sumea.com.au/forum/attached/caroo/200575212051_artefact.jpg"]artefact.jpg[/url]
118.23 KB

[img]icon_paperclip.gif[/img] Download Attachment: [url="http://www.sumea.com.au/forum/attached/caroo/200575204220_thebigboss.jpg"]thebigboss.jpg[/url]
124.11?KB

Thats my drawing of the final boss that you have to fight in my concept. it's all in the game design document I'm writing. Im so far upto 40 pages.

Submitted by Caroo on Wed, 06/07/05 - 8:47 PM Permalink

Daemin:

Thank you very much. i'll look into those right away.

Submitted by Jacana on Thu, 07/07/05 - 4:05 AM Permalink

Just a note - spelling can be fixed by spell check. There is little reason for written documents or communication to be incorrect.

Just to add to what Leto said about programming - I have heard people say that as a designer you are not suppose to worry about the limitations of the teams around you. You are suppose to worry about the limitations of your own imagination. If you can dream something up more then likely an artist or programmer can find a way to make it work.

Submitted by Kalescent on Thu, 07/07/05 - 7:13 AM Permalink

What Jacana says about not thinking about the limitations of the team around you is bang on. Its exactly the way i would encourage a gun designer to approach things.
Leave the programming and art to the artists and coders, although some basic understanding would help in expressing your idea - but only as far as in that you could present the problem clearly through meetings and discussion and via your documentation.

A rule would be not to imply formulas or methods of working out a problem. You supply the vision let the professionals in each respective areas provide the feedback on whether or not its feasible or not. Its really all about having the ability to rely and use the power of others in the best way you can.

Submitted by Daemin on Thu, 07/07/05 - 7:36 PM Permalink

HararD, Jacana: It's more so he'd be able to better express his ideas and concept to programmers than to understand what limitations are present in his designs. If the programmers can understand him better because he can speak their langauge then they are more likely to implement what he was envisaging initially.

Submitted by Caroo on Thu, 07/07/05 - 8:00 PM Permalink

Daemin: Bingo mate. Couldn?t say it better myself.

Programmers have spent the time to sit down and learn these complex programs. They have my respect and I trust in there ability.

Artists have slaved away at their work until they finally reached that ever-intangible industry standard. They also have my respect.

I don?t want to know these things to limit myself.. I want to know these things to better communicate and become more versatile to the studio, therefore pulling my fair weight and being the best I can be.

With the want to become a creative and respected designer you kinda want that skill.