A simple first person shooter that may or may not have anything to do with the concept of symmetry.
A simple first person shooter that may or may not have anything to do with the concept of symmetry.
The game has a similar struct to older games like Quake where the objective is usually to survive and get to end of the level while killing monsters/demons.
The game has a similar structure to older games like Quake where the objective is usually to survive and get to end of the level while killing monsters/demons.
The purpose of this project is to serve as an exercise in creating a game from the ground up using as few libraries as possible. The game uses the following
The purpose of this project is to serve as an exercise in creating a game from the ground up using as few libraries as possible. The game uses the following
libraries:
libraries:
@ -56,87 +58,151 @@ All the code in this repository is under GPLv3, see LICENSE for more information
## File format specifications
## File format specifications
- ### Entity
- ### Entity
The following example shows an entity definition. When saved into a separate file, this forms the blueprint for
an entity which can be used to create multiple entities that follow the same definition.
```bash
```JSON
Entity
{
# Comment, Sample entity definition in file, paremeters left out are set to defaults
# Comment, Sample entity definition in file, paremeters left out are set to defaults
# Empty line at the end specifies end of entity definition
type : 6
entity: "Something"
material : 0
position: 0 0 0
diffuse_color : 1.000 1.000 1.000 1.000
scale: 1 1 1
geometry : sponza.symbres
rotation: 0 0 0 1
specular : 1.0000
model: "suzanne.pamesh"
active : true
material: "blinn_phong"
diffuse_texture : default.tga
diffuse_color: 1 0 0 1
diffuse : 1.0000
diffuse_texture: "checkered.tga"
specular_strength : 1.0000
specular: 0.55
name : Sponza
}
```
When saving a scene that contains entities created from entity archetypes, each of those entities are saved as a "Scene_Entity_Entry"
to signify that these are to be loaded from a separate file. Example of a scene entity entry for the entity defined above might
look like this
```JSON
Scene_Entity_Entry
{
scale : 3.000 3.000 3.000
rotation : 0.000 0.000 0.000 1.000
position : -13.000 1.000 1.000
filename : Sponza
name : Sponza
}
```
```
- ### Configuration Variables a.k.a cfg-vars
- ### Configuration Variables
```bash
```JSON
Config
{
# Comment
# Comment
render_width: 1024
render_width: 1024
render_height: 1024
render_height: 1024
debug_draw_enabled: true
debug_draw_enabled: true
fog_color: 0.5 0.2 0.2 1
fog_color: 0.5 0.2 0.2 1
# There can be comments or empty newlines in between unlike entity definitions
ambient_light: 0.1 0.1 0.1 1
ambient_light: 0.1 0.1 0.1 1
msaa: true
msaa: true
msaa_levels: 8
msaa_levels: 8
}
```
```
- ### Keybindings
- ### Keybindings
```bash
Keybindings file contains the definition of all keybindings. Each "Key" block contains definition for
# All keys are parsed by comparing the output of SDL_GetKeyname
a named input mapping. The mapping can have two keys which can activate it. All keys are parsed by comparing the output of SDL_GetKeyname.
# Each line represents a keybinding
Move_Forward: W
The following example shows an input mapping called "Move_Down":
# Multiple keys to a single binding are specified with commas
Move_Backward: S,Down
```JSON
# Combinations are specified with a hyphen/dash
Key
# When specifing combinations, modifiers(shift, alt, ctrl) always come before
{
# the hyphen and the actual key comes afterwards. At the moment modifier keys are
mods_secondary_alt : false
# forced to be on the left side i.e. Left Control, Left Shift and Left Alt.
key_primary : E
Quit: Left Ctrl-Q
mods_primary_ctrl : false
# Single modifier keys are allowed but multiple modifier keys without corresponding
mods_secondary_shift : false
# non-modifier key are not allowed
key_secondary : NONE
Sprint: Left Shift
mods_secondary_ctrl : false
mods_primary_shift : false
name : Move_Down
mods_primary_alt : false
}
```
This can then be used from within the game with:
```C
enum Key_State
{
KS_INACTIVE,
KS_PRESSED,
KS_RELEASED
};
// Returns true if the state of the input mapping matches the parameter 'state'
// which should be a value from the enum "Key_State"
bool input_map_state_get(const char* map_name, int state);
```
```
If no keybindings are found when the game launches, the game generates a file with default key mappings.
- ### Level/Scene
- ### Level/Scene
- A Binary format with header attached at the top
A scene file consists of definition of global scene parameters in a "Scene_Config" block along with the player definition.
- Save child entities first
This is then followed by entities which can either be a Scene_Entity_Entry or just a plain Entity.
- Copy paste all entites in the file one by one. Since the entites all look
Scene_Entity_Entry refers to the filename from where the entity should be loaded first and then have the parameters
the same in memory and are made up of tagged unions, a simple memcpy approach
within the Scene_Entity_Entry block applied to it.
should suffice. The problem is entity heirarchies. There are multiple approaches to
solve this problem.
Every scene alwas contains a default player which is defined in code however a Player block contains definitions
- Save a sorted list of entites to file i.e. before saving create a new list that does
for player attributes that are applied to player when the scene is loaded.
not have the empty array slots in the entity list and then just copy and paste. This
is the simplest way to solve the problem as we don't have to worry about indexes of
The following example shows a scene with the player and a light entity called "Test_Light":
parent/child entites in heirarchy. We can take the whole array and paste it to the
file but creating a copy of entity list for this purpose only would be slow and consume a lot of memory.
```JSON
- Instead of creating a copy of the entity list for sorting and saving, sort the actual entity list
Scene_Config
and update all references as necessary then save the array to file.
{
- Just write the name of the parent entity as parent. Make sure that all entity names are unique.
debug_draw_color : 0.800 0.400 0.100 1.000
- Use separate EntityDefinition file that serves as a blueprint/prefab for the entity
fog_type : 1
to load/save. When the entity is saved in a scene file, the scene file only needs to
fog_density : 0.1000
refer to the entity's EntityDefinition file/asset along with it's parent and children
fog_color : 0.170 0.490 0.630
- This approach requires seperating a scene into mutable/immutable parts.
debug_draw_physics : false
Meaning, entities that can change their state during the duaration of the level are
fog_start_distance : 10.0000
mutable and those that remain the same as they were defined in their EntityDefinition
fog_max_distance : 450.0000
file are immutable.
debug_draw_enabled : false
- In each level there going to be mutable entites i.e player and player's position/orientation, objectives
debug_draw_mode : 0
cleared/remaining, doors opened and puzzles solved etc. Instead of handling all of these in the
ambient_light : 0.100 0.100 0.100
scene file, we save all the mutable state in the savegame files. When restoring game's state from a save name we will need
}
to handle loading of a scene and then applying the mutable state to entites after loading.
- Entities can have (a fixed number of?) properties. Each property has a name and a corresponding
Player
variant value like, health or ammo etc. But, how to save/load all of that?
