[Home]
[Anime]
[Babylon 5]
[Christian]
[Games]
[Personal]

Nathan Mates' Personal Info Pages

Nathan Mates's .plan Archives

Plan Archives from February 1999.

[visi.com] 
Login name: nathan    			In real life: Nathan Mates
Directory: /home/nathan             	Shell: /bin/tcsh
Plan:
Job: Network Programmer, Battlezone 2, developed by Pandemic Studios http://www.pandemicstudios.com , published by Activision http://www.activision.com [Note: in this, I am *NOT* speaking officially for either of those, I'm only speaking for myself.]


2/28/99: You've been tag-taming a BZ2 deathmatch for over 49 days in a row under Win95/98... and the system crashes. Guess what? That's not BZ2's fault. According to Microsoft, Win95/98 is limited to an uptime of 49.7 days, so the ultra-marathon deathmatches are out. Big thanks to http://www.userfriendly.org/ (great online cartoon strip, by the way) for pointing out http://support.microsoft.com/support/kb/articles/q216/6/41.asp

Some quick calculations of my own say that BZ2 might have problems running a single game (without restarting the map or anything else) for more than 2485 days (~6.8 years), but I *seriously* doubt anyone will be able to keep any system running BZ2 up for that long. If you do, please contact the fine book of Guinness for listing under "miracles." :) Also, I'll be pretty darn flattered to find many people playing BZ2 online in 2006.


2/27/99: New system at home built up. For those keeping track, my main machine has the following: PII-350, ABit BH6 motherboard, 128MB RAM, SoundBlaster Live! (w/ 4-point surround & subwoofer), Diamond Monster 3D (Voodoo1-- kept around from old system due to Tribes), Creative Labs Riva TNT, Adaptec 2940UW, and a NE2000 ISA ethernet board. I really like the designs of ATX cases now-- it took me longer to borrow the 3.5" drive, HDs (11GB UW SCSI) and CD-ROM (Plextor 12/20x) out of my old system than it took to install the motherboard, RAM, and CPU. It also took a while to get all the drivers installed for the new software...

Rough benchmarks: 786,923 keys/sec with 2.7106.436 client (see http://www.distributed.net/rc5/ if you don't know what I'm talking about). My other 'benchmarks' of Might & Magic 6 (software-only rendering) was a *HUGE* improvement, and Tribes also was *much* smoother.

One problem for the TNT experts-- with latest drivers, if I set my Windows desktop to more than 1024x768 (1152x864 is my preferred resolution, this also happens in 1280x1024), the display is drastically mis-centered on screen (MAG MXP17F, with .inf installed for it) -- the picture comes up way to the left of center, and I can't get it back to centered with the monitor controls. Anyone ever see this, and have a fix? [Note: fixed 3/1/99.]


2/26/99: A bit of initially contradictory news came out yesterday, with some sides initially saying US telephone calls to ISPs might be treated as long distance (and subject to extra billing $), and others saying not. http://www.slashdot.org/articles/99/02/25/236232.html summarizes that this extra billing won't happen.

Good. As a network programmer, the last thing I want is extra costs for people wanting to play online... that'll make companies less likely to want to put in network play. [I've done lots of other things in the videogames field besides just network play, but I'm personally of the 'smaller government' conservative stripe.] In Europe, even local calls tend to be billed per minute, making hours spend online a $$$ proposition. That bites, and the internet hasn't taken off as much over there because of that.

Of course, I'm not too pleased at the telecom companies who brought such a suit to begin with, and had they gotten their way in the FCC's decision, it seems quite certain there'd be an extra charge. They'd simply be shooting themselves in the foot with that, as cable modems would have been more and more attractive.

I've got cable modem to home, and I'd hate to downgrade to a 28.8-56K modem after being spoiled rotten with it. Ping times of under 75-100ms to a load of Tribes servers, and similar ping times on other games. Low latency, lotsa bandwidth, not much cost-- I love mine. Bug your local cable companies to roll it out in your neighborhood. Games in general play so much better on cable modems, DSL, T1s, and the like, and if every 28.8 modem in the world was replaced by a fast connection, my job would be so much easier.


2/25/99: [This is totally unrelated to BZ2, but I thought it was cool enough to mention.] If you've read previous .plan updates, I'm building a new system at home. Since I'm of the "I own screwdrivers and I'm not afraid to use them!" mentality, I'm building this system out of parts mailordered from a whole bunch of companies.

In previous mailorders, I've become reluctant to use UPS simply because (1) I'm at work when they usually drop by, and (2) their nearest pickup center is in downtown Los Angeles, which is quite inconvenient to drop by. Most places let me have a shipping address different than credit card billing address, but some companies won't ship to an address not on file. On previous orders, I'd get the UPS sticker at home, then call them up and reroute the package to work. That added a day or few wait to the delivery. [FedEx has a pickup station only a few miles south, and was more convenient.]

So anyhow, I was waiting for the ATX case for my computer to come in, and didn't see any UPS stickers at home, getting worried it had shipped late, or something. 20 minutes ago, the UPS guy dropped by work, and they'd automatically rerouted the delivery from home. Definitely a nice thing to do, and makes me less reluctant to ship UPS.


2/23/99, Later... DLL simplification went well, code neatened up in some other areas, and some compression tracking stats added in to see how well certain things are going, and if things could go better in some areas. Those are minor compared to the next big thing on my plate: a decent User Interface (UI) for the network code. It's been in "UI from hell" mode ever since I started, with people required to punch in IP addesses and jsut about nothing else. I can use it just fine.

However, we kinda feel the public wants something a little nicer, so I'm starting work on that. Some news may be coming down the pipe soon as to certain things we're supporting that may make a bunch of people happy; I won't say anything at this point, though, until it's official. Keep reading this page, and you might just learn something. :)


