Writting a book on game development

[WILL]

Idigicon has great possibilities for publishing materials! In fact they use the same services they use for manuals and instructions for their own home-brand products made by the Coders Workshop.

Perhaps a deal can be struck to publish through them?

It's not a bad way to go...


As for your tracks and such, here is what I would personally recommend;

I'd just look at whatever text books or programming, etc books that you have on hand. Or maybe go a library or local book store if you are short handed of examples and see how the 'professionals' do it. Check out how far they explain the surrounding theory behind what you're trying to teach or explain and how much they insert their own personalized dialoge. It's kinda like looking at someone elses code and learning in the same way.

You're not writting this thing for robots afterall, but you also don't want to end up making a joke and story book either. :lol:

I think the best way to aim your material is to stick to the game theory and avoid getting too wrapped up in APIs, platform specific areas and anything that will distract too much from the task at hand. If you want to cover different APIs or platforms, I believe the best way is to make a seperate section or chapter for it. Every book I've read seems to do it this way.

You cannot really avoid the language too much, since how else are you gonna write this thing? So you are stuck having to get into language specifc things, but it might also be best to not get sucked into explainning every function, type or method you are using. Again, I'd recommend a seperate chapter all together for these things. Possibly at the beginning if it really seems like it's required. This way we know what you are talking about before we start using it.

I think, [size=9px](again this is just what I think not nessissarily the way it is)[/size] that writting a tutorial or small instruction is not really the same as writting a book. The tutorial has to be small and is sort of meant to be consumed in smaller chunks. The book on the other hand, while it still can be written so that you don't need to go from cover to cover to do anything, you have all this material to fit into it that you have to organize it a little better so everything is easily found and accessable. The better you break up the materials into their own segments of topics the easier it is for the reader to come back to it and use it as a reference later on. Which is really what most would want [size=9px](again, my belief)[/size] for the ideal programming book.


Hope some of my ideas and thoughts help you in your goal here. I'm dying to be able to see another Pascal-based games programming book out there.

[cairnswm]

I spent some time yesterday looking through chapter 1 of 'Isometric Programming with DirectX' (The only GameDev book I have).

Basically its 40 pages per chapter, an average of 25 lines of text per page.

The chapter covers an outline of windows programs, but for our book we could do an outline of the game program - language independant - except maybe for a template.

Things to cover

Game Object Initialisation
Sprite Management
Game State
Game Loop
Input Handling per state
Rendering per State
Sound management

all in brief. Sort of explain what they are, what they are used for etc. Later chapters could go into detail on each aspect - possibly a chapter per library as well.

[pwill99au]

Hi All,

Because of my (extensive) tutorials about delphiX, I've had several people asking me to consider writing a book. But next to the fact that DelphiX probably isn't the right package to base a book on (although I probably could convert them to any other package), I simply don't have the time.

...

Above is a quote from a message by Traveler. My question, to Traveler or anyone else, is, if DelphiX is not the 'right package to base a book on'... then what would be right

JEDI SDL maybe It's about the only one I know of. But there are probably other candidates.

What do ppl think about this

Regards,
Peter W. :-)))

[Traveler]

Delphix is nolonger the right package simply because it is too old. I believe SDL (if you want to have a chapter about cross-platform gamedev as well), Omega, Asphyre or one of the other more recent D3D based packages, would be a better choice.

[cairnswm]

Most of my Game Dev work is now done using JEDI-SDL. I have found it an API level that suits me really well.

I dont have Linux at home (or rather I have the CDs just not an installation). In Two months or so I should get a bonus and hopefully enough to buy a new PC or two at home for my kids - Then my ond P3 600 can become a linux machine and let me really get the Cross Compilation working.

I will do the book as a FreePascal/Lazarus using JEDI-SDL book. Concentrating on 2D with someone else contributing some 3D stuff.

[WILL]

Lulu.com is a site that allows you to publish books in any quantity you wish. (You can even just publish/sell one!) This may be the perfect solution for writting Pascal game programming books.

The only form of payment you will have to incur is about 20% (if I recall that figure properly) of the sales cost for each book. You set the costof the book. You can make printed or ebook, type of spining, cover art, and so on... You submit your 'manuscript' via a word document or some other such format.

I think because of this site it will allow this type of project to be completed with very little effort on the publishing side. And Sams,
Sybex, WordWare and the rest be damned...

[cairnswm]

lulu.com looks like a cool site.

I'll try put some effort into getting a small book done

[Raskolnikov]

This is something that Pascal could deffinately do with, I've been thinking about writing something along these lines using FreePascal for sometime now except splitting it up into several books:

The first book would cover FreePascal, teaching the language and the use of the associated tools (ie, fpdoc) and software construction principles. The second would cover cross platform development using GTK or even lazarus, if 1.0 happens to be available; the third would teach game programming fundamentals with SDL and finally 3D development with OpenGL and OpenAL.

Now, thats *alot* of work and right now it's just a pipe dream...but damn it'd be cool. The more publicity pascal gets the better and well, as it's users it's up to us to spread the word one way or another.

[marmin]

I think the best way to aim your material is to stick to the game theory and avoid getting too wrapped up in APIs, platform specific areas and anything that will distract too much from the task at hand. .

Now, imo that is mainly the problem with object pascal game dev. Am I wrong to notice that most people who want to program choose pascal because it has rad tools like delphi and wrappers like delphiX (that is hopelessly old and slow ).

If one wants to seriously program a fast game one has to dig deep in API, a complex game requires to know exactly what the computer is doing. And most programmers turn away from pascal because they get the impression that pascal game dev is outdated and not technical, fast, at all. That's just my opinion. A game that is made with all kinds of wrappers, rad tools, it's just not the real thing..

Why should a c++ programmer has to know all the details and a pascal programmer not?

[czar]

I think you will find that many people who want to write games want to do so for their own pleasure. They do not dream of making Quake 5 and C&C generals 2007. Instead they have idas about making RPGs, platform games and small single screen acrade games. Delphi can make any type of game that can be made in C++, however the wrappers and components make it much easier for programmers to begin making the games they want.

I have been making commercial software using delphi for the last 6 years, mainly multimedia educational gamey type programs and my lack of C++ experience has never been a problem.