From NetRace

Net Racers

Technical Features

• 3-D engine. Our graphics engine was built upon the DXUT framework
  • The DXUT framework is a brand new addition to the DirectX SDK. It contains a layer of helper functions allowing for rapid prototyping with a solid DirectX implementation. The DXUT provides:
    • Simple 3-D device creation and deletion. Most DirectX wrappers provide a minimal implementation, removing features that you would like to use. Not so with DXUT. Creating a device with DXUT is simple, and yet allows you to create a device in any fashion you wish, including:
      • Choosing any 3-D device in your system, not just your default.
      • Choosing any resolution and bit depth supported by that device.
      • Choosing between windowed and fullscreen, instead of only allowing fullscreen.
      • Choosing your Z-buffer and depth stecil options, instead of choosing whatever is standard.
    • Simple device reset. Changing resolutions and switching between windowed and fullscreen usually aren’t supported by most DirectX wrappers. DXUT handles this gracefully. DXUT will reset the device when needed, and only destroys / re-creates the device if it has to. Callbacks are provided to allow you to handle device reset on your assets with ease.
    • 3-D Mesh handling. D3DX provides functions for managing .X mesh files and textures. DXUT takes it one step further by combining the mesh, textures, and materials into a single class. Loading and rendering static meshes from standard .X files is simple.
    • Menu system. DXUT has a full menu system complete with every type of UI widget you’d expect in Windows. Implementing menus is very easy, and handling input from the menus is straightforward. A menu system is usually re-written from scratch by every studio. And most of the time, it’s done the “wrong way”. It’s nice to see a standard menu system that contains all the UI widgets you’d need bundled with the SDK.
    • Settings dialog. DXUT has a built-in settings dialog, built using the menu system, allowing you to change device features during runtime. Things like changing resolution, bit-depth, vsync, depth-buffer are handled automatically within this dialog.
    • Basic keyboard and mouse input. DXUT provides simple input functions for keyboard and mouse. However, the functions aren’t advanced enough to base your entire engine on them (joystick support noticeably missing), but it does provide a starting point for rapid prototyping.
    • Primitive Sound functions. DXUT provides simple functions for loading and playing sounds. Advanced sound support is still missing though (3-D sound, MP3 support, etc).
  • Shader Support. Vertex and Pixel shader support was added. Shaders in HLSL .fx format are supported.
• Physics simulation. All physics in the game was made possible by a physics engine we integrated into the system. Features provided by the physics engine were:
  • Simple Rigid Dynamics. Standard feature of any physics engine, this provided simulation of gravity, and objects bouncing off each other.
  • Vehicle physics. The engine provided for a complete vehicle simulation, providing for realistic vehicle dynamics.
  • Heightmap support. Instead of representing the heightmap as a poly soup, the engine provided support for representing the ground as a heightmap internally. This gave us less overhead on the system and a less error with respect to the simulation.
• Game Object System (GO). The GO system is the way objects are represented in the world. A GO is a container for Game Object Components (GOC). A GOC is a simple, non-hierarchical class that performs a single function. This allows flexibility for creating objects without creating a complex class hierarchy. A GO is simply made up of a list of components. You can add or remove any component you wish, giving you the freedom to create many different types of objects. Under a class hierarchy, this sort of flexibility is hard to support because you have to worry about which objects you are affecting further up the chain.
• Network engine. Considered the main focus for the class. Here we implemented a client-server networking interface from the ground up, using Winsock. Features of the networking engine:
  • Interface independent. Our network design abstracts the low level network code into its own interface. We implemented our interface in TCP/IP, however it could have been implemented in any network technology (for example UDP or IPv6). We have already started prototyping an interface based on Microsoft's new PNRP network technology.
  • Message support. We have implemented around twenty game-independent message types, with the ability to eaily add more when needed.
  • Large number of clients. Our network desgin has no inherent limit to the number of clients that are supported. Our only limitations are those relating to the protocol being used, and available CPU/network bandwidth.
  • Networking physics. Our physics system doesn't actually travel across the network. We run all physics simulation on the server. Clients send input data to the server and the server sends out object positions.
  • Game Announcement and Lobbies. When a server is created, it starts sending out a very low bandwidth heartbeat broadcast to annouce its presence. Clients listen for this heartbeat from all servers so that clients can choose which game to join. Once a client joins, the client enters the lobby where all the players wait for the game to start.
  • Chat. Chat is supported, and chat box is provided in the lobby for discussion between clients.
• Heightmaps. We created our Heightmaps in Bryce. We exported height data to .pgm, and render data to .x and .dds.

Asset List

• Our assets were taken from various sources:
  • The cop car  ??
  • The jeep  ??
  • The race cars were taken from Microsoft GDC demo discs and the Microsoft DirectX SDK
  • The shaders were taken from Microsoft GDC demo discs and the Microsoft DirectX SDK
  • The sounds  ??
• All other assets were either created by our team, or was found in the public domain.