2/23/99: Milestone candidate submitted yesterday. Yay. With that load off my back, I could do some of the non-critical items I wanted to do like unifying/simplifying the code to make a shared DLL interface file that all the singleplayer and multiplayer missions work from. This is much nicer, as we only have to modify one file when the interface to the DLL changes, not 3-4. Guess that's the "KISS" (Keep It Simple, Stupid) principle at work, something I'm a bit of a fan of.

And, some updates on comments I've made previously... looks like there are some RPGs based on Quake and Unreal engines in the work, Arachnarox, Wheel of Time, and a few others. It'll be interesting to see how well they manage to separate the graphics engine from the gameplay, and if they manage to change the public's perception of "engine == gameplay" that seems prevalent. Also, looks like Heavy Gear2 has some commander mode on a map, something I was unaware of when looking at others in the office play a demo last fall. Sorry for any misconceptions about HG2; they're purely my error.


2/20/99, later: This is something of a general observation on 3D games I've worked on, and at this stage of BZ2, such observsations MAY NOT bear any reality to the final optimized version on store shelves. [I'm running debug builds of BZ2 almost exclusively right now, which have a fair chunk of overhead for the debug info (extra logging of packets received by timestep, etc).]

Basically, in my experience, a *lot* of 3D games, when profiled, spend less than 50% of the CPU time in the actual game. [A profiler is a program that monitors another running program, and helps identify where the slowest part(s) of the program are by seeing which functions take the most time.] I do not have any %s for BZ2's code right now, and most likely won't.

This begs the question: so where's the CPU time going, if the game isn't a simple majority of it? Answer: DirectX (Direct3D) and the 3D driver are the main culprits here. Those two eat HUGE chunks of time, and most likely that'll remain the case for at least a year or so. They're doing stuff like geometry transformation and lighting on polygons, before passing that processed data to the 3D card. No consumer-level 3D card does geometry acceleration on the card. AMD and Intel have pushed big marketing campaigns around their new chips doing faster geometry acceleration, on the CPU. [Aka time not spent on the game.]

