I started playing this game last week but it had been sitting around on my Xbox 360 for about a month before I had a chance to play it (my wife and I had been deep into Fallout 3 and had little time for anything else). I have to say that I am impressed so far. The fine people at Capcom and GRIN have put their collective heads together and created a new experience around a classic title.

The training rooms are perhaps the most significant departure from the original. While the new visual look and great audio soundtracks do not change the gameplay experience, the training exercises are designed to enhance the game with a public ranking system and add a competitive edge for those who would not be completely satisfied by Bionic Commando's mission based levels.

For those who like item and monster records in their games, and I am one of those people, this game adds that feature to a genre which has traditionally shied away from such features. GRIN has also revised how you hack the enemies communication systems. Instead of simply selecting the "hack" option and then waiting to see if you have been detected, Rearmed starts a mini-game where you need to direct a ball to various target spaces in a cubic grid.

However, the most important feature the GRIN team has added is to ensure that it feels like Bionic Commando. I hope you give it a try and let me know what you think about the remake.

Categories: Games, Retro, Xbox 360
No Comments »

Core Memory

Just finished another classic computing book entitled Core Memory: A Visual Survey of Vintage Computers (ISBN: 0811854426), written by John Alderman and photographed by Mark Richards. While I did enjoy the photography much better in this book than in Digital Retro, I found both the context of the photographs and the text provided somewhat lacking in substance. Although I did find the photographs to be colorful, I do not find so many pictures of wire bundles and wiring trunks to be especially interesting. While it is interesting the see the complexity in wiring for one or two of these machines, it would have been more intriguing to see various parts of the machines, and to have those parts labeled.

I have not had the pleasure of using one of these machines, let alone putting them together. I can readily identify electronic components, but without providing context for the photograph, it's just a jumble of wires or components with no discernible purpose- however pretty they may appear on camera. It would also have been a great opportunity to provide more technical details on the machine, sample machine code or instruction sets, screen shots or running software (assuming the machine could even be turned on), and what not. It would have been fascinating to have a detailed list of primary technical components and their functions for each machine. Since some of these machines occupied so much territory, it would also have been informative to have a common layout diagram with a typical installation. Don't get me wrong, I enjoyed this book and all of the machines are photographed very well, but I think it would have been better to have smaller spreads and more annotated pictures.

Categories: Books, Retro
No Comments »

I just finished reading the book Digital Retro: The Evolution and Design of the Personal Computer, written by Gordon Laing (ISBN-10: 078214330X). Each machine in the book gets a four page spread, showing different angles of the various pieces making up the computer. I must admit that I did not find the images particularly engaging for the most part. They were excellent photographs, no doubt about it, but I don't think showing the back/sides/top of a monitor and keyboard is the best way to go about creating a visual history that will resonate with your intended audience. I would have been more engaged to read about the various quirks, pour over screenshots of popular software titles and the operating systems of choice, working code from the most popular programming languages for the platform, and even get a close look at the internals (for the inquisitive types who weren't afraid to void their warranties).

Pictures of the units themselves abound, but most are of poor quality, so a well lit photograph goes a long way to documenting what these computers looked like. However, once you have taken a photo of the front and back, there really isn't much left of the exterior that is interesting (not including the few machines which actually took advantage of the third dimension and had features on the sides of the unit). With all of the pictures, it left little room for text, and the text contained little more than a summary one could pull off a Wikipedia page. To be fair, the summaries are concise and some columns are filled with interesting tidbits. My favorite is on the last page within the section which documents the NeXT Cube. The page is almost completely filled by the monitor for the system, but there is an excellent piece of information which describes how Steve Jobs acquired the Industrial Light and Magic (ILM) division of Lucasfilm. Basically, George Lucas was in a bind after an expensive divorce and need to raise about $30 million dollars in capital. After a few failed attempts from other buyers, Lucas eventually accepted Steve's low-ball figure of $10 million. Needless to say, ILM eventually payed back huge dividends since they eventually released the enormously successful film Toy Story, which grossed over $362 million worldwide. ILM produced a number of large films and when you top all of that off with a lucrative IPO, Mr. Jobs is sitting on a mountain of money which probably has its own zip code. 

