Thursday, April 14, 2011

The Philosophy Behind T:AV - Part I

First off, I'll date myself by saying that I grew up in the dawn of computer gaming. And I use the term "grew up" loosely, because I really never grew up. So let me rephrase it: I morphed from a small human into a slightly taller human in the dawn of computer gaming. As a result, I've seen it all. I've watched games evolve from simple monochrome vector graphics to 32-million color polygon rendering phenomenons.

Abstract vs. Realism

Something about the evolution of gaming appears to have been just as much of a hindrance on creativity as it has an aid. It seems strange that artists when given only one color crayon, might come up with something more original than an artist who has been given a crayola box with 128 colors, but somehow that often seems to be the case. Now maybe that's the fault of the artist, or maybe its the audience. Regardless of who is responsible, nobody looked at Mario, in his 16x16 resolution, 3-color glory, walking around Donkey Kong's tower of sloped support beams and thought, "That looks SO fake." It would seem though, that the only reason nobody complained was because the technology available wouldn't allow for more realistic imagery. The moment such technology became available, people became more nitpicky, and demanded more realism.

While this in theory is all fine and dandy, it forced artists to more often think inside the box. The more realistic games became, the more they became limited by the confines of every day reality. Now I'm not saying there is no imagination anymore when it comes to games, but if you put modern games next to the old ones, there is no question that the older games had more freedom to deviate from reality when they chose to.

For an example other than Donkey Kong, one that more closely pertains to the project at hand, I'll actually use TRON. While I love the Tron Legacy film, this new sequel to TRON that was released in December 2010 still falls prey to the same demand for realism that video games have. In the original TRON, lightcycles turned at 90 degree angles. An audience in 1982 had no problem accepting this. They knew that even though it was a film, TRON was a video game universe, and the video games of the time often had bizarre or impossible rules and physics. So they accepted it as, "That's just how it works there." In Tron Legacy, someone concluded that audiences would reject such impossible physics, and made the light cycles behave more like real-world bikes. People would otherwise ask questions like, "How can someone turn a vehicle at 90 degrees? Wouldn't it skid? Wouldn't the person be crushed against the side?" So now, light cycles have brakes, analog turning, can skid and burn rubber, and can even switch their light ribbon on and off at will. Not that this is automatically a problem - the new film was wonderful, but as a game mechanic, it makes less sense. And while one could make an argument that Tron Legacy is more complex because the video games of today are like that, anyone who has played classic light cycle games would see why some of these mechanics don't work as well for a video game. To summarize, as film effects have improved, the demand for realism has increased. And the same trend has happened with video games. The better the technology has become, the higher the demand for realism.

If Donkey Kong were being introduced for the first time today, there would be a lot of people scratching their heads. In order to defeat Mario, Donkey Kong throws barrels down ramps. Connecting one ramp to another are ladders which Mario has to climb. Sometimes the barrels don't just roll down ramps, they roll down the ladders. To a modern gamer who has been spoiled by realism, this automatically creates numerous questions. "How do the barrels roll down ladders? Why do they sometimes roll down ladders and sometimes not? How can ANYTHING roll down a completely vertical surface? Wouldn't it fall? It falls too slow. Why doesn't it break after it falls? What's holding up the platforms?" To a gamer in the 1980's though, this wasn't on their minds. All that mattered was, it was challenging, and it was fun. Who cares why the girl in her perpetual pre-middle-aged life managed to get herself imprisoned by a 20-foot tall gorilla? She's obviously not particularly happy about it, so stop asking questions, pick up the sledgehammer, and SAVE HER!

TRON: Anti-Virus, which thankfully is not at the beck and call of any producers who are trying to adhere to certain formula standards designed to widen the audience potential as much as possible, seeks to return to the roots of computer gaming. This means that while realism will still play a role (there will be gravity, and things will fall when jumping off cliffs.... usually....), T:AV will not forget that TRON is, at its core, a video game universe. And since it takes place on a 1980's computer system, classic gaming should play a role just as it did in the original film.

