development

This month was a little hectic because I had final exams. Here's a progress vid:

• Added a prototype "grenade launcher". Note it simply launches those balls I need to actually fix the arc/speed and add explosions.
• Added code to generate arrows which get drawn to the screen
• Add a movement indicator to the screen, the black arrow is your input direction and the green your current velocity
• Separated the hud drawing into it's own file and generally improved working on the hud
• The debug renderer was only impelmented in isolation to the full game, but now it's integrated into the game. The orange outline on objects is the physics worlds representation of the game.

This month started out by implementing a debug renderer for Jolt Physics, because of that we got a cool wallpaper for you:

• Implemented a "stopwatch" class which can be used to determine the frequency at which things occur in game.
• Added a font renderer to the game, so we can draw text to the screen
• refactored the project to use testable submodules
• pulled out game loop structure to simplify code in main
• Added sound system and wind sound effect with gain relative to your velocity
• Added crosshair

This month, I've mainly been focusing on getting individual things working in isolation, so that I can start slowly integrating them into the game. I did some preliminary work with openal to get sound working in the game, and now I'm working on getting text showing up on the screen. Here's a timelapse I made when working getting sound working

Stuff like this was so trivial when using godot, but now I literally have to make it all happen either by hand (sometimes with help from external libraries), but it's usually always lower level.

At times this can be frustrating because it takes so long to get something that someone could actually recognize as a "game", but the main thing is that it's actually a finite list of things. Right now my list looks something like this.

• ability to draw 3d geometry
• ability to draw 2d geometry
• ability to draw arbitrary text to the screen
• produce sound
• interact with the world through input devices

The timeline for doing this is skewed because I have to also focus on school and other things right now, but I'm currently working on getting text to show up on the screen which should help a lot with giving players information about their movement etc and help with debugging.

So much has happended since the last update, good and bad, either way frag-z progress is moving forward.

To sum it up, during the last year I was mainly working and just trying to make ends meet and in my spare time doing what I could with the game. The main issue was godot, I wanted really good performance even on older hardware because I want anyone to play the game and for it to be bloat free. Godot was a detractor in that regard and having so many available features at my finger tips and weird architectural choices I couldn't bend made motivation to work on the project harder and harder to find.

Since last january I'm pretty sure I fleshed out the main architecture for how skills can be detected. I refactored the godot project into smaller sections and ran performance tests on windows mac and linux. The performance was not up to par and I abandoned godot for all of the above reasons.

Since abandoning godot I learned how to use blender to create my own models, re-learned c++ compiling, cmake, how to render using opengl, use shaders, load obj's into the game, learned bullet physics, unlearned bullet physics and learned the basics of jolt physics.

The current status of the game is that we have a game where there is gravity and you can move around and bump into the map, entirely without godot and just with c++.

this month started off with the very first game test, with Nel, coli, Jacques, Teeare and me, the game test went well and fun was had.

feedback

• hud scales up with resolution
• tab activated scoreboard
• deathmatch gamemode
• create deathmatch map (thinking sewer level)
• view direction of enemy players
• potentially add weapon model
• movement has some quirks
• movement reverses with A/D only movement
• circle hop with W only movement
• AMD support
• show movement stats on client
• show the velocity vector

plan

• death match

On 2023-01-05 I decided that Rulebook isn't the right name for the class, it should just be Match since a Rulebook shouldn't have methods, as it's only a book.

Notice that death match isn't actually that different from most points win, for example health can be considered points, and that whenever your points go below 1, then you will respawn elsewhere on the map with 100 points again.

• implement abstract Rulebook, then create Rulebooks for deathmatch and most points win
• in the deathmatch match, it will also contain the method weapon_transaction(source_player, target_players)
• create abstract match class(2023-01-04)
• create subclasses for actual match types(2023-01-04)
• add transaction method(2023-01-04)
• for now deathmatch will be timed
• remove the logic inside of the railgun, and simply use GlobalPlayerEvents(2023-01-06)
• move the fire check inside of the player
give the weapon a
• new map

in order to support the new game mode, we are going to build a new map oriented more towards death match

• more long flat areas to fight on, not as vertical as previous map
• more wedges that aren't steep
• projectile launcher
• create projectile launcher class
• implement the physics movement function
• implement check to see if it's collided
• implement explosion
• create a sphere at the explosion point, with explosion_radius
• for each colliding thing, if it's a player, then draw a ray from the blast origin to the center of the player, if it reaches that player, then we can apply a force to the player, also perform a transaction (no points lost if you shoot yourself, only to other players)
• We'll need a way to know who fired which projectile, so instead of embedding a reference to an entire player, we'll just add it to a group who's name is the id of the player.
• shotgun & lightning gun
• generalize the hitscan weapon, this generalized version has a method called get_spray_pattern which will returns a list of hitscan rays. It will also have a method called fire which iterates through the spray pattern and uses the referee to conduct a hitscan transaction.
• in order to play different sounds for the different weapons, more information needs to be added in players events pertaining to firing, we also have to specify which weapon is being fired.
• movement
• quake style movement
• turn of auto jump, implement queue jump
• we don't jump if we never received a false for jump pressed before the next time we hit the ground
• performance
• I've found that even running locally, it feels like aim is a little choppy.
• First I created a version of the game with everything except movement, aiming and a map stripped away, next I checked the rates of the mouse polling, movement, and process function, all are being clocked at 60Hz, I also checked to see if data was being trucated across the network, which didn't seem to be the issue.
• My conclusion is that this choppiness is chalked up to the latency introduced by the network, this will be eventually remedied by using client side interpolation.

first we will develop a thin slice through the whole game, that way we will have a minimal working game that can be played. this way we can get user feedback as fast as possible instead of building the whole game and then having to undo previous work.

the thin slice will be a version of the game where you can connect to a server online through a UI, be able to ready your players and then start the game, the game will be mpw with a single weapon (rail gun), rail gun beams will be rendered on the client side and a scoreboard will be shown. After 10 minutes the game ends and you are returned to the ready up state.

• slice

• client side
• send over keypresses, mouse deltas to server(2022-12-18)
• terminal with sensitivity command(2022-12-18)
• crosshair(2022-12-27)
• server side
• process keypresses and mouse deltas, send back rotation and position of player(2022-12-20)
• create a Match class
• contains the current state of the match preparation, live and complete(2022-12-26)
• the complete state shows the scoreboard for everyone for at least 30 seconds.(2022-12-28)
• contains a Referee class which monitors shots fired and allocates points to respective players
• it is aware of the current game type(2022-12-26)
• each step of the game, we can ask the referee if the game is over.(2022-12-25)
• scoring information passed along with high frequency info(2022-12-26)
• if the Referee says the game is over, we move to the complete state(2022-12-28)
• chat messaging service(2022-12-28)

• development

• after the slice is developed we will work on features in the order most requested by the users it will probably be in this order
• sound/visual representation
• new maps
• add the other weapons
• team based gameplay

• performance

• netcode
• don't send info if there is no delta

• infrastructure

• make discord server(2022-12-22)
• make website(2022-12-25)
• headless server
• aquire remote linux machine(2022-12-29)
• figure out how to compile game for headless(2022-12-29)
• create download section on website
• auto updater (long term)

review

this month was really good, I managed to get the game into a playable state in about a week. i built a map a system to run sound on the client, weapons, a referee system, messaging/commands and smoothed out movement.