I find the book to be a excellent coffee table reference and the columns do make for a quick and easy reference, but I would have enjoyed the book a lot more if it went the extra mile and showed me things most books never touch upon.

Categories: Books, Retro
No Comments »

I spent some time trying to place a QGLWidget into a QGraphicsScene. Apparently, this is not a supported use of the QGraphicsScene class. One Trolltech engineer suggested creating a viewport using a QGLWidget instead of the typical QWidget (default). Neither approach worked and both ended up suspending the program on my Mac. There goes option number two for OpenGL sprites in the game.

Categories: Game Development, Niblet
No Comments »

Before I began my investigation into the suitability of Qt for games, I wanted to use Qt's new QGraphicsItem framework alongside the OpenGL support. I was curious to see if an OpenGL object could be wrapped by a QGraphicsItem and rendered into the same view. The short answer is yes, but the result is not very pretty or practical. Basically, it comes down to a fundamental issue with OpenGL and sharing rendering contexts with other engines. OpenGL doesn't allow this by design, but you could use an QGLWidget and encapsulate that in a QGraphicsItem implementation. The result is very heavy weight, not particularly elegant, and doesn't easily support animation of the OpenGL shape. With the latest version of the Qt API, you can render a QWidget object into an OpenGL rendering context, but not the other way around (without using a container like QGLWidget).

This is fine and not detrimental to the project, so we'll continue using the new graphics framework minus the features relating to OpenGL. This gives us plenty of options for rendering, but 3D will be set aside for now (unless I get a spark of genius). We may revisit it later to explore different ideas, like the intro screen or credits; however, we will need to find out how well Qt supports direct pixel rendering. I am very familiar with various image classes, but whether they can be used in and efficient rendering pipeline is still an unknown.

I'm trying to be realistic here. Niblet is not an overly complex idea, but I would like to use compositing for a variety of effects and some effects like fire would need to be rendered using fast pixel access.

Categories: Game Development, Niblet
2 Comments »

Right around the point where you finish with the Waters of Life quest, one of the waypoints during the main quest, the game crashes at different points much to the frustration of Fallout players everywhere. I do not know of a fix for Xbox 360 players, but for PC players, using your debug console may save you a lot of time and headaches. The basic strategy is to turn off the AI engine before the game crashes (you'll need to experiment), progress to a new scene or area or event, then enable it again. We had to do this a couple of times: once during our approach to Jefferson Memorial (we reactivated it once we teleported to Janice Kaplinski), and again before we turned the valve to unblock the pipes (last request from your father). To teleport to Janice we followed these steps:

1. Press the tilde (~) and disable the game's AI with the "tai" console command.
2. Enter the command: player.moveto 00019FC6. This will teleport you to Janice Kaplinski.
3. Talk to her, Dr. Li, and any other scientists, if you want.
4. Turn the AI on again with the same "tai" command.

Categories: Games, PC
No Comments »

We've been playing Fallout 3 for a few days now and it seems to have a few problems, but nothing too major so far. Over the last week or so, I have read a number of posts and articles complaining about the stability of the game. Well, my response to these people is to just relax and try and fix your problem with the debug console - Xbox and PS3 users are out of luck, I'm afraid.

With a game of this size and complexity, you must allow for the initial round of bugs, even ones related to the main quest. Bethesda simply does not employ enough people to cover the same amount of ground as the community. As an example, how many people do you think have purchased a copy of the game since it was released? I'm lazy, but let's just say 100,000 copies were sold. As is the case for almost every piece of software, users really do make the best testers since there are a lot of bored people in the world, and everything they do in the game is new and intriguing to them so they tend to poke and prod at the software in ways the game development company never expected. Do you honestly think Bethesda should try and compete with that many play testers? Well in order to have a testing team which can compete with a group that size they would need to charge $1000 for the game. Yeah, no thanks, I'll live with my slightly crippled software, until they come out with a patch release.

When you think about the number of things which could have gone wrong, the bugs I have seen floating around the Internet are annoying, but not outside what I would have expected from a game like Fallout 3.

Categories: Games, PC
1 Comment »

e·vil [ee - vuhl] - marked by calmness and serenity even during times of hardship and pending doom; literally oozing politeness when not absolutely required or called upon to exhibit; marked by ignorant suggestions and reiterateration of obvious facts and conclusions (can sometimes be confused with an idiot); shows no signs of being bubbly in personality which should normally accompany excessive politeness.

We've been playing Tales of the Abyss a lot lately and there are a few disturbing character traits we've noticed with Fon Master Ion. We presume you've noticed how blindly and obediently he unlocks all of those doors leading into the Sephiroth trees? After the cataclysm, notice how Luke takes the blame for letting Akzeriuth fall into the miasma, but in fact it was Ion who opened the doors in the first place! Ion is also in constant communication with Grand Maestro Mohs in the first half of the story, who we all know to be corrupt with power. Mysterious disappearances which he claims are kidnappings? Yeah, you're laying it on pretty thick Fon Master. Last, but certainly not least, is his disposition. Who in the Nine Hells is that polite or apologetic on purpose, except for the Prince of Darkness himself?

Categories: Games, Playstation
No Comments »

Categories: Comic
No Comments »

I'm a big fan of the Monkey Ball series produced by Sega. Sadly, I can't just bring the game everywhere I go since it's shackled to a console, and you just don't get the same experience on one of the portables. So to get my 3D rolling ball fix more easily on the road, I have turned to a game called Neverball. Neverball is actually two games in one package; the second game is called Neverputt. It's a GPL licensed game, so you can fool around with it to your heart's content and maybe even contribute something worthwhile back to the project when you're done.

Which brings me to the focus for this series of articles, we are going to add some functionality to the Neverball game. But before we can inject a new feature, it helps to understand how the game works and the architecture of the software; otherwise, we risk adding code which is either buggy, incomplete, or just awful. Since I really appreciate the stream-lined codebase for this project, I definetly do not want to sully the project using inferior source code, but that doesn't really concern me since every drop of code I write is pure gold.

As a logical first step, let's review the overall structure of the project. If you download it from the project's website, you will be given a choice of packaging suitable for Windows, Linux, or Mac OS X platforms. For the most part, I'll be focusing on the Linux platform, since it tends to be my development platform of choice in the here and now (although that's quickly changing to the Mac). However, I will not forget about the other two and will relay any useful information for those platforms when I come across it.

Neverball has a simple build file using to generate the executables and compiled map data, although there is a Microsoft Visual Studio specific project file so you are saved from toiling with Cygwin. You should have little difficulty in getting it to compile using your favourite Linux distribution. It has dependencies on a few SDL libraries like SDL_image, SDL_ttf, and SDL_mixer. I would also recommend developing and testing this program on a machine using 3D hardware acceleration. Depending on the sophistication of your CPU, software emulation may not be terribly fast and can prove frustrating when you're jumping into the game so frequently.

The project is structured into basically four pieces: data, modules specific to Neverball, modules specific to Neverputt, and the shared source code used by both programs. Between the two projects, Neverball is the larger and more full featured game. Neverputt uses the same rendering engine but customizes the game setup, layout, camera, etc. to suit the game of golf. The 3D rendering is entirely performed through OpenGL; there are no DirectX dependencies which is a boon for us since it makes the project more consistent and easier to modify.

The underlying engine uses objects and maps constructed from within a program called Gtk Radiant. I believe the most compatible version for Neverball would be 1.5, but 1.4 or earlier may work as well. A word of caution, the Gtk Radiant project does not build particularly easily on Mac OS X 10.5. You can find pre-built versions on the Internet via a small variety of sites, or you can simply download it here. In the next article, we'll look at how to set up Gtk Radiant and get it working; we'll also be looking at some of the higher level architectural pieces which makes the world of Neverball come to life.

Categories: Game Development, Neverball
No Comments »