The System Shock Hack Project is a project to reverse-engineer and recode (from scratch, but using the original datafiles) the 3D role-playing/shooter games from Looking Glass (System Shock and the Ultima Underworlds).The current virtual manifestation of TSSHP (it will probably never get a physical manifestation) consists of quite a lot of miscellaneous technical info on System Shock and the Ultima Underworlds, a software-rendered engine which is slowly coming up to speed, and quite a lot of blathering on mailing lists about AI, physics etc. Oh, and this web page.
The basic idea is to reverse-engineer and then re-engineer System Shock. Why? Well, partly to preserve the legacy of the great Looking Glass studios. Partly to bring a classic game up to date. But mainly because we think it's tremendous fun.
Download.
The 3D engine.
Development of a 3d first-person game can be broadly divided into the following categories:
- Technical
- Graphics engine
- Physics engine
- AI
- User interface (HUD, controls etc.)
- Design
- Level design
- Artwork (textures, objects, HUD)
- Testing
- Packaging, marketing etc.
Technical: Graphics Engine.
Believe it or not, this is actually the easy bit. After all, a polygon is a polygon is a polygon. he says, with the naïveté of somebody who hasn't actually tried it. One year on I'm thinking a little differently
System Shock, like the Ultima Underworld games which preceded it, uses a tile-based map. Unlike DooM and its ilk, which have a very small-scale grid and allow lines connecting any arbitrary points, the System Shock maps are 64x64 grids of quite large tiles. In this it resembles Wolfenstein 3D; however the UW/SS graphics engine is far more sophisticated allowing diagonal walls, variable-height and/or sloped floors and ceilings, and bridges and other objects which may be stood upon. A table might be useful here.
Graphics engines I have known and sometimes loved
| Engine | Grid | Walls | Floors/ceilings | Look up/down | 3D map | Objects |
| Wolfenstein 3D | Large tiles | Square blocks | Single fixed height | No | 2D only | 2D sprites |
| Doom/DoomII | Small 2D | Arbitrary | Variable height, flat | No | 2D, variable height | 2D sprites |
| Heretic/Hexen | Small 2D | Arbitrary | Variable height, flat | Yes | 2D, variable height | 2D sprites |
| Quake | Small 3D | Arbitrary | Arbitrary | Yes | True 3D | 3D models |
| System Shock | Large tiles | Square / diagonal | Variable height, sloped | Yes | 2D, can stand on objects | Mixed 2D / 3D |
Here we see that System Shock is not true 3D, but comes closer than the other pseudo-3D engines in the table. (Quake and its derivatives use true 3D engines). It is also the only game to use both sprites and 3D models for its objects. Unlike Doom and its derivatives, which have floors and walls always at right angles to one another, Shock surfaces can be at any angle. However, the map itself is basically 2-dimensional.
What does all this mean? In fact, very little for the purposes of the TSSHP engine, once we get the map loaded that is. All calculation is performed in 3D, and the renderer tries not to rely on the specific shape of System Shock / Underworld tiles (though the level loaders and some bits of the mapping code, and the automap of course, still do). Doom and Doom-alikes partition their maps into a tree of guaranteed-convex (really concave) "subsectors" using a Binary Space Partitioning algorithm. Fortuitously for us, however, the System Shock maps are already divided into convex subsectors; these are the tiles themselves.
At its heart, the current incarnation of the TSSHP renderer is a portal engine. This is something of a buzzword at the moment, but basically it means that the 3D world is partitioned into convex subsectors which are linked by portals: these are polygons through which the player can see from one sector to the next.
When traversing the world looking for sectors to draw, the engine starts off in the sector containing the viewpoint, and sets its current inclusion volume to the view frustrum for the screen (i.e. the interior of the polyhedron consisting of the projections of the four edges of the screen, plus planes to define a minimum and maximum draw distance. Say that again a few times slowly). Each time it encounters a portal, it is clipped against the inclusion volume and the resulting polygon, if any, is used to make a new inclusion volume containing only that part of the 3D world which can be seen through the portal. This provides an an elegant way of searching the world and there is no overdraw of surfaces.
The TSSHP renderer processes the world in 4 passes. First it compiles a list of potentially visible tiles (PVTs). This is a quick search without clipping against the individual portals: any tile which can be reached from the starting point through any number of portals without going outside of the view frustrum is included in the PVT list.
The second pass produces a partial ordering of tiles. This sorts tiles so that any tile appears in the PVT list before all tiles that can be seen directly through it. The reason this is separate from the previous is that there may be more than one route to a tile (set of portals through which it is visible).
In the third pass, tiles are processed according to the above partial ordering, and fully clipped by the portals through which they are visible, so that now only those tiles that can really be seen by the player are considered. Objects are queued here as belonging to the first tile in which they are encountered, so that they are drawn as far forward as possible. This isn't perfect, but will do for the time being.
The fourth pass traverses the world from back to front, and renders each tile. All drawable surfaces are backface culled and clipped, and if they pass they are lit, transformed to view space and passed to the back-end texture mapper. Then all the objects belonging to the tile (marked as so in the third pass) are rendered.
Screenshots.
If you liked this article, subscribe to the feed by clicking the image below to keep informed about new contents of the blog:
0 comments:
Post a Comment