|
Author Topic:   Development update
LDA Seumas
unregistered
posted August 16, 1999 06:20 PM           
We're getting some nice sculptural forms modeled up now. It's starting to look like every track might have its own unique set of starting post statues, from lions, to winged horses, to heads, etc.

Weapons are progressing (just got the high speed tank gobbling Drill spinning around), and the tank models are coming along. Networking is firming up for modem play over the net, though it hasn't been heavily tested yet (the next Test will be part of that phase).

The next big thing will be getting the user interface working. I hate GUIs. But it should look pretty cool if what I try pulling off works as planned...

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP:

LDA Seumas
unregistered
posted August 19, 1999 06:47 PM           
I finally seem to have everything working in preperation for real, honest to goodness Internet Multi-Player games. Server side "Rate" controls (each client configures their own) are now working almost perfectly, so the server will intelligently send less data to a client so as to not overflow the modem pipe, yet still make sure all the really important data (info on your own tank and things close by) gets through.

I had to implement a lot of mini-packet prioritizing (mini-packets are super low overhead packets internal to the game's networking, which are bundled together into more expensive, real UDP packets for transfer) based on distance from client, and general importance, so that the most needy packets get through first.

I haven't yet tried a) simulated lag or b) real modem based internet connections, but things are running well on the LAN with rates limited to 2,000 bytes per second, and the current client prediction code is handling LAN latency without apparent trouble. Real Internet lag could be a pain though.

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP:

LDA Seumas
unregistered
posted August 23, 1999 10:47 PM           
Phew, got a lot done yesterday. The Graphical User Interface is shaping up, and should look very cool. I've got a version of the Particle Fire code running into a texture in real time, which can be displayed over top of the screen using the 3D hardware. As you can imagine, it looks sweet. I'll probably have the particles swirling and dancing around the mouse pointer.

The entry deadline for the Independent Games Festival is coming up fast, so the next thing I have to get in is proper audio streaming to play back the cool music we're having produced for the game.

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP:

LDA Seumas
unregistered
posted August 25, 1999 09:06 AM           
Thanks to Aureal A3D 2.0 and the SEAL audio library, Tread Marks now has 3 distinct audio output options: True 3D sound through A3D2.0/DirectSound3D, fake 3D sound through DirectSound, and fake 3D sound through the WaveOut interface.

So with the next Test (and final game) there shouldn't be _anyone_ who can't get some manner of decent audio output from the game. A lot of people couldn't get sound to work properly with the first Test, so I wanted to be sure to correct it for the future. Thanks to everyone who provided feedback.

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP:

LDA Seumas
unregistered
posted August 27, 1999 04:47 PM           
The new GUI is really looking good. No more Windows Dialog Boxes! Buttons smoothly fade and fly on and off screen, there are nice backgrounds with the new Tread Marks and LDA logos, and of course the Particle Fire layer, with particles swirling around the rotating transparent glass mouse pointer and exploding when you click.

The neatest thing is that the normal menus can smoothly pop up over top of the game in progress. The ease with which I was able to get that to work surprised me. It's cool to have a unified interface; switching to a totally different rendering architecture for menus, and then having watered down in-game option menus kind of sucks, IMHO. I imagine a separated menu system would be the easiest way to go if the menus were being done by a different programmer, though. There are some advantages to doing it all yourself. <grin>

We've got everything pretty much ready to go for the Independent Games Festival entry version, which we'll be sending out Monday now. All the current loose ends and bugs are pretty much tied up, though I want to add a few more multi-player niceties (such as chatting and team play) before releasing the next Test, though. I'd also like to have a Master Server List set up on our web site before then, perhaps with a Perl CGI script, and of course the new dedicated Tread Marks web site.

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP:

LDA Seumas
unregistered
posted August 27, 1999 06:28 PM           
Oh, another interesting thing I forgot to mention. The menu system is implemented using the same C++ class based "Entity" system that is used for the rest of the game, which means that every style of button, font, listbox, edit box, background, etc., has a plain text .ent file with configuration options, thus making it possible to very easily change the entire look of the interface without any programming knowledge. I imagine people will have fun creating new "skins" for the interface, in addition to the in-game entities.

C++ Virtual Member Functions and Pure Virtual Interface Classes are Good. Don't be afraid of Virtual Functions; having virtuals only adds 4 bytes to each object, to hold a pointer to a global virtual function table for that class, and virtual function calls are still very fast. Once you play around with pure virtual interface classes, you won't want to go back. Most recently, I implemented a pure virtual Sound interface, and I can switch between two implementations of that interface (one for A3D 2.0, one for SEAL) with a change of a single pointer, and the application doesn't know any different.

The Entity system is also based around (mostly) pure virtual base classes for the EntityType objects (which store settings from the .ent files and load graphics and sound resources) and Entity objects (which are the actual entities in the world, with position, orientation, and other info). Adding new Entity classes that inherit some functionality from parents and simultaneously provide new functionality is easy. The game engine simply calls the Think() member on the entity, and the virtual function pointer passes the call to the appropriate function without knowing anything about the specifics of what that entity might be.

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP:

CheshireCat
Member
posted August 27, 1999 07:42 PM            
Out of curiosity, are you rendering the gui stuff (buttons, panes, cursor, and whatnot) using texture mapped polys, after setting the projection matrix to an orthographic one? Or are you using 2D pixel blits?

I've been trying to render GUI stuff under OpenGl by creating a texture that has a bunch of control "parts" (borders of buttons, etc) on it, and a texture with my font on it, and then piecing together the GUI with a bunch of polys. A bit of a pain in the arse =] I'm wondering how others do it.

CheshireCat

IP:

LDA Seumas
unregistered
posted August 27, 1999 08:03 PM           
I switch to an orthographic projection for all the interface and heads up display rendering, but I render using textured polygons in much the same way as the 3D scene is drawn. My orthographic objects are sorted by Z order and rendered with the Z buffer disabled. 2D pixel blitting functions are not very optimized on many OpenGL drivers, so texture mapped polygons are the best way to go for performance.

I'm doing fonts with all the characters arranged on one big texture, using textured quads to draw each individual letter on the screen.

One practical example of how the entity system makes things easier that just came to mind is the clickable nature of the GUI objects. I wrote a base GUI Entity Class that supported the notions of mouse over, clicked, and released/activated, along with slow creation and deletion (e.g. flying off screen and fading to transparent). All the specific GUI Entities inherit from the base, so I don't have to duplicate any code to have them all support being clicked and flying/fading on and off screen. (I know this is fairly basic for anyone who has experience with object oriented software design.)

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP:

CheshireCat
Member
posted August 27, 1999 08:12 PM            
Inheritence and virtual functions are our friends =] True dynamic classes are even more fun, if a bit impractical.

