| Game Design: A Practical Approach | |
| author | Paul Schuytema |
| pages | 416 |
| publisher | Charles River Media |
| rating | 6 |
| reviewer | Michael Fiegel |
| ISBN | 978-1-58450-471-9 |
| summary | A practical, often code-heavy guide to game design |
All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2010 Geeknet, Inc.
I never RTFB! (Score:5, Funny)
(...) may find themselves skipping over swaths of text instead of actually reading it.
It should appeal a lot to slashdotters then ;-)
Re: (Score:2)
As long as the book gives me some mod points before I start skimming it, I'm good to go.
Next up: (Score:3, Funny)
Re:Next up: (Score:5, Funny)
Having fun: The methodical way.
Translated from the original German.
Parent
Best Game Design Advice (Score:3, Insightful)
"Make Games, Not Product."
It is a subtle and deepy philisophical statement. Doom 3 was a product, a game engine to be specific. Same with Unreal 2. Both were lousy games.
Technologically they were impressive yes, but a game, not so much.
You have to go in making a GAME. That will shape the entire development process versus going into it as a product otherwise the video game industry will burn itself out just like the movie industry... wait... shit.. We complain about how remakes and sequels in movies but video games? Lets make another ZELDA... crap.. too late...
Everyone should make 2 games (Score:5, Insightful)
Everyone taking programming should learn to program two specific games in the course of their curriculum:
TETRIS (Collision detection, input , output, real time game loop, sound, etc.. 2D collision)
Multiplayer FPS Clone (3D programming, basic modelling, networking, latency management, using established middleware, map design)
That will teach those kids that said, "When am I ever going to use Linear Algebra in real life!"
Whippersnappers...
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
True everyone should also have to take a crack at path finding at least once. That and the Travelling Salesman algo.
Re: (Score:2)
What would you recommend instead? I am really looking for suggestions so once I finish my tetris clone I can move on to something else, but I think a multiplayer fps clone might be a few steps too far.
Re: (Score:2)
Grab the Quake 1 engine from ID. Just make a regular square map with some obsticals (think a paint ball court.)
There is enough documentation on the internet to get started. Another option is the DarkBASIC set that also helps work through a 3D FPS.
Don't worry about artistic quality, you are looking at technical implementation.
Re: (Score:2)
Re: (Score:2)
YOu can grab the quake 1 engine from ID software and get a basic FPS game up in about 5 hours solo. This is suggested as an excercise in using middleware, not coding a game engine from scratch.
Quotes (Score:2)
Re: (Score:2)
<q> had naught to do with it.
Re: (Score:2)
Just screwy /. CSS or something then? It seems to be displaying fine now.
Nice review anyway - although I'm still trying to work out what the "catlike typing" sentence means. :)
Re:Catlike Typing (Score:2)
http://www.bitboost.com/pawsense/pawsense-faq.html [bitboost.com]
WHY? (Score:2)
Re: (Score:2)
As I mention in the review, I think the book is still relevant since Lua is still relevant. As not many other design books (that I am aware of) are Lua-focused like this, that might be a selling point for some people.
Re:Why there is so much emphasis on design (Score:5, Insightful)
Correction. Mediocre programmers are a dime a dozen. Any comp sci grad with a 6pack of coke can get through directX 9 tutorials and have a decent floating ball, swimming shark. Good/Great programmers are a rarity indeed, and good games ALWAYS have a good programmer behind them. No lag in input, decent framerate, no odd bugs. Yeah, they deserve their paycheque.
Parent
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
John Carmack!
Carmark can design a great game engine. But it's been a while since iD has released a great game.
Re: (Score:2)
It's been a while since ID released ANY game.
Re: (Score:2)
Re: (Score:2, Interesting)
In my work, I disagree (Score:5, Insightful)
In my work as a programmer, I often have to fill in huge gaps left by the designers, and the designers usually only get the best ideas after they have seen what the engine can do.
Also, the specification of the average designer is so vague in terms of programming, e.g. "I want the program to be smarter than the user" that it is worthless.
Because of this any fulltime designer is usually in the top 5% of his craft, while a fulltime programmer still can be useful if he isn't in the top 5%.
Parent
Re: (Score:3, Insightful)
Programming and design are still distinct. When filling in blanks left by designers, you are doing design. When you are shaping what the engine will accommodate, you are also doing design. When you implement the design in code, you are "programming" (in the "ten-cent coding" sense of the word).
I think that in the real world, most "programmers" must be coders and designers, whereas designers need not be coders. That said, a good designer is probably worth more between the two, since the quality of design
Re: (Score:3, Funny)
Agreed, they used to try to teach us that at the University.
The example was an early fly-by-wire plane that failed to apply brakes while landing because the tarmac was flooded with water.
Specs said that the brakes couldn't be applied until the airplane touches the ground which it never did because it was only touching the water and the programmers implemented the specs as is.
They tried to teach us that programmers have a responsibility to review the specs and mention anything that did not make sense ! ;-)
Re: (Score:3, Insightful)
Maybe I'm being way to literal, but how do the brakes know the difference between cement and water that feels like cement at hundreds of MPH?
Re: (Score:3, Insightful)
Maybe I'm being way to literal, but how do the brakes know the difference between cement and water that feels like cement at hundreds of MPH?
Grats, you just passed the test of "programmers have a responsibility to .... mention anything that did not make sense"
Re: (Score:3, Informative)
Good point, I just talked to my aviation expert and he recalls that incident but we haven't found any links to provide you with. This occurred a long time ago.
My experts says he thinks it wasn't a fly-by-wire system, it was the first tests ran on a prototype equipped with computer assisted ABS brakes and the prototype failed to break at all on landing. He said he thinks the airplane was built by Hawker Siddeley.
Anybody that can provide a link to this is welcomed. I do recall the teacher in school telling th
Re: (Score:2)
Coefficient of Friction?
Re: (Score:2)
"In my work as a programmer, I often have to fill in huge gaps left by the designers, and the designers usually only get the best ideas after they have seen what the engine can do."
But this is more about technology getting in the way of the design and the fact that game design itself is comparitively young, compared to say architecture.
I agree that understanding programming and coding definitely helps a game designer, no doubt about it. The same way that understanding coding and shaders helps artists.
The
Re: (Score:2)
The programmers are just the construction workers who make the design a reality. Both are skilled and necessary, but construction workers without an architect aren't going to build anything of great value.
Good analogy.
Re:Why there is so much emphasis on design (Score:5, Insightful)
> Programmers are a dime a dozen. That ain't nothing but ten-cent coding.
Oh please. Ideas are dime a dozen too. Your great idea means jack shit if it isn't implemented.
_Great_ Programmers, and _Great_ Designers, are much, much rarer.
I'm not sure how many years of game programming you have (sounds like you don't have much), but you are ignoring important pieces of game development:
* An architect who is illiterate of the materials used to build the building, will spec something that can't be built. Designers tend to ignore run-time costs because they don't understand the technical reasons why you can't implement their "grand idea." Good AI is not computational cheap.
* Often times, design "hand waves" how systems will work, because they can't be bothered with the actual nitty-gritty details. The devil is in the (implementation) details.
* More and more game designers are doing programming via scripting. Designers for the most part, are clueless about writing _good_ code (due to inexperience), and heaven help the programmer who has to debug their scripts. In the ideal world a designer would work _together_ with a programmer so that BOTH may learn each other's craft.
> the implementation can be farmed off to any body shop.
Uhm, no.
Some things look great on paper, but in practice, are bad ideas.
Sometimes a great execution, will make an OK idea, be good !
I would seriously consider learning more about design and programming before spouting off.
Parent
Re: (Score:3, Insightful)
And an architect without construction workers is nothing but a second-rate sketch artist who draws only (imaginary) buildings.
Re:Why there is so much emphasis on design (Score:4, Interesting)
Actually getting a building built is way more complicated than either of those two statements. Any complicated building most likely has a good sized team of people working on it. Besides just deciding what the building is going to look like, the architect(s) on the project need to coordinate all of the engineers and consultants (mechanical, structural, landscape, etc.), deal with lots of code/government issues, keep the project within a workable budget, and then make sure the contractor actually builds what was designed.
Sadly, the way the construction business often works (in the US at least), the relationship between the the contractor and the architect/client is often adversarial, because there are lots of clients who want their building to be built basically for free, and lots of contractors looking trying to squeeze every dollar out of the client.
But on occasion I've worked on projects where the contractor is involved from the beginning and generally acting in good faith, and there's a real partnership at work. Those projects are usually much more fun.
I don't remember what my point was. Make sure your kid never decides to be an architect.
Parent
Re: (Score:3, Insightful)
Programmers are a dime a dozen. That ain't nothing but ten-cent coding.
Designers, though, are the core of any game.
I used to work writing video games, and still do some coding in the CustomTF mod.
We had an expression: anyone can design a game. The hard part is implementing it, and implementing it well.
Look at the open source community for proof.
Three times this year so far, I've had people approach me with an idea for a game, but didn't bring anything to the table themselves. Though to be fair one was a CS
Re: (Score:2)
Although, to be fair, there are certain principles of game design that are crucial for success.
For me, the main ones are:
1) All options should be interesting. Some can be more powerful or less powerful, or situationally powerful, but no choice should dominate another, and all should be useable by someone familiar with the game. This applies if you're talking about writing the next Starcraft, or creating a P&P roleplaying supplement.
2) Players should be challenged. Players should not be crushed by diffic
Re: (Score:2)
I very much agree. Seems to me that one reason game developers integrate LUA is because game designers are at least as big hacks as the developers.
Re: (Score:2)
The lines between designer and programmer aren't so clear. Consider this anecdote.
One startup I worked for briefly had a design and even a reference implementation. Took them 18 months to get to that point. Their reference implementation was extremely slow, taking about 20 minutes on a small set of data and they wanted someone like me to improve it. As requested, I changed out all the C++ iostream library calls for C stdio library calls, which got the run time down to 12 minutes. That was their idea
Re: (Score:2)
Re: (Score:2)
I think that seriously understates the importance of the actual brains behind making something a reality. You can make this same point without denigrating the very people who actually wrote LUA.
Re:Why there is so much emphasis on design (Score:5, Insightful)
Programmers are a dime a dozen. That ain't nothing but ten-cent coding.
I feel a bit silly responding to obvious flamebait, but it's been modded insightful for some bizarre reason. As a professional game programmer, I feel the need to respond. A *professional* game developer understands and appreciates the values of his co-workers in ALL disciplines. There's no room for some stupid 'us' vs. 'them' mentality. I'm fortunate to work with some brilliant artists and designers. We programmers produce not only the game code, but also internal tools that are essentially "force multipliers" for them. In return, they use our code and tools and produce cool and amazing things we would never have thought of.
They are the ones who shape and craft the game, much like I.M. Pei designs masterful works of architecture. The programmers are just the construction workers who make the design a reality. Both are skilled and necessary, but construction workers without an architect aren't going to build anything of great value.
This is Slashdot. You need a car analogy.
You're claiming the steering wheel (designer) is the most important part of the car, because without it, we couldn't control the car (direct the game development). But there are so many vital systems to the car - removing any one of these components makes the car useless, so it's silly to argue which one is 'most important'. What good is the car without wheels? Without an engine? Or brakes, or a body? Even the more minor roles (headlights and tail lights) are critical for specific circumstances.
Yes, coding is necessary, and this book has plenty of code. But if you are serious about creating a game, it's the design that matters, the implementation can be farmed off to any body shop.
I wish you well with that approach. Unless you take ALL aspects of game development seriously, you're doomed to failure.
Parent
Re: (Score:2)
What an apt username.
Re: (Score:2)
I don't understand why the author calls the foundational elements of game design atoms... I mean.. logically, an atom in this context would imply the simplest, well-formed concepts of game design that cannot be broken down any further. Concepts like "UI, inventory, power-ups, puzzles, conflicts" are generally abstract and can most certainly be broken down or interpreted differently. So, if the author needs a catchy buzzword label to define the content elements of his book... why choose a word that has scientific, logical and mathematical meaning? Meaning that conflicts with the intended meaning this label is supposed to define.
I think it's a requirement of buzzword-labels that they either make no sense or dilute the meaning of the original word, or both.
Re: (Score:3, Interesting)
I don't understand why the author calls the foundational elements of game design atoms.
I think it's a requirement of buzzword-labels that they either make no sense or dilute the meaning of the original word, or both.
Book author is hot for Lua. Lua's data structures innards are kind of lisp list-ish and one funny part of the wikipedia article explains that in small part, they invented Lua because lisp's syntax is "too hard". Lisp lists are made of atoms. So, to summarize, author likes Lua, Lua's list innards are lispish, lisp lists are made of atoms.
The author probably couldn't help himself but to call the individual foundational elements of game design, atoms.
Re: (Score:2)
It's also useful if you want to patch or edit the game at runtime--this can really speed iterations.
But I agree that it can be overkill. Casual games I write often either lack a scripting language, or are entirely written in a scripting language. :-)
Re: (Score:2)
In more complex games, scripting can have the additional advantage that you don't need to recompile (or with good engines, even restart) the game when changing the script. That can be a huge timesaver.
Additionally, you can get in-game console parsing/execution (think Quake3) for free when you integrate your scripting engine with that.
Re: (Score:2)
I always found that with complex games, the number of scripts starts to grow, and then at some point I wish I had a script verifier to make sure I didn't make any typos. And then, I start hunting for ways to make the script faster. And then I realize that what I really want is a compiler that produces native code. Which then leads me to writing the logic in C++.
So, I don't see any advantage at all in not recompiling.