[font=arial, sans-serif][size=2]Hi! I hope I'm in the right section of the forum and I apologize in advance if I'm not.

I just coauthored a book on F# and game programming. The main subject of the book is the F# language and its various constructs, but every single chapter is centered around a game-related problem. Each one of the first 5 chapters describes a problem, shows and discusses its solution and then discusses in depth the F# constructs used. The book has a (relatively unique) "problem-solution" approach where everything is explained because of how well it works in solving the problem, and not just "because". The 5 problems we present are:
- a bouncing ball
- the Saturn V rocket
- an asteroid field
- a large asteroid field optimized with quad trees
- a police starship that must fight off a pirate ship attacking a cargo freighter
In the last two chapters we use XNA to build a 2D and 3D renderer for two of the samples we have seen. We show the basics of the SpriteBatch class, the Model class, input management and audio with this powerful framework. Basically, we cover the most important aspects of XNA in a simple and succint way.

If you want to take a look at the samples, they can all be downloaded freely at: http://fsharpgamedev.codeplex.com/

The book is relatively short and cheap, and can be found here http://www.amazon.com/Friendly-Fun-game-programming-ebook/dp/B005HHYIWC/ref=sr_1_12?s=digital-text&ie=UTF8&qid=1313593351&sr=1-12 or here http://www.smashwords.com/books/view/81765

By the way, I'd really like for this book to be considered by the site admins for the "Resources --> Books" section ... Any idea how (or where) I can ask them?

Thank you for your attention!

Giulia[/font]

Nice effort. I don't have a compiler offhand for errors and other quirks but I believe you could have used a tad more (active) pattern matching in lieu of if..elif..endif constructs. (e.g. Chapter 5 coroutine impl and AI samples, also in Quadtree class impl).

Interesting usage and explanation of units of measure, and coroutine wrapped in a monad.

Good luck!

Well, thanks a lot

We were a bit torn about using active patterns: on one hand they are very neat, on the other we did not wish to add too much to the book (which is already a bit full of notions). How exactly would you have used them?

Also, if you don't mind the question, what would you add to the book, and what would you fix? We are gathering proposals for the next iteration of the book (due in 12 months)...


Finally, if you liked the book and you get a chance, please leave a mark on the amazon page

I would add -- and I haven't read the work, nor do I have more than a passing familiarity with F# -- that a book on any language should opt to make best use of its idioms -- ignorance of, or fear of overwhelming, the reader be damned.

It's like many of the early "learn game programming in C++"-style books which treated C++ as a slightly more convenient C -- Yes, I suppose its a nice example of how one could do things, but they did little if anything to move the language itself forward, nor to advance the way in which we think about building games.

Chose the best way to do things and offer alternatives where they are appropriate. I think if you follow those two simple rules, you will find that the book ends up precisely the length that it should be. For what its worth, that's my opinion as a reader of much technical material, and as a technical writer (software & programming) by profession.

Well, we certainly have no fear of overwhelming the reader: every chapter does not hide anything for fear of being overly complex, to the point that chapter 5 makes heavy use of computation expressions (monads) to define an entire abstraction layer to create coroutines to build an AI. In short, the book does not aim at hiding too much. Rather, we have tried to keep everything to a minimum, that is we have not used features such as quotations, active patterns, object initializers, inductive types reflection and many other cool F# capabilities simply because we felt that they did not add much to our *game development samples*; if they made it possible to build some very cool, self contained game example then we would have used it.

Maybe this is not the best approach, maybe it is, of course it is not my place to say. But I have never loved "language-itis", that is that strange illness where a language is presented as incredibly cool by a proponent who then proceeds to discuss its mechanisms in detail and with no apparent connection with reality. We believe that there is a lot of coolness in all languages, from ASM to C to C#, Java, F#, Scala, Haskell, Lisp, Lua, Python and so, so many others The hardest part is figuring what each language does best when you put it to real work, not how well it defines something a bit pointless such as summing a list, doing a factorial or computing a Fibonacci number. We tried to show how to implement a series of realistic mini-games where F# happens to shine a bit. Hopefully the book will be enjoyed by its readers!