Tag: book

Game Development and Production

There are tons of books about writing every aspect of a videogame, about how designing the next great hit, about how to model and animate characters, but this is indeed the first book about how to make a videogame. In other words by reading this book you’ll get some insights at how to plan and manage a successful videogame project. Although project managers should be mainly concerned about the matter of this book, I think it is a must read for team leaders and a worth reading for everyone involved in a videogame project.
I recommend this book not only for those involved in professional videogame production but for anyone who has a project (even at hobbyist level) about videogame production.
The author presents his own experience as the owner of Taldren studio and producer of several games. The book focus mainly on Fixed Budget/Fixed Time kind of games, which are actually the most difficult to complete withing the constraints.
Topics range from how to use UML to sketch the project requirements to how to propose the project to a publisher for funding, to which parts of the project to outsource, to how to find a job in the industry.
The author is proposing his own experience presenting what worked and what not. Considering the maturity level of this industry I think that it is a very good approach, instead of ruling do’s and dont’s, he collects best practices with a critical approach.

C++ Standard Library

(picture refers to the cover of a later version of the book) My approach to C++ was of unbound enthusiasm, until I started using it intensively. Then I got a more fair perspective on the language. Although it is still my language of choice (and it will likely be for a while) it is far from the elegance and simplicity that were the hallmark of the C language.After learning the ins and outs of the standardized C++, you’ll discover that the modern C++ language is a complex, heterogeneous, large pile of different bits and stuff patched together. The standardization process did no good to this and when you go in details of the standard C++ library all the mismatching comes to light.
Covering the whole standard C++ library is a daunting task, but this book does an excellent job. The aim of the book is to provide both a reference and a tutorial. Despite of these two, somewhat opposite, goals the result is very good. When you read it as a tutorial you can skim over the reference parts, glancing through tables and summaries since you just read the real stuff. When you use it as a tutorial you’ll find plenty of cross-reference both to descriptions and examples.
The only lacking in the book, by admission of the author himself, is about the io/stream section of the library which is not discussed in fine details. Anyway I found it very complete covering all the common and a good deal of the not-so-common usage of the everyday usage.
If you are going the C++ way and you’re already a programmer I strongly recommend this book along with “The C++ Language” by Stroustrup.

Spiriti

This is the second book from Benni I read. And the second I like. The story is about a new live concert which has to be organized to revamp the Perpetual War which is starting to lose share in the audience. Unfortunately shamans and Spirits are in the island where the concert should take place.Benni writes with talent an entertaining, satirical and surreal novel. The world he describes is not our present one, but it is easy to recognize current politicians, countries and corporations in the clever parody.
As in Terra! it is not just about satire, but the story is there with an urgent message of being true, of we under siege of empty or fake values.
Unfortunately this book seems to be available in Italian only.

SS/GB

I bought this book beacuse I am fascinated by the alternative history books. What if the German had won the WWII? The subject is the same dealt with in the book Fatherland by Robert Harris. The difference is that Fatherland is set in Germany, while SS/GB is set in London, telling about invading forces trying to define and layout the new system scheme and the subjected people striving between the revolt and revenge desire and the need of a stable and safe everyday life.I found the book rather dull… as if there were no story to tell about. The main character is a famous detective in Scotland Yard now to the orders of the new boss – a German army general. The plot is about some atomic research and stealing of related documents. There is a general good potential for developing situations, but the writer seems to lightly ignore them, putting other meat on the bbq and going on like that.
Maybe I lack some history details about relevant WWII people in UK, so I missed too many links and goodies, or maybe too much went lost in the translation… Anyway I wouldn’t reccommend this book. (I just glanced through the Amazon reviews that are instead rather good).

XP Refactored – the case against XP

Extreme programming never covinced me 🙂 I read Kent Beck’s book. I found it very well thought, with a good presentation. On some topics I agreed – unit test would have been a great thing to have in many projects I’ve worked on. Also some YAGNI (“You Aren’t Gonna Need It”) would have had helped sometimes. Also I found quite clever the idea of on-site customer, even if not so practical. Anyway I couldn’t imagine my programming life in pair. I have my rythm and I like to code alone. I’m ready to join colleagues if any of us would like to share thoughts or has some question, but programming was meant to be done alone :-).Another two points I wasn’t very comfortable with were no written requirements and no planning. I coulnd’t see how this kind of methodology could be applied to the environment where I’ve been working. We programmers strove to get specification and requirements in a written form. Our customers – artist and game designers were too fast in changing their minds, adding new requirements, and no so precise in their requests.
No plan conflicted with my idea of preparing for the future, choosing the right path to get to the goal.
Well, this book is a critique to the whole Extreme Programming, both on methodology and results. I recommend this book, even if its size could have been halved by removing parody songs (quite boring if you don’t know the original tunes) and reducing pointers to notes instead of having them occupy an inch of vertical space.
The starting point of the book is – where are XP results? Apparently the C3 project which was the springboard for the XP methodology was a blatant failure, so much that no one in Chrysler want to hear again of XP. C3 not only failed to hit the milestone (replacing the legacy payroll system before any chance of y2k bugs to manifest), but failed to produce a working system. According to the evidences that can be collected on internet and books, before being cancelled, C3 was able to handle only some 10% of the payroll it should have handled.
Nontheless many XP supporters advocate that this was a success, and that a project cancelled is not a failure, it’s just that the project stops to deliver value to its customer. XP propose other odd claims, such as, the planning doesn’t exist per se and XP project contracts should feature an ‘optional scope’. The customer should sign for a fixed amount of money and time, but it is not granted to have a result.
The book authors propose a fitting metaphore, they state that XP practices are like a circle of snakes. The XP requires a great effort to keep snakes at their places without anyone being harmed, but at the first distraction or relaxation, the snakes unravel biting the bystanders.
Some practices are identified as being more hard to follow closely. Also some roles have too much responsibilities such as the on-site customer (she is supposed to code unit test) and the coach (who is the warden of the XP verb, costantly taking care no one drift away from hortodoxy).
Also some risk are identified in the real world implementation of XP – likely a superficial management/customer would like the lack of up-front design and documentation, because this means that the programmers will start early to deliver something. But it is also likely that the very same superficial management would not apply unit test and costant refactor. In these situations all the XP methodology crumbles on itself. Many programmers had written to the book authors reporting their, usally bad, experiences in XP projects.
Another fitting observation is that basically what XP is doing is to enter maintenance mode from day 1. By looking at the traditional cost curve for a software project you notice that during this phase the curve is quite flat. And in fact what XP claims is to provide a flat cost curve. But it is the point where the project is most expensive. No one of the XP techniques can do anything to lower this.
Anther point that left me puzzled about XP was… pair programming. According to XP every activity has to performed in pairs. To support this claim Kent is ready to offer some references. XP refactored run a bit of investigation and discovered that the test (yes, just one) supporting that two heads paired have a productivity greater that a non-paired duo, was conducted on college students. Obsiously the results cannot be related to experienced or senior programmers.
The book closes with a refactoring of the XP methodology. I would say this is the least interesting part, since it turns out to be just another methodology not so different by the agile ones proposed in other book of software engineering.
To sum it up, I think you better read this before deciding to enter an XP project, and definitively you MUST read this book before running your own project with XP methodology.

Terra!

Terra! has been a nice surprise. The story is simple, after WW6 earth is a deserted land low on power resources where humanity is constantly fighting against the cold and snow, but with parties uttermost fighting against each other. A new planet is discovered and it seems to allow the life as it was intended to be. Quickly an expedition is set up by the Sinoeuropean Federation. Rushing after this spaceship there are two chasing spaceship, one from Amerorussian Empire and one from the Samurai Empire.Benni’s style somewhat resembles Douglas Adam’s, but where Adams goal was a comic intent, Benni is more concerned about humor. This approach let the author to convey more thought provoking messages.

Decipher

The plot is intriguing – set in the near future. While the weather and the environment is getting worse and worse, the human kind discovers some ancient ruins that are likely to be what is remaining from Atlantis. Atlantis was a very advanced civilization which discovered the real nature of the sun, which periodically causes destruction and chaos all around the solar system.They prepared an advanced mechanism to save the humanity, but weren’t able to complete it on time, so they left hidden instructions in myths and legends.
As I said the plot is intriguing and the author faced a great deal of documentation work, providing cross references in myths, linguistic and scientific discoveries.
In my opinion there were some aspects that could be developed a bit further, such as the “Rola Corp.” which seems to pull the strings of many characters, or the simplicistic ending of the conflict that was arising.

Core Techniques and Algorithms in Game Programming

This book aims to be a comprehensive textbook for videogame programming courses. At least this is what it seemed to me. It doesn’t contain anything new or complex, but it is a good presentation, offering many references, for all the subjects in this vast field. To the experienced videogame programmer, the book hasn’t much to offer, nonetheless I found a couple of things I didn’t think of and/or I didn’t know about.
For example AI programming with rule system was something out of my experience, both because the consoles on which I programmed hadn’t much CPU power to spare and the games I coded didn’t require an advanced AI, with the notable exception of RogueSpear GBA.
Employing a rule system for RogueSpear GBA could have likely simplified our tasks.
Also the outdoor rendering algorithm is something that was relatively new to me.
To sum it up a good reference book, containing pointers to more detailed dissertations. I recommend it for junior programmers more than seniors.

Bread Alone

I read this on my wife advice, and I thank her because the book is very nice and ties you in until you finish it.It is the story of an american young woman with a passion for cooking bread. The book starts with her first serious boyfriend, going on with the marriage, how it broke and the way she walked to find herself.
Characters have their own personality and behaves accordingly. The story is fresh and inspiring.
Plus you get a number of bread and bread related stuff recipes.

Extreme Programming Explained

Extreme Programming is a software engineering practice, promising to deliver a flat cost line for fixing defects during all the development cycle of the project.The book is very well thought out, providing a crystal clear explanation of all the methodology and the rationale behind.
I don’t agree on every part though I think that there are some practices that are worth studying or using in other environments. For example the idea of running light is very attractive, but having large and or complex system just described by the code itself is, to put it mildly, scaring. Design is needed to point the way and ensuring that the system is evolving in the right direction.
The extensive use of the unit test is a good thing, too often the building blocks are flawed and you discover it only when you need them in some specific situation. Pair programming is one of the aspects of XP that I like the less. When programming I like to have the control, to be free of editing a file in the most messy way I prefer grant that the result is good. Also trying to think alone to the solution and following reasoning path that could be perceived as fruitless by my hypothetical pair.
I wrote a summary (in Italian) of this book.