Discs...

It's been a while now since I published a real progress update, and the reason for that can be summarized in one word: Discs.

The Identity Disc is the most iconic weapon in the TRON universe. One can no more imagine TRON without Discs than they can imagine Star Wars without Light Sabers (so strong is the comparison that many new-generation fans have begun referring to them as Light Discs).

Back in the late 90's, when I first thought of the idea of Tron: Anti-Virus, Identity Discs were not even going to be included. Not because I didn't want to, but because it probably would not have even been possible. First-person shooters were still in their infancy, and hardly anything ever went beyond some kind of projectile that came out of a gun, flew straight at its opponent, and then exploded (even grenades were rare at the time). But countless improvements to Duke Nukem 3D by the modding community have greatly expanded the game's capabilities. That's not to say that making a disc work is easy though. In fact, it's an enormous headache.

It would not surprise me at all if the Identity Discs end up having the most complex AI in the entire game. If I were basing them off of Tron Legacy, it would actually be easy. But I am painstakingly attempting to get the behavior of the Discs to match what is seen in the classic film (this behavior is actually emulated pretty well in the Tron: Evolution game). In TRON, Discs are akin to swords. They are an extension of their wielders, even across the distance of a room. Disc fights are very duelistic in nature, with opponents attempting to hit and parry. The Discs are also guided weapons, as if while in flight, they operate by remote control or telepathy, always linked to their owner. A wide range of attacks can be achieved, which also dictate what must be done to achieve a successful block. All of this translates into a rather complex system from a programming perspective, though to the player it should be pretty straightforward. To make disc combat possible, I have had to add two more functions to the game, a block button, and a 'target select' button.

The Disc combat system is not done by any means. I am still knee-deep in it. So in the event that it takes another month to get it working the way I want it to, I felt that I ought to post about it.

The Philosophy Behind T:AV - Part II

As I previously stated, the TRON universe, is a place that is greatly influenced by the minds of its creators. This is demonstrated as we see Kevin Flynn's imagination brought to life on the game grid. His lightcycle game, which on the low-tech capabilities of the era, appeared as simple 2D lines being drawn on a screen, appear as fully-3D futuristic motorcycles to the inhabitants of the computer world. Just as Programs take on personalities influenced by the Users who create them, it is apparent that other aspects of the universe are affected in similar ways.


Life Inside a Classic Video Game
 
"On the other side of the screen, it all looks so easy." -- Kevin Flynn

If you were to take a piece of paper, draw a basic kid's maze on it, and then draw a line from the beginning of the maze to the exit, you have created and played a simple 2D game, something that could easily be made into a basic computer game. Though as a game, instead of a line being drawn, you'd probably want an object to represent the player (presumably something shaped like a person, even a stick figure will do). Then you might want to populate the maze with some sort of monster, robot, etc, that can attack you as you're trying to escape the maze. And unless you're sadistic, you'll want to give some kind of weapon to the player so he can defend himself.

Playing this game would be pretty easy for your average gamer, at least in the early levels. But if this game were being played by an inhabitant of the computer realm, surviving the maze would be an entirely different matter. Not only is it life-or-death to them, but they're actually having to run around inside of this maze... the walls of the labyrinth intimidatingly towering over them, diving and rolling to narrowly avoid attacks from the monsters, and pulling off spectacular trick shots with their blasters. A 2D game, represented in 3D. Just about anyone can see that video games themselves evolved in this way; a game like Berzerk or Robotron many iterations later looked like Doom or Duke Nukem 3D. For Tron: Anti-Virus, the intention is to provide a 3D first-person shooter, but treat it as if the 3D element is an extension of a 2D video game. That isn't to say that 3D won't be fully taken advantage of, merely that the basis of certain elements of the project are deeply rooted in gameplay mechanics that are commonly only used in 2D games.

Pondering over these old games has helped me think of a number of puzzles that I plan on including in T:AV. One classic game concept in particular has even inspired an entire level. Such inspirations aren't limited to level design either. It can also be found in the behavior of enemies in the game; how they move and attack, and how they must be killed.

It is my hope that incorporating these elements into Tron: Anti-Virus will create an experience that is somewhat unique to the first-person shooter genre, but is also strangely familiar.

Though I don't intend on turning this into a playable puzzle (at least not one that is actually critical to gameplay,
I felt like this post was an appropriate place to showcase it. I did it moreso as a programming exercise than anything else,
and to see how well eduke32 handled it. It's one of the earliest computer "games", Conway's Game of Life.


The Philosophy Behind T:AV - Part I 

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.

The Philosophy Behind T:AV - Part II

"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.

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.

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.