BaShildy,

*sigh*

Just because players with no programming experience often propose overly grand concepts for games it doesn't mean they can't be guided to go along reasonable lines. That's what the teacher is there for, don't you think? I think it's far too easy to underestimate what people can do given the proper guidance and encouragement. Remember, the idea is not "design any game you like", but rather "how might we approach a game where the player ..."

[edited by - chronos on June 30, 2002 12:50:26 AM]

Always underestimate people. That way you wont be disappointed

But how will they realize its overly grand until they are the ones that have to implement it. I think the overly grand concept is created because they don''t understand the implementation phase of development. That''s why I think you can''t really understand your design, until you''ve developed one before.

Obviously theres a path from player to developer, and the guy who makes outrageous requested as a player could some day make games. I just think theres no quick path from game player to epic game designer. You can''t design games 2 steps above your development skills and expect them to work and be fun. I guess I''d rather have level designers and writers helping me with content over pure designers. I''m more into the team effort thing rather then 1 man''s vision. Anyone at any level can give suggestions, and sometimes they are really good.

quote:

---

Just because players with no programming experience often propose overly grand concepts for games it doesn''t mean they can''t be guided to go along reasonable lines. That''s what the teacher is there for, don''t you think?

---

Yeah, but they need to learn it on their own as well. I just don''t believe you can go from game player to designing RPG''s/FPS''s strictly by playing games and studying them. You have to be active in the development of lesser games to be able to work on greater games. With my class we started small, and we did some great stuff in 2 weeks. We focused purely on development, and we always gave praise to students who were succeeding. They can now go onto to better games, because we helped guide them at the early levels, and they now have experience in developing small games.



- Kevin "BaShildy" King
Game Programmer: DigiPen
www.mpogd.com

Nobody here is proposing that the kids design an RPG or any sort of "epic design". You seriously underestimate kids if you think they're incapable of coming up with some simple game mechanics. If they get too ambitious it's a simple matter of being honest with them and guiding them toward a less ambitious proposal.

[edited by - chronos on July 1, 2002 1:21:58 AM]

Oluseyi (offtopic):

Apologies for continuing this offtopic discussion, but I'd like a chance to respond to it.

quote:

---

Original post by Oluseyi
Theoretically, you could teach computer science on Babbage's difference engine. The real point of that statement is a lament of how many young people go into computer science because they are "into computers". Computer Science has to do with computing; it's basically applied math.

---

Going into computer science because you're into computers is no worse than going into music because you like playing the electric guitar. Sure, computer science is the science of computing, but it's also the science of computers, these being computing machines. Just ask yourself what the "science of computing" would be like without the existence of non-human computing machines and you immediately notice a relationship between the need to program computers and advances in computer science. Computers depend on algorithmic problem-solving more so than humans, humans being very effective at solving many kinds of problems without the need for a mechanical, algorithmic approach.

[edited by - chronos on July 1, 2002 3:15:30 AM]

quote:

---

Original post by BaShildy
No disagreement here. I also follow the same rule. I fully believe in having complete documentation before the coding starts. My point was that the game shifting away from the original "vision" is a good thing, and the documentation should stick with it. I''m against a designer who gets angry that the game is getting away from his vision, and supportive of a team who''s goal is to modify the game during development to make it as fun as possible.

---

OK, I get you now. I think you''re right, but only up to a point. Frankly, if the end product has changed much from the designer''s original "vision," you can''t have a terribly brilliant designer on your hands.

Keeping in touch with your audience is, of course, a form of market research. And that''s never bad.

quote:

---

I''m sorry, I don''t remember the discussion. Do you have a link? Hopefully what your refering to wasn''t during the end of my last project, in which I was exhausted and hated everything about games You gotta love the last few days before release.

---

http://www.gamedev.net/community/forums/topic.asp?topic_id=101650
The gist of it is that because we know what goes into games, we end up more interested in the techniques or design of the game, and not so much if it''s "fun."




Superpig
- saving pigs from untimely fates
- sleeps in a ham-mock at www.thebinaryrefinery.cjb.net

Funny how Miyamato makes some of the best games and never learned "game design theory" and he doesn''t program.

quote:

---

Original post by Mr Saturn
Funny how Miyamato makes some of the best games and never learned "game design theory" and he doesn''t program.

---

Exactly! Games aren''t limited to the computer. The computer is simply a delivery method. A tool, a medium.

If your lecture is limited to one session, I wouldn''t worry about implementation at all. There would be sketches and light documentation, but I wouldn''t worry about coding or building anything. Unless you plan to implement the game for them in your spare time or have them build it down the road.

quote:

---

superpig:
AP (the last one): you sure you''re not confusing design with implementation? I''m not going to a level where they''d have to deal with algorithms or code - it''ll be more the sort of level this forum reaches on a day when everyone feels apathetic.

---

Yes I was! I spend a lot of time programming and find myself stopping occasionally to enhance the design. The two start to blur together after a while. (The difference between a programmer and a coder?...Tweeking the design?)

Kudos for thinking through a lesson plan, superpig.

-James
"Set shields to apathy."

quote:

---

Original post by Mr Saturn
Funny how Miyamato makes some of the best games and never learned "game design theory" and he doesn''t program.

---

Imagine how much better he might have been if he had and did.

[offtopic]
chronos:
I''m quite enjoying the discussion. Unfortunately, it''s not sufficiently full-fledged to deserve a separate thread at this late stage, so we''ll just kindly ask the uninterested to ignore our tangent.

quote:

---

Original post by chronos
Going into computer science because you''re into computers is no worse than going into music because you like playing the electric guitar.

---

Agreed. Both are bad reasons, provided by "going into music" you mean "engaging in rigid academic study and training for years".

quote:

---

Sure, computer science is the science of computing, but it''s also the science of computers, these being computing machines. Just ask yourself what the "science of computing" would be like without the existence of non-human computing machines and you immediately notice a relationship between the need to program computers and advances in computer science.

---

The truth, as I see it, is that very little of computer science actually needs computers. Proper project design doesn''t need computers, though having a word processor would help. Proper code design (interaction, process flow, etc) doesn''t need computers either, though diagramming software like Visio would be useful here. Program analysis doesn''t need computers. Computers only come into the picture when it''s time to write or run (test, use) the applications, so the individual who doesn''t have an affinity for all the portions preceding this is already at a (self-inflicted) disadvantage.

There is no denying that computers are a necessary part of the advancement of computer science. I''m merely pointing out that computer science doesn''t revolve around them, especially given that the former predates the latter by several decades (though not necessarily with that name).