Right now player_manager has some variables about it's movement that can not be changed by map makers:

const SPEED: int = 5
const JUMP_FORCE: int = 8
var jumps: Array[bool] = [true, true]
gravity += 20 * delta

The only things the map maker can change are the player_movement, and if player shoots semi-automatic or machinegun:

[settings]
player_movement = true
shoot_machinegun = false

And when PlayerManager script wants to check if it has a machine gun or semi-automatic or if it can move it has to constantly check:

if Global.current_scenario and Global.current_scenario.shoot_machinegun == true:

This is bad because:

• Map makers can not customize player movement settings.
• PlayerManager has to constantly check the Global.current_scenario which feels very odd and introduces a lot of copuling of two things that shouldn't be coupled.

How to fix it

Let's introduce some new variables:

[player]
movement_enabled = true
speed = 20.0
jump_force = 10.0
max_jumps = 4
gravity_force = 30.0
shoot_machinegun = false

And then, the PlayerSpawner should be the one that just checks once the Global.current_scenario settings and initializes the PlayerManager with the correct variables. So PlayerManager doesn't have to couple to the Global script.

Another thing that should be improved

By the way, I'm also thinking that scenarios should only override the settings they need to override. For example many scenarios have the same default score settings, and the same default player movement, so maby is not necessary to define these variables for every single scenario that just uses the default.

[settings]
time = 30

[player]
movement_enabled = true
speed = 20.0
jump_force = 10.0
max_jumps = 4
gravity_force = 30.0
shoot_machinegun = false

[score]
score_per_hit = 1
accuracy_multiplier = false

• Horizontal targets: All targets spawn at the same
• Moving targets: Targets move in random
• Random targets: Random static
• Tracking: Keep your aim tracking a target.

The selection of default scenarios probably could be a lot better, I didn't put much thought into it when I originally created them, I'm open to suggestions about what posible scenarios could be added.

• There shouldn't be too many default scenarios, maby around 4-8 is a good number, making too many would be hard to maintain.
• The default scenarios should be really unique, and serve unique purposes, in case anyone wants a "slightly tweaked" version of a default scenario, that person could tweak it by themself.

I don't really play any aim trainers other than LibreAim, and I would like to buy some aim trainers (like Kovaaks) on Steam to learn in what areas LibreAim should be improved. Probably a good approach would be to just see what the most popular scenarios on other popular aim trainers are, and just try to replicate those.

The "humanoid" target shape doesn't have any animations yet, but they could technically be added now!

Also none of this is documented yet, and it should be.

You should be able to have targets with other shapes, right now i'm thinking mainly Cubes, and Humanoids.

• This system should have support for adding more shapes in the future.
• Maby in the future some map creators want to add their own custom-shaped Targets, so this must be keept in mind when when implementing this.
• Keep in mind that targets have a custom material so users can customize the target color, this functionality should be kept.
• If there are going to be humanoid targets, maby it would be cool to:
  • have animation support for those.
  • have some way of distinguish at which part of the body you shot at.
  • its spawn point pivot should be at its feet, this will make it easier for map makers.

I like this humanoid model, is low-poly and cc0! https://comp3interactive.itch.io/low-poly-human-mesh

The "scenes" folder

Some time ago I had a long conversation with my co-workers about how we should structure Godot projects.

First of all we decided that a "Feature-based organization" where you have folders for each feature like player_character/, enemies/, levels/ works better for us than a "Type-based structure" where you have folders for each type of asset like scripts/, sprites/, sounds/, scenes/.

This is very convenient because Godot works by itself in a very modular way and almost everything in Godot is just a Node, so we started having a folder called scenes/ where we keep all our modules.

But one of my co-workers thought it was odd to have a folder called scenes/, when its purpose isn't really just to host Godot Scenes, but modules of the project. And I agree with that, so we started calling this folder src/ but this is also an odd name since it sounds like "source" and doesn't communicate well its purpose. So we decided to call this folder modules/.

There are some other good names for this folder, here are some suggestions:

• modules/ or features/: I like these names.
• No folder at all: Is also a good option but you will end up with too many folders on the root of the project.
• src/, source/, core/: Doesn't communicate very well its purpose.
• systems/ or components/: this sounds good but is an odd name since it suggests an Entity Component System when you may not be using that.
• domain/: from the domain-driven software design, maby a bit too abstract for my taste, and you may not been very strictly using a DDD design, so not the greatest name in my opinion.

Currently LibreAim has a folder on its root called "scenes" this is because I created this project before I had this conversation with my coworkers and really thought about this. So this folder name should be changed.

Too much coupling and too little cohesion

Right now, some core parts of LibreAim have too much coupling, and too little cohesion, I'll try to explain why.

Right now the scenes/ folder looks like this, and this looks very bad:

├── autoload
├── game_world
├── main_menu
└── target

Let's start with main_menu this folder hast too many responsibilities, mainly the main_menu/settings/ folder that contains all the stuff related to user custom settings. Settings should be it's own module, since now I want to be able to show game settings on pause menu #19 but it feels wrong since it's currently structured as a sub-module of MainMenu instead of Settings been it's own thing.

The same thing happens to game_world/ in this folder we have many things like the main first person shooter Player controller, many UIs like the EndGameUI, GameplayUI, PauseUI, and many systems like the BulletHole that you leave when you shoot at, and sample_world_geometry.tscn which is the 3D level where player is during the game.

It can make sense that they are categorized all under the umbrella folder game_world/ since they are all indeed things that are only visible when you are in the "game world" but they are not properly modularized. This is not a collection of independent modules, this folder is a root game_world.tscn that connects to too many submodules so it hast little cohesion, and all those submodules are highly coupled to the main game_world.tscn scene.

As you can already tell that the target/ it's on its own folder while the rest of things like this are under game_world/, this is just odd.

All of this can be improved!

It would be nice if these could be used by screen readers for accessibility reasons using Godot Access Kit!