[Those of you who remember the BZ2 IRC chat last month will remember my *PERSONAL* opinion on adding in extra instructions, as the K6-3D and Katmai/PIII are doing: I think the transistors are better spent on larger L1/L2 caches, the time and effort in developing such things better spent on more Mhz, deeper pipelining, and all sorts of other improvements that *every* app can take immediate advantage of. But, I think the marketing departments figure that "3D" is easier to sell than "Bigger cache and X more Mhz than competitor Y." Extra instructions are, put simply, extra work for developers to support. More Mhz ain't. Of course I'd prefer the CPU makers to do work instead of me-- who wouldn't?]

So, what's the consumer to do? In reading Brian Hook (at id)'s finger plan recently, I ran across this quote, which I'll borrow for a second:

--- snip
Your time is better served lobbying your video card driver manufacturers for 3DNow and KNI support. This will net, by far, the most gains in overall performance for the majority of users with PIII and K6 systems.
--- snip

I second that. That's basic optimization-- speed up the slowest parts of the system first: DirectX and 3D drivers. Of course, that doesn't mean our Pentium III code won't knock the socks off users, with "more, better, faster" looking stuff. We do a lot of pre-processing on polygons we send to the driver, and that code's nice and happy on a PIII. (This is part of the Dark Reign II shared engine code, so DR2 will also be PIII-happy.) Sorry, I'm not qualified to benchmark exactly how much faster things are, but it's a nice noticeable difference.


2/20/99: I've been scoping out video boards for my new gaming system at home-- I decided to stick with my existing Matrox Milennium II (PCI) and 3DFX Voodoo1 for at most 2 more months to catch some of the "next wave" of 3D boards. In looking at some spec sheets, I see mentions of 2048x2048 textures.... daaaayang. Less than a year ago, I was working on the Playstation whose *ENTIRE* video memory would be eaten by a 1024x1024 texture. [It's got a 256x256 max texture size, but 1MB is the entire video ram allocated.] Also, video boards with 32MB RAM onboard is double the *entire* ram size of my first pentium box I bought in 95. Stop this insane upgrade cycle, I want to get off...

Well, not really, but this really goes to show how 3D cards are doubling in specs about every 6-8 months. Now, what I need is a fairly reliable website somewhere that's got a roadmap of release dates on video boards through mid-April or so-- my usual suspects of anandtech.com and tomshardware.com don't seem to have such info. Anyone care to drop me a line if such a site exits?


2/18/99: I hope anyone who was at the Intel Pentium III launch event in San Jose this week took a look at BZ2, as we were shown along with tons of other games. [And a minor mention on Intel's website at http://www.adviceforpcs.com/showroom/index.asp ] Since Intel's officially saying we've got Pentium III/Katmai code in BZ2, I guess that cat's out of the bag. We're *still* backwards compatible, and the minimum system specs are still Pentium166 + HW 3D card; you will not need a P3 to run the game. [I've got an old PPro/200 on my desk for some testing, and it's running on that just fine.]

Now write all your favorite big gaming (and magazine) websites to ask them how great BZ2 looked at the launch, and how they should be writing about BZ2 among the other good games coming out. Hey, I'm not above wanting 'free' publicity, or at least a mention for games I'm working on :)

[I saw that avault mentioned 'Brunswick First Strike Bowling' for the P3, but I didn't see anything about us. Geez, I worked on Brunswick Bowling (precursor to this P3-enhanced one) while at another company, and we had to make it run on a P133 w/o 3D accelerator. One heck of an upgrade in graphics technology. Now if only Avault would mention BZ2 instead :P ]


2/17/99: I had an email related to BZ2, engines, gameplay (especially similarity to Heavy Gear 2), etc, and while writing a fairly detailed reply, I decided to archive it so that it'll hopefully unconfuse others. [Apparently, after the BZ2 irc chat a few weeks ago, the "big news" was what engines we weren't and weren't using. Personally, I look at gameplay, not what engine it's using, but to others, this is important or at least news.] Here's my reply:

--- snip
Nope, BZ2 is definitely closest to BZ1 in terms of look and play. The engine merely helps put polygons onscreen; we have a large chunk of the game's "personality" separated out from the engine. I think that the Quake, Unreal and Lithtech engines have done something of a disservice to the term 'engine', as games with them tend to look *and* play identically. However, gameplay is, in my opinion, something that can and should exist at a higher level than the raw engine.