CheshireCat

IP:

LDA Seumas
unregistered
posted August 27, 1999 08:35 PM           
What do you mean by "True dynamic classes"? I'm not sure I follow.

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP:

CheshireCat
Member
posted August 27, 1999 09:01 PM            
Some languages (Smalltalk, and some others and can't remember) provide a mechanism that keeps track of all the class information for every object during runtime. An object can change who it's base classes are on the fly. An example would be a window object that changes itself into an icon by altering it's inheritance. I guess dynamic inheritance would be a better name.

CheshireCat

IP:

LDA Seumas
unregistered
posted August 27, 1999 09:09 PM           
Ah, yes. I imagine you would need a higher level language than C or C++ to do that effectively.

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP:

LDA Seumas
unregistered
posted August 28, 1999 01:59 PM           
In addition to the new sound system for Tread Marks having much more compatibility with different systems, it's generally better than the sound in the Test in a couple of other ways as well.

For starters I fixed a rather dumb bug that was causing sound to play at a much lower volume depending on the pitch angle of the entity creating the sound. I've also changed the way falloff with distance is modeled, so sounds that are close to you have more volume, and the world sounds a little more real. We've also added more sounds, fixed up some old ones, and made more of the explosions and other effects produce sound.

The camera is also much improved, which I may have mentioned before. What I might not have mentioned is exactly why, since it's a little embarrassing. Shortly before we released the Test I heard that Rollcage changed the camera zoom as you drove faster to improve the sense of speed. I thought that sounded like a cool idea, so I added it to the camera code, but I made it so the camera zoomed _in_ as you drove faster (this is what happens when CameraJazz is 100 in the Test). The problem is, that's totally backwards; zooming in actually makes things feel slower! It's zooming _out_ that makes things appear faster, as the scenery appears to slowly accelerate and then whip by at high speed as it gets close. In other words, once the Second Test is out, you'll think the tanks suddenly got a turbo boost. The (correct) effect really does feel fast.

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP:

LDA Seumas
unregistered
posted August 29, 1999 05:26 PM           
I spent most of the day yesterday experimenting with the SGI Software OpenGL rendering DLL, trying to improve performance. It looks like in the latest version (which is still pretty old, as the software renderer isn't actively supported anymore) 16-bit textures on a 16-bit frame buffer can be about as fast as 8-bit textures (paletted or 3-3-2), and even not much slower than an 8-bit frame buffer (and R3-G3-B2 is ugly, with only 8 levels for red and green, and 4 for blue, one of which is zero blue).

With one tank on the terrain, the software rendering gets about 10 fps at 640x480 on a P2-400. It jumps to about 30 fps at 320x240, and I'm keeping all the HUD and menu fonts big enough that the game will be playable at 320x240 res. It may not be that pretty, but at least it should run on systems with no hardware accelerator or old/broken OpenGL drivers (but then the inclusion of the wonderful GLSetup should fix most of those problems). A P200-MMX will probably be the bare bones minimum for software, and also about as low as you can go for hardware. It's been a long time since P200-MMX machines were new though.

The version of Tread Marks for the Independent Games Festival entry is pretty much in the can, as we were aiming to get it shipped out on Friday, but last minute bugs conspired to delay it till Monday. It should still arrive on time though, and this year they'll actually be playing all the initial entries (or we presume, since they want 10 playable copies right off the bat), so they won't be able to simply dismiss us based on the fact that we shun the Holy Design Document. But whether we get into the Festival or not, this deadline has helped to bring a number of aspects of Tread Marks up to snuff, so the next Test and the final game will be better for it.

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP:

LDA Seumas
unregistered
posted August 30, 1999 08:38 AM           
The CD-Rs for the Indie Fest are burned. Last (known) bugs squished. Ahh.

The Second Test is coming soon... Just need to make sure Internet networking is good to go, and launch the TreadMarks.com web site along with a Master Server handler so people can find servers.

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP:

LDA Seumas
unregistered
posted August 31, 1999 04:34 AM           
This topic is getting a bit big, so I'm continuing my development updates in this new topic:
/forums/archive/ubb/Forum2/HTML/000007.html

------------------
-- Seumas McNally, Lead Programmer, Longbow Digital Arts

IP: