Starting in May I''ll be getting away from the basics of DirectX and hitting the RPG specific stuff. While the TOC is already laid out (which I''ll post info on the page soon), what kind of information would you like to see in the book? Jim Adams home.att.net/~rpgbook Programming Role-Playing Games with DirectX 8

What type of RPG? MMORPG, CRPG, Baldur''s Gate-like? Or do you have plans to cover each style. Considering they all have similiar data management this does not seem impossible but I think I would gain more from a book that focuses on one specific style.

Are you going to focus in on any languages that are especially useful in developing RPGs? I imagine you''ll talk a little about VC++, C++, C. Will you focus on the differences in languages as far as what''s required?

I would like to see a nice big section on Scripting engines.

-Will

Well, one thing an RPG book should have is how to store information - item locations or "what''s here" data, preferably so it doesn''t cause savegame files to become 30mbs. Also, how and when to store NPC/monster-related data and what to do with them when the player changes ''area''. How to handle companions. General data and status information management, etc.

If time permits, have a single program that you update for the entire lenght of the book.
You can still put small example programs throughout.

But at the end, the user will have a working demo, that should be quite impressive. (Not to mention, it will help sales!)

Almost no books seem to do this.

When adding a chapter on pathfinding, put it in the big demo.
When adding a chapter on invertory management, put it in the big demo.
When adding a chapter on NPC AI, put it in the big demo.
When adding a chapter on sprite animation/mesh animation, put it in the big demo.
When adding a chapter on combat, put it in the big demo.
Etc....

You don''t have to make a full blown game. But you will give the user''s a working skeleton of a game that they can flesh out.
That''s my 2 cents.

I totally agree with Gorky, one big demo at the end would seal the deal for me buying this book.

Not enough authours writing books about game programming seem to include a demo engine. It is almost as though they know the theory but have never attempted to actually implement what they are trying to teach. To me that screams cop-out

I understand that a fully fledged game is not possible due to time/money. Still, even a simple little rinky-dink program, that works and demonstrates the concepts throughout the book, is sufficient.

That is what I look for in a book and why I haven''t bought many "game programming" books. The "example engine" just is always missing...

Dire Wolf
direwolf@digitalfiends.com

Dire Wolf
www.digitalfiends.com

Yeah, include an (extensive!) chapter about scripting engines! And don''t put too much emphasis on graphics and stuff you can read in every Game-Programming book...make it really RPG-specific! (i.e. Data-structures, NPC-Handling, Event-Handling, ways to make a game non-linear, A.I. and such! )

I would like to see some fair degree of elaboration on how to organize an item heirarchy. A FPS might have eight weapons while an RPG might have a hundred. A good RPG doesn''t just stop with weapons and armour but also includes a large number of auxilary items that can be used in some manner. I think UO was a good example of that, but I suspect they used brute force to accomplish it. How you model a world is where I always get lost in a RPG. There seems to be plenty of books on how to model it graphically, but shortage of books dealing with how to bridge the gap between an item that sets there looking pretty and one that can be used realistically.

As for scripting I think it would be most useful to explain when to call a script and what access a script needs rather than specifics on how to embed and extend something like python. Embedding and extending it is actually the easy part though the part people seem to view with dread. It also seems that people often misunderstand the role a script plays in a game. They often seem to mistakenly think that the script is doing micro-management such as collision detection rather than a more macro level such as how a player interacts with the game. So some guidelines on how to decide what a script can do and what should be done by the code would seem helpful. Also how you give the script a situational awareness without forcing the script writer to make a thousand and one function calls to get the information they need to respond to an event.