Internals

Internal Components

OpenSpades is made of several important components. Here's a partial list of them:

• Core
• [C++] Dispatch Queue - distributes given tasks to multiple CPU cores. Similar to OS X's Grand Central Dispatch.
• [C++] Backtrace Tracker - traces function calls to provide activation records (backtrace) in case of an unexpected error.
• [C++] <- AS Settings - manages configuration variables (aka cvars).
• [C++] File Manager - manages access to multiple file systems.
• [C++] File System - abstracts one directory tree.
• [C++] Bitmap Codec - Decodes/encodes bitmap images.
• [C++] Stream - abstract class which involves the following fundamental operations: read/write/seeking.
• [C++] Audio Stream - a read-only stream that is used to decode audio data.
• Presentation Layer (interface between code and user)
• [C++] <- AS Audio Device - receives audio commands and plays sound. An audio device might use the spatial structure of the game map for better auralization.
• [C++] <- AS Renderer - receives renderer commands, draws everything needed, and shows the rendered off-screen image to the user. This is implemented using C++ code, though this is accessible by the script. Script needs a handle to the renderer to access.
• [C++] Runner - creates renderer and audio device, and pass them to the initial view. A runner also handles input events that comes from the window system and converts them into the format that views accept.
• Abstract User Interfaces
• [C++] View - (new in 0.0.10) an abstract object that is responsible for receiving input events and managing operations that is required to do in each frame. A view might delegate some events to the subview. Note that although some views let script handle events, views are not accessible from script.
• [AS] UI Framework - simple GUI toolkit designed to work on the renderer interface.
• [C++] <- AS Font
• World Objects
• [C++] World - encapsulates the state of the game world.
• [C++] <- AS Game Map - encapsulates the state of game map.
• [C++] Game Map Wrapper - mediates the access to the game map for floating-block detection.
• [C++] Player - encapsulates the behavior of a connected player.
• Game Logic
• [C++] Client
• [C++] Network Client
• [C++] Client Player - encapsulates the visual of a connected player. If the player is Model of MVC, the client player would be View.
• [C++] Local Entity - Client-side object that has no corresponding in the server-side. This includes grenade smoke and tracers.

Legends: [C++] = implemented using C++, <- AS = accessible from script

What happens when I play this game

0.0.9:

1. Game executable is loaded by the operating system, initializing some data sections.
2. List of script-visible objects is created using the constructor of ScriptRegistrar.
3. Now we enters main function.
4. Core features (backtrace tracker, dispatch queue) are initialized.
5. Read-write file systems to access non-compressed resources are initialized.
6. Now writable file systems are ready, so we start recording output messages (SPLog) to the log file.
7. Pak files are scanned, sorted, and registered as zip read-only file systems.
8. Script engine is initialized. All script-visible objects are registered to the script engine.
9. FLTK is initialized.
10. Main window is created and becomes visible.
11. OpenGL capability is checked by creating a small OpenGL renderable window.
12. User clicks the connect button.
13. A runner is created.
14. The runner initializes SDL, renderer, and audio device. At this time, renderer only initializes 2D rendering subsystem.
15. The runner creates client by passing the created renderer/audio device objects.
16. The client loads some images to render the loading screen.
17. The client initializes in-game UIs.
18. The client draws the loading screen.
19. The client asks the renderer for the full initialization.
20. The client creates a network client and initiates the connection to the AoS server.
21. During this, ENet library is initialized. And then ENet host object is created.
22. After receiving the map data, the network client decompress and decode the map data.
23. The network client creates a world object by passing the map.
24. The network client creates player objects and registers them to the world object.
25. The network client gives the world object to the client.
26. The client gives the map of the world object to the renderer and the audio device.
27. The renderer initializes map-rendering subsystems.
28. The renderer registers itself as a game map listener.
29. The client creates the client player objects that correspond to the player objects.
30. The client player invokes the skin script to create the skin renderer.
31. The limbo window and scoreboard is displayed.
32. User selects a team and weapon.
33. ExistingPlayer packet is sent to the server.
34. The server sends CreatePlayer and StateData packets which include the local player index.
35. The client player is created for the new local player.

User Interfaces

• Main Window - startup window that allows users to configure the graphics options and access server lists. This is implemented using FLTK, not through the renderer interface nor UI Framework.
• Main Screen - new startup screen implemented in 0.0.10. As the main window, this also contains server lists and options, but configurable options are restricted because the renderer is already initialized when the main screen is loaded. This is implemented using UI Framework.
• Setup - new quick config screen implemented in 0.0.10. This is implemented using UI Framework.
• In-game Menu - new menu window implemented in 0.0.10. This is accessible by hitting ESC during the game. This is implemented using UI Framework.
• Say Window - This used to be implemented using C++, however, in 0.0.10 this is implemented using UI Framework.
• Scoreboard - implemented using C++
• Limbo Screen - Weapon/team switcher implemented using C++.