SpaceDuel3D

Welcome to the SpaceDuel3D homepage! Here you will find the latest SpaceDuel3D source code distribution together with bug lists and release notes.

Want to submit a bug report or a suggestion? Before you write, please read this.

SpaceDuel3D is a small multiplayer game for Solaris and Linux workstations written by Gustav Taxén (nv91-gta@nada.kth.se). The aim of the game is simple: blow other spacecraft into smithereens while avoiding colliding with asteroids. SpaceDuel3D should not be considered a "real" game - it should rather be seen as a side effect of trying out ideas for a more advanced game. In due course (and if time permits) the experience I've gained from implementing SpaceDuel3D will be part of a larger project. But as it is, SpaceDuel3D shows that it is possible to use OpenGL for other things than scientific visualization and that it is possible to create simple OpenGL-based games that runs fast enough on a slow Pentium box without hardware graphics acceleration.

SpaceDuel3D is distributed under the terms of the GNU General Public License. See the file COPYING in the root directory of the distribution for more details. The graphics that are included with the game are also distributed under the terms of the GNU General Public License. This basically means that you may use, modify and distribute the code and graphics but that you can't include them in a commercial or noncommercial product that isn't distributed under the terms of the same license.

SpaceDuel3D comes with ABSOLUTELY NO warranty! THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. Please see the file COPYING in the root directory of the distribution for details.

Requirements

Solaris or Linux box - target processors are P90 and SparcStation 5.
Mesa 2.3 or later or any other OpenGL 1.1 implementation.
GLUT 3.5 or later.
gcc 2.7.2.1 or later.

Not required, but highly recommended:

Network connecting two computers meeting the requirements - playing solo is no fun at all.
Fast processor or graphics hardware supported by OpenGL - especially if you want textures.

Files

SpaceDuel3D.1.0b.tar.gz - Archive containing SpaceDuel3D version 1.0 beta together with source code and documentation.
SpaceDuel3D.1.0b.zip - Archive containing SpaceDuel3D version 1.0 beta together with source code and documentation. (In ZIP format.)
README - The README file for SpaceDuel3D version 1.0 beta.
RELNOTES - The release notes for SpaceDuel3D version 1.0 beta.

Known bugs and limitations - version 1.0 beta

It is possible to be spawned within another vessel or within a blast. The current respawn algorithm selects a random asteroid and places the vessel in a random position close to that asteroid. It doesn't check where other entities are. This will probably not change, unless it is causing lots of trouble for many people.
The Solaris version of the system call poll have problems detecting when clients disconnect. What happens is that poll says that there is data available to read on the socket. Thus, the Solaris server now detects client disconnects by noting that there is data available to read on the client stream socket. This works since the clients never send any data to the server through the stream socket, but it it possible that this may change in later versions, thus making it nessecary to go through the network code again.
The Solaris version of the system call read often returns -1 with errno set to EAGAIN, which (according to the manual page) indicates that some service is temporarily unavailable. The current network code simply calls read again when this happens, thus resulting in a large number of system calls. I'd be extremely interested to know whether someone has a solution to this problem.
The current network code does not include a facility to convert data sent from a little-endian machine to a big-endian machine (and vice versa). Therefore, it is very likely that Solaris servers can't connect to Linux clients and the other way around. This will be fixed in a later release.
Keyboard steering is not working the way I want it to at the moment. In order to be able to use the same algorithm for both keyboard and mouse steering, the current code works so that a keypress corresponds to 100% steering action, while the mouse steering can use 0-100%. Since GLUT can't detect key releases yet, the algorithm results in the weird "I can start rolling in both directions, but I can't stop the rolling" effect. This will be fixed as soon as GLUT includes a way to detect key releases.
There is no "security" in the network code. It is quite possible to swamp servers with a large number of client connection attempts. I'd be grateful for reports on how many clients that can connect before the game becomes unplayable on different setups. In a later version, I will set an upper limit to the number of connected clients. I'm also quite sure that it is easy to write stand-alone clients that breaks the game in different ways. Don't run servers on Internet- accessable machines that mustn't crash!
Size and density of asteroid field is fixed.
The code that draws the radar is rather ugly and very inefficient.
The radarInverseRotation function produces unexpected results. A quick fix is in place, but the function itself should be debugged.
The sphere generation code is rather ugly and probably inefficient.
Starfield needs a better algorithm.
The linked list module should include a list iterator. Some of the functions that allocates memory will fail on assert when unsuccessful instead of returning NULL.
The code in s_client.c breaks the module abstraction. A list iterator should be used instead.
s_simulation.c should be split into vessel, blast and explosion modules.
checkCollisions breaks the list ADT abstraction. List iterators should be used instead.
Glitches in the starfield textures can be seen when using 3Dfx.
Possible bug in Mesa/3Dfx driver makes it nessecary to use the depth test and clear the depth buffer on a number of occasions where it wouldn't have been nessecary. This causes the framerate to drop about 2 fps on a P90 without hardware acceleration.

Before submitting a bug or limitation report...

...please check the current buglist. It is possible that someone else already have discovered the bug you found.

Also keep in mind that SpaceDuel3D is in no way a commercial-quality game and never was intended as such. The basic rules and features of the game will (most probably) not change. Some things that won't be added even if reported as limitations are

Vessel model textures.
More than one vessel type or model to choose from.
Different weapons.
Power boost pickups (a la Quake's quaddamage).
Computer-controlled vessels (such as robots or drones).
Sound effects and music.
Chat mode (i.e. sending text messages between clients).
Windows 95/Windows NT version.

I will try to fix bugs that causes the game to crash, though. Suggestions that are easily implemented may also be part of later releases.

To submit a bug report or a suggestion, send an email to me, Gustav Taxén, at nv91-gta@nada.kth.se. Please put the word 'SpaceDuel3D' or 'sd3d' in the subject field - it makes it easier for me to maintain my mail.

Where to get more information

Gustav Taxén