Olivier Langlois's blog

Until recently, the only way that you could get a second guitar was to buy a Guitar Hero 3 bundle including a second copy of the game. That is what I did and I am quite happy of this decision because, for people that do not know it yet, Activision announced a game disc replacement program to fix Guitar Hero 3 mono audio problem and Activision will require people to first send their game disc before shipping to customers the bug fixed disc. By having second copy, this will allow me to keep playing while I wait the fixed disc which I would expect to take few weeks.

That being said, the real news is that the company Nyko announced at CES this year that, for buyers looking for an economical option to get a second Wii guitar controller, they would sell a standalone guitar controller for the Wii called the Nintendo Wii FrontMan Wireless Guitar at a substantially lower price than the Guitar Hero 3 bundle price. It will be available on March 15, 2008 and Amazon.com is already accepting preorders!!

For people wondering if playing coop at GH3 is fun enough to justify the purchase of second guitar controller, my opinion is YES!

Some people are maybe wondering why we are not seeing cross platforms titles such as Guitar Hero 3 being compatible from one version of the game to the other versions. For instance, I have the Nintendo Wii version of GH3 and I would have loved to be able to play with my coworkers online that have the PS3 version.

Technically, it is possible because, with the exception of Microsoft Xbox consoles that are using a proprietary encrypted protocol, all consoles are using the same standard TCP/IP protocols to communicate and TCP/IP protocols goal is to connect different hardware together. Usually, game developers are either using a network engine that adds another protocol on top of UDP or they develop themselves the new protocol layer but either way, the protocol will be identical from one platform to the other.

When I was working at Quazal I have frequently let network test programs communicate between a Xbox 360 (in development, you can turn off the proprietary encryption to let you debug your programs) and PS3s flawlessly.

That would be cool to have that feature in retail games but the reason we do not see it is only because it is against the console makers interests who have full control on the software sold for their respective platform. You want to play online with your friend that just purchased a new Xbox 360 game. Well, you will have to buy a Xbox 360 too or else you will not play online with your friend. Period.

It could have been a good book since the topic is interesting. All developers know what spaghetti code is or how adding features quickly on top of a prototype without modifying the software architecture can lead to a big blob of unmaintainable code. I took this book in hope to learn other bad software development habits in order to avoid them. Despite the potential, this book does not deliver it. It start with a lengthy and half comprehensible 60 pages introduction followed by a catalog of antipatterns where most of them are empty of value. Out of around 30 antipatterns, I would estimate to less than 5 the number of antipattern descriptions interesting. Examples of useless antipatterns are:

Bad management; proposed solution: The manager must become aware of his problem in order to change.
e-mail arguments; proposed solution: Call a meeting to come to an agreement instead of wasting time writing e-mails.

After having reported the bug to MySQL and after a lot of patience trying to explain it to the MySQL developers, they have finally verified the validity of my bug discovery and have classified it as serious!!

For the gory details of my discovery, you can consult the bug report.

My opinion is that this will happen. You just have to take a look at Guitar Hero 3 sales that show that the game is best selling for the Wii. It does not take a MBA to figure out that releasing Rock Band on the Wii would be a profitable move for the publisher.

There are, however, few difficulties that need to be overcome before this happen. First, the publisher apparently is hoping to generate a lot of revenues from the sales of downloadable content for the game. With the new online connectivity of consoles, they are creating a platform that they control on top of the consoles. On the Wii, this is not possible yet to do that. Technically, it would be very easy for a game developer to write downloadable content on a SD card or on a USB hard disk but I am guessing that it is Nintendo that is stopping developers to do that for marketing reasons. That is certainly a factor that is slowing down Rock Band arrival on the Wii.

Secondly, Rock Band is using the network engine of my former employer, Quazal and Nintendo has a partnership with GameSpy, Quazal competitor. The exclusivity deal between Nintendo and Gamespy has the consequence of denying access to the Wii console to all the other 3rd party networking middleware providers. What that means for the publisher is that he will need to take a tough decision. Negotiate very hard with Nintendo to allow Quazal to port their middleware on the Wii. If this happens, it would be very beneficial for Quazal as Rock Band would become their entrance ticket to the Wii market. I am guessing that this option can be expensive as Nintendo is in position to negotiate as they do not need any hot title right now on the Wii to sell consoles and making tons of money. The other option is to port themselves the Rock Band game online connectivity module from Quazal API to GameSpy API. Based from my experience, I estimate that it could take a couple of months to a small team of software developers to do it.

No matter what outcome is chosen, there will be a lot of work to perform to do the port on the Wii. The chosen outcome will just move the burden to do the port of the networking module either on Quazal or on Harmonix. There will be no difference for the end-user so EA and Nintendo will opt for the option that is the most profitable for them. The decision will just make a big difference for my old buddies at Quazal so I hope for them that things will work out in their favor because they are working hard and have good products. Anyway, based on this explanation, I am predicting that if Rock Band makes it to the Wii, it will not happen before Thanksgiving 2008.

I have not found this book very fun to read because of its very structured and academic format. I have not learned much from it as much of its content is general wisdom that anyone with many years of experience in the industry has probably seen around before. Something positive I can say about the book is that I totally adhere to the methodology explained in the book. In my software development career, I have experienced myself the benefits of applying similar software development management methodology and I have also seen the negative consequences of not following it.

I have not found this book as interesting as the type of books that I usually read. I prefer books dealing with the more technical aspects of software development. I have read this book because I need to acquire a solid base of knowledge on software project management and not because the topics covered in the book seemed fun and interesting to me. Even if I was not very enthusiast to read it, I must confess that the author made a great job making his book interesting to read by interleaving important concepts with anecdotes from his work experience.

This book is divided into 54 short advices each taking 1 to few pages to expand the rational behind the advice. This is a format that I like and the advices that I have preferred were the ones dealing with the psychological aspect of software development. An example of such rule is that software quality is the mirror of the state of mind of the team. For some this might be obvious but considering the book intended readers which consist of engineers and software professionals, the author has been wise to be explicit on this topic in my opinion as from experience, human interactions is usually not the strongest skill among developers.

The part that seems to me to be outdated is the whole proposed economical model to market software. The author advocates that to make money from software, you must release often like every year and by doing so, your customers will be so happy that they will gladly hand you more money year after year. I think this model used to be true when the software industry was still young 20 years ago but in 2008, the software products are so mature that no matter how hard you try to squeeze more new features, it will not be enough to justify for people to purchase the new version when that last one does everything you want. You just have to think about the sales of Windows Vista or Microsoft Office 2007 to see what I mean. Changing just for the sake of changing does not sell.

In my opinion this model should be changed to one where incremental small evolutions are proposed to customers. I would be willing to pay a small amount of money every year for an OS that is smaller, better and faster at each version. I do not get it how software companies can expect people to be interested in slower and more bloated products than the previous version. Add the possibility to purchase inexpensive add-ons to fill very specific needs to the model and you have a very attractive model. I am not sure if what I would like to see is representative to what the typical customer expects or if my proposal is viable in real life but one thing is sure. The model proposed in the book does not seem to work anymore for many mature businesses.

There is a 2006 edition of this book. I might take a look in it to find out if the advices that I have found outdated have been reworked.