Víctor Caveda Blog » Software Engineering

Riptide GP: An Android Game Postmortem

caveda — Tue, 27 Sep 2011 18:44:22 +0000

The website Gamasutra frequently publishes articles where game creators talk about the development process of a game. These papers are called Postmortem because they are written once the game’s been finished/released and that’s precisely what it makes them so so valuable. They are no just about “how brilliant we are”, on the contrary, Postmortems usually focus on mistakes and lessons learned.

Although most of them may be considered a must-read, I’ve found particularly interesting the one about Riptide GP where the guys of Vector Unit describe the process of porting a 360 xBox game (Hydro Thunder Hurricane) to the Tegra 2 platform. Hot topics such as funding, monetization and piracy are also addressed in the write-up . Definitely a good read!

Postmortem: Vector Unit’s Riptide GP

_______________________________________________________________

Duke Nukem Forever: When Enough Is Not Enough

caveda — Sun, 24 Jan 2010 21:57:52 +0000

Duke Nukem Forever has been one of the most expected games ever. As every geek knows, it’s been by far the most infamous case of Vaporware as well. Many lessons can be taken from the story of the project and how the 3D Realms people managed it. In fact, I sincerely believe this story must be taught in every single Software Engineering Course as an example of unbounded ambition and perfectionism.

Even though 3D Realms was a highly talented and groundbreaking developer company, when it comes to the Duke Nukem Forever, they totally failed. Actually, they coined the dreadful sentence: “It’ll be done when it’s done” which represents the principle that drove this neverending project. It worths reading the whole story that has been told in a splendid article published by Wired Magazine:

Learn To Let Go: How Success Killed Duke Nukem

_______________________________________________________________

Panda Cloud Antivirus

caveda — Fri, 01 May 2009 19:18:01 +0000

After 18 months of hard work, the baby’s finally born! This is my first project as Application Architect and I must say that it’s been quite a challenge for the whole team. Since we’ve built almost everything from the scratch, we’ve spent a good deal of time thinking and designing every little aspect of this piece of software. Of course, there’re still things to improve/fix/work on (like any Beta software) but, generally speaking, I’m fairly pleased with the result.

By the way, Panda Cloud AV has been released as a Public Free Beta so if you want to check it out, just visit the official site: www.cloudantivirus.com

There is also a blog for testers in which you can find technical details about the product, e.g Security Model, Known Issues, Logging, etc.

_______________________________________________________________

Call It Anything

caveda — Fri, 08 Aug 2008 16:35:21 +0000

Building prototypes (if necessary) is considered best practice as far as software construction is concerned. Its usefulness lies in the lesson learned which can be applied later on. Therefore, you can develope prototypes in order to validate your architecture, testing performance aspects, selecting the right technology and so on.

So far so good. However, you must know the fundamentals of software prototyping:

Partial functionality. Your prototype shouldn’t have all features. After all you’re trying to validate just one aspect of your future product, otherwise your working on a early version of your product.
Doesn’t meet your quality standards. Since a prototype is not a product, there’s no point in making it perfect. Moreover, you need it to make a decision so you want it finished ASAP.
Disposable. Because of point 2.
You’re prototyping and that is crystal clear. Stakeholders (particularly managers and clients) must understand you’re working on something disposable.
It’s part of your planning sheet. So everybody knows you’re going to spend some time on it.

If your so-called “prototype” breaks any of the rules mentioned above, it’s more than likely that it has nothing to do with a prototype. If this is your case:

Do no refer to it as a prototype, call it anything. You’ll save yourself a lot of trouble.
Ponder using any of those incremental methodologies.

To sum up, just keep in mind the following:

It’s a prototype.

It isn’t.

_______________________________________________________________