A sorta tangent on "game looks": as all PC 3D cards start getting roughly comparable in terms of abilities, games have started looking similar to each other, if nothing other than the bilinear filtered look of all textures, etc. There's a stereotypical PC 3D game look, just like there's a stereotypical Playstation game look (slightly grainy), and a stereotypical N64 game look (blurry and foggy). All of those come from the underlying hardware, and mostly not the game engine. Yes, there are games that break the mold on all of the platforms I listed. But, I think those are really the exception, not the rule.

The 'Darkside' engine is being used for both Heavy Gear 2 and Interstate 82, and quite possibly others as well. I82 and HG2 play quite differently from each other, and that's because the gameplay isn't in the engine. What's possibly confusing to some is that the guy who started writing the Darkside engine, Julio Jerez, joined the BZ2 team last summer to work on parts of BZ2's code. [He's also credited in the BZ1 manual for 3D stuff, and he also worked on Interstate 76, so it's not like he's unfamiliar with our codebase.] While he may have brought expertise in 3D, he didn't bring the Darkside engine.

The Darkside engine is not used in either BZ2 or Dark Reign 2, so why should games play like HG2? Dark Reign 2 has its own engine (no fancy name I've ever heard for it, so I call it the DR2 engine). BZ2's engine is a mix of the DR2 engine for certain things and the BZ1 engine for some other things. Dark Reign 2 is in a number of ways the traditional RTS moved into 3D. In DR2, you are a commander *only*-- you tell people what to do, when to do it, etc. It's also got a darn nice 3D gameplay and interface with freely moving cameras in 3D, etc. In DR2, "you" don't ever fire or move around as a character, you're only the disembodied general giving orders.

BZ2 is just like BZ1 where you're a commander present in the game world. You're in a vehicle (or on foot), capable of blowing stuff up yourself, or being blown up, and you can also give tons of orders to your units. It can still be a fast action gameplay (we've been doing deathmatches around the office, and they sure ain't sluggish), and we've got some other stuff I can't talk about now. In watching others play the HG2 demo, I saw the "you're in a vehicle" aspect, but I didn't see the commanding of units aspect. Maybe that exists, but I'm unqualified to comment on it.
--- snip

Had 6 machines in a deathmatch last night-- nothing like getting large chunks of the BZ2 team running to expose a bunch of "this'll never happen" cases, including a packet caching bug that'd existed for months and never run into. When you've got 6 players with cool new weapon efx going off onscreen, it looks real pretty... I still get killed a lot when half of my mind is trying to look at some of the realtime logs for performance info, tracking framerate, and the like, and others are just out to kill.


2/15/99: Finally got unbusy enough with netplay code long enough to take a look a demo level running on one of our artist's machines. Man does it look SWEEEET. Those of you with nice big amounts of video (texture) ram are gonna love the way things are looking.

[This is one sorta problem of working on network code for weeks on end-- I know some deathmatch levels like the back of my hand, but don't see anything else. Oh well, maybe I'll see some other levels from magazine screenshots :]


2/13/99: Alright, call me arcade INcompetent. Or at least incapable of finishing the first training level in Tribes in the time alotted (25 minutes). Man do I feel annoyed at both myself for not doing 'simple' stuff, and the designers who think things like that are "good." Jumping puzzles BITE the big one, imho. Castlevania for the PSX did things right, imho-- very *few* timed jump puzzles required. Those of you at the recent BZ2 irc chat should know what handle I go by online. [And, as a real trivia question, explain its origin. No points if you were one of the folks who knew the long format of it when I was on irc.]

[And my P200 (no MMX) and Voodoo1 at home is just about minspec for games-- I had to turn down details a LOT. Ugh. Time to upgrade... and that means extra expense for an ATX case, new DIMMs, etc.]

Update, later 2/13.... 35 minutes of gametime, and I still can't freaking get to the third platform in the Tribes introductory singleplayer level. Sorry, but someone forgot to freaking playtest this silly thing, imho.

And even later, after playing several online games... Finally beat that silly platform puzzle. Tip: jump off the terrain in the NW to the highest 'big' platform, then it's an easy jump to the small platform with the switch. I *HOPE* that wasn't the way players were supposed to complete that ANNOYING mission.

I've figured out what I hate about that mission, and a bit of Tribes in general-- you're controlling a humanoid, but the physics (especially of deceleration) are floatier than some of BZ2's vehicles. When I'm on my own feet, I can stop on a dime, or a quarter if I haven't had morning coffee. Tribes' characters have *way* too much momentum, and take a full second to decelerate. I can expect this to be because that helps the network code (inertia keeps things going as they last were), but it's damn unrealistic at times.


2/12/99: Network code ran great in a release build-- no additional problems or quirks. [Unlike, say, simply building the silly thing for Release thru MSVC++ which required workarounds.] Milestone candidate archived while I go back to fixing a few joining order synchronization issues. Should get a nice 4+ player DM going around the office later tonight to really beat up on the game.


2/11/99: Network code has been nice and stable for tests for upcoming milestone and [CENSORED]. Respawning powerups in the deathmatch maps. Just a few small issues with some severely out of order join from queues-- should be about a 10-line fix tomorrow, and some new features to add to the Deathmatch DLL.

Wasn't a day for MS tools to work with or for us... MSVC++ fubar'd inline calls in a release build (first one we've done for a while; needed for the milestone and seeing roughly what the fps is on slower machines), then the VSS database (holding history of all source code) was acting rather funny just before I left. [Might as well leave when it's getting late and something that critical's acting up...] Files were getting truncated on checkin, some checkins weren't listed in hitory, etc. Blech. Now if only the DOJ will finish up telling MS where they should be going tomorrow... [Preferably somewhere they can hire a boatload of beta testers instead of lawyers with a spare billion $]

By the way, is anyone bothering to read this? Or do I just naturally talk into a void? :)


2/9/99: Wheee. Some deathmatches happening around the office now. It's now the designer's job to get the weapons balanced-- some are a little overpowering. Still want to muck with the DLL code, but that's been backburnered with important network issues.


2/6/99: Well, the N64 passed my requirement (just like any console or HW upgrade) of having 5 games that I wanted for it, so I got a N64, along with Zelda64 and Castlevania64. [3 other titles to be bought shortly] Castlevania's good, but a bit harder to get used to than C:SOTN for the PSX (probably the best 2D sidescroller I've played). Zelda's also rather good, but haven't played enough to fully get the hang of controlling Link... but will definitely keep playing.

BZ2's net code's coming along well; just exposing some bugs elsewhere in the code when certain actions are taken. The network code stresstests some parts of the engine that nobody else tests, so I'm the bugmagnet at work.


2/4/99: Dynamic join code looks happy; I had all 3 machines on my desk (it's normally 2, but I needed a third for the >2 client case) on speaking terms with things staying perfectly in sync for some of my own testing. Then, my boss wants to see how things go in a Deathmatch mission, so he joins a game... Having slightly more experience in the BZ universe than me, after some initial testing, he tries to blow up my vehicle. That exposed a bug that I'd never run into simply because I forgot to try blowing anything else up. D'OH! Keep forgetting the soundtrack to BZ2 is *NOT* _Kum Ba Yah_ :)

On the subject of music, when I got home tonight, I had a package waiting for me, CDs published by NSoul Records ( http://www.nsoul.com ) This ain't your grandparent's Christian music, and it ain't your parent's. [Well, not mine, anyhow] Nice, loud Christian Dance, Techno, Synthpop, R&B/Rap, etc. I've got at least 12 of their CDs now, and they're great listening when at work, along with stuff by _The Echoing Green_ ( http://www.echocentral.com )


2/2/99: After some time spent getting things working after the latest round of integration with the DR2 code, I'm back to testing the dynamic join code. [This is so you'll be able to jump into the middle of a game in progress and get the worldstate mirrored into your computer fairly quickly.] Debugging stuff like random # seeds being sent and synchronized on all sides, making sure everyone sees the new player as entering at the same time, other good stuff.

When dynamic joining's reckoned to be somewhat stable (I think it is with 2 players, working on 3+), will hand code over to others who are putting together deathmatch maps, and let others REALLY hammer on it. Should be fun.

While it's nice(?) to be basking in the warm glow of 3 monitors (from 3 boxes) at my desk here at work, remembering which keyboard and mouse controls which monitor are attached to which.... I need a neural interface to the three machines :)


nathan.j.mates@gmail.com