While realism often makes a game look better, it rarely makes for a game that is more fun. The games in human history that have stood the test of time are extremely simple and have little bearing on how reality works. Can a castle get up and walk around? Do horses have to step once sideways every time they take two steps forward? Do Queens pick up arms and fight in battles? 99% of the time, the answer is no to all of that, regardless of what point in history you're talking about, but it hasn't stopped chess from being one of the most well known and popular games of all time. Remember that the next time there's a complaint about how ridiculous it is that Duke Nukem (at least in DN3D) can carry 7 guns with 12 boxes of ammo while jumping twice his height without even breaking a sweat. I know mythbusters proved that hitting a flesh target with a shotgun won't make it fly backward 10 feet like we see it do in the old action films, but that doesn't make it feel less satisfying when we do it in a video game.

Sunday, April 3, 2011

"I Never Should Have Written All of Those Tank Programs" -- Kevin Flynn

Considering how little experience I had with Duke Nukem 3D's scripting language only a couple of months ago, I'm rather amazed that one of the first features I implemented into TRON: Anti-Virus was also one of the features that I thought would be the hardest to implement; a drivable vehicle. Vehicle mods have been done for Duke3D/eDuke32 before and after only a few minutes of looking at the code, I had an idea of how to go about it.

Getting the movement controls to work and the appearance of manning a swiveling turret that rotates independent of the vehicle was finished in no time. What took much longer was completing HUD. Every instrument on the HUD actually works, and they're all graphical representations, which includes a compass, an overhead view of the tank showing the angle of the turret relative to the chassis, ammo, vertical angle, speed, and armor.

Finally there was the projectile, which I foolishly decided I wanted to have working before I took a break. The tank is one of the three most recognizable and iconic items in the original film, so I really wanted the weapon to look like it should. This required a lot more effort than typical Duke animations would - 5 different components total; the impact flash, '2 different particles', the blast 'ring', and the pathing 'trail' following behind the projectile as it moves through the air. The biggest problem here was the blast ring, because in order for it to mimic the film's effects, it would have to align itself to whatever surface the projectile hit. In later games this is a rather common effect - the first time I remember seeing it was with the shock rifle in Unreal. But none of the default Duke weapons do this, which meant a hairy bit of extra code for what is otherwise just a basic explosion.

Saturday, April 2, 2011

My first bout with artificial intelligence (sort of)

Considering that those many years ago, trying to figure out AI in Duke scripting was where I stopped working on modding, it made plenty of sense that AI is where I'd start working on it again.

The landscape of the gaming community was far different for me at the time. The internet was still in its infancy, finding communities of people wasn't all that simple, and my only sources of reference material for Duke modding came from 2 different FAQ's I was able to find. If I couldn't figure everything out from those, I didn't have anyone else I could ask for help. To make matters worse, my only programming language at the time was HTML. I had never dabbled in any kind of dynamic coding before.

Fortunately going back to this game, I now have had far more experience. I've written games from scratch in shockwave, flash, and game maker, and used GUI-based scripting features in other games such as Starcraft. Therefore, a lot of things made far more sense to me this time. In just a couple of days, I had a simple monster chasing me around, one of the monsters that I've had in mind for the game since the beginning. I chose this one because it required minimal artwork to get it to look somewhat like it should.

Once that was taken care of, I decided to move onto the Bit; a neutral character in the game and not critical for anything, but it'd be wrong to not have those little guys in there. They can do everything the bits in the film could do... which... wasn't much really. They can hover, say yes, and say no, say both words in their own emphatic way, and they'll wig out and zip away in random directions if you shoot them.

Both of these creatures are among the simpler ones in the game, but were good learning experiences. I tend to work best by immediately applying what I've learned. It helps keep it ingrained in my mind so I don't forget it later. When I learn a new command, I immediately think up something I can test it on so I can see it in action. Little tricks I picked up from getting these simple-minded creatures to behave properly will surely come in handy later.

Friday, April 1, 2011

Birth of the Blog

After thinking about it for a few days, I decided I should do something I swore to myself I'd never EVER do: create a blog. While I'm not much for this kind of social interaction, I felt that the development of a project such as this could do with some kind of a journal, so here it is.