When the server presses the "Start Game" button, the server changes maps, but the client does not. The client remains on the "Lobby" map. Both players can still see each other.

The walking animations work fine for going vertically or horizontally, but when walking diagonally in any direction there is no animation

An inventory system to be used with tasks etc.

Should have:

• Items visible in player hand
• Ability to drop and pickup items, with shortcut and a GUI icon
• Dropped items visible on floor, can be picked up
• Toggle-able based on other events
• One item at a time
• When holding an item, toggles off the kill mechanic

See https://github.com/opensuspect/design-document/blob/main/general_gameplay.md.

While it was already visible by default, with #26 it becomes really apparent that some sort of filtering (I assume bilinear filtering) is being used on the assets. I'm not yet familiar enough with godot to figure out if or where a setting is to set it to integer scaling.

Throughout the code, we use different names for the "teams" or "roles" the players get.

Based on the game design team's decision, the larger team, the default role should be called "agent" / "agents", while all smaller teams, who try to disrupt the main team's work should be called "infiltrator" / "infiltrators".

The variable names and comments throughout the codebase should reflect this for clarity.

Godot refuses to let you send remote procedure calls to yourself. When you move around, your x and y are sent to the server. if you are the server, godot spits out an error message.

The animations still work, but the textures are white. Trying to change any setting (including skin color) crashes the game. The appearance editor looks like this on an exported client:

@nicemicro discovered that the appearance editor is using .import files instead of the .png files. This is probably why the editor breaks when the game isn't in debug mode.

The players shouldn't be able to see players through walls, but they should still be able see the darkened environment. The players should probably have a limited visual range.

Create a new type of Node that can be placed into a scene. For the purposes of this spec, we will call it 'Player Spawn'. Upon entering the Main Game mode, the server will assign each player to an unoccupied Player Spawn, at random. That location will be used for the initial position of their character.

We need to revamp the killing system. What should be done:

1. an overlay for the target to kill (crosshairs maybe?),
2. a customizable keystroke + an on-screen clickable icon to commit the kill and
3. a customizable keystroke + an on-screen clickable icon to reload the gun which also might serve as the timer for the reload.

For details, see the relevant part of the design document.

When in the lobby, the background should be scrolling horizontally through the windows, to give the train the appearance of motion.

This is on hold until the game design and art teams can give us feedback about what appearance options will be customizable.

When the victory conditions are fulfilled for one of the teams, a victory screen should show up for the winning, and a defeat screen for the losing teams, which should show which players belonged to which group / team / role.
The system should be flexible enough to work in case of more than 2 teams.

Allow players to choose their appearance while in the lobby.

Initially implement as a button with a popup. For this basic version, we're more interested in implementing the plumbing. Allow the player to select an arbitrary color from a chooser, and save that to a place that will be persisted between scenes.

Later on we will receive input from the Game Design team as to a more interesting system (disguise kit? wardrobe interaction? opening your own dossier and "correcting" it?)

When starting the game (moving from lobby to the map), a short cut scene should be implemented that shows the player what role they got assigned to.
Should be capable of showing one's partner, too, if the secret faction (infiltrators) have more than one player.
Should be capable of announcing other roles, like detective, publicly known detective, etc.

Handling for the game to switch to the win/lose screen.

Should have:

• A system to handle conditions based on other in-game variables
• System to determine winners / losers, and triggers end screen accordingly

Conditions:

• Infiltrators win when number of infiltrators >= number of agents
• Agents win when tasks are complete
• Agents win when there are no infiltrators

See https://github.com/opensuspect/design-document/blob/main/general_gameplay.md.

Toggle on full screen mode, and attempt to start a game. You will notice all the content for the role screen is far off in the corner.

Acceptance criteria:

• After clicking Play Game:
  • Option to Create New Game
    • Local
    • Internet
  • Option to Join Existing Game
    • Server name or address

Woo, this is my first bug report!

Description of Bug:
Pressing exit from the keybinds menu whilst in a game, takes the player back to the menu screen, rather than back to the game.

Steps to reproduce:

1. Host a game
2. Open the menu, go Settings > Keybinds
3. Press the back button

For accessibility and customizability there should be a settings submenu for changing all keyboard (and mouse) bindings that are used by the game. Though not an urgent feature, it will help players using different keyboard layout. Especially if the text chat is a critical game component, using a different layout than usual would be very uncomfortable for some players.

Support for multiple keybinds on one action would be a feature to consider (e.g. allowing movement with WASD and arrow keys).

The implementation might be linked to and possibly dependent of #99.

Changed the screen resolution to 1920x1080 and since many of the ui nodes aren't properly set to centered/full rect/under a center container etc many things are moved to either off screen or to the side whenever screen resolution isn't 1024x600. This will become a big issue in the future if it isn't taken care of soon.

Way to reproduce:

1. Create a new game
2. Start the game
3. Go back to lobby
4. Go back to main menu
5. Create a new game
6. Start the game

Game crashes with error: Attempt to call function 'set_movement_disabled' in base 'null instance' on a null instance.
Where it occures:

func _clean_up():
	for id in PlayerManager.players:
		PlayerManager.players[id].set_movement_disabled(false)

the PlayerManager.players is a dictionary with one element that is NULL

Acceptance criteria

• Two rooms
• Player spawn points (#161 prerequisite)
• Some kind of texture on the walls and floors (programmer temporary art is okay)

Non-goals

• Any type of actual map design
• Looks good
• Any kind of mechanics

While the environment gets the dark overlay, the characters are still visible outside the light radius, including the names.

Right now the FSM only works server side, meaning game states aren't synced.

Create a finite state machine for the server to track the overall state of the game. It should be relatively easy to extend, but something like this is a good starting point:

A task type, that is never "started" or "finished", but constantly emits an output value based on some random input and some setting in the task interface (check https://github.com/opensuspect/design-document/blob/main/general_gameplay.md for reference).
The input value(s) should be constantly managed by the server, and task, where the setting is available, should provide the same interface with all players, so that should also be managed by the server. The output value should be also available to tasks that depend on the maintenance task, and certain values should trigger events such as warning sirens or even win / loss conditions.

There is a mock implementation of a gas valve task where the output should be regulated with a randomly changing input in PR#192.

Goals to be achieved:

1. The tasks should have a parameter whether their states are synced to all players or not.
2. Tasks should clearly define what variables define their state and these states should be synced with the server and stored there.
3. If a task is synced to all players, the server should update it for every player once someone changes it.

Players who are killed should die and became a spectator.

A system that allows the map to be interacted with. This would manage stuff like opening doors, and other map interactions. Features to include:

• Store a list of dynamic map objects (such as doors)
• Be able to receive signals from other systems, such as the task management system
• Be able to change the state of various objects on the map

Currently, the only ingame UI is made up of a few nodes in main.tscn. We're going to need a much more robust system than that. I think the system needs:

• A heavy focus on modularity (easily add new UI components to manage)
• Easy for other systems to hook into to tell it to show a UI component
• Keep track of whether or not a menu is open

I think a working pause menu from which you can return to the main menu, access settings, and close the game that uses this framework would close this issue.

A kill mechanic for players assigned as an "infiltrator". Used to kill others not assigned infiltrator.

Should have:

• Reloading (triggered by player, has a cool-down time)
• Adjustable range
• A shortcut, and a GUI icon
• Toggle-able based on other events

See https://github.com/opensuspect/design-document/blob/main/general_gameplay.md.

A UI menu/screen to show during meetings.

Requirements

• Allow players to vote on one another and to skip
• Have a timer to limit how long meetings can be
• Give players access to the chat during the meeting
• Show each player's appearance next to their name

Implement a flexible tasks system. This is a large system to implement, might take multiple people to tackle it, or one very dedicated soul.

Should have:

• Task assignment, based on role / randomness
• Interaction between player, task and map
• For exact details, see design document, linked below

An example task can be seen at this PR: https://github.com/opensuspect/opensuspect/pull/192
See https://github.com/opensuspect/design-document/blob/main/task_base.md.

In the lobby, players should be able to vote on the map they want to play on.

This can initially be implemented as just a button that opens a pop-up and allows players to select or not select maps. When the server moves to the "main game" phase, a map will be selected based on the votes of all players.

The game design team will later give input as to how this can be made more interesting. (Maybe each player has their own "train ticket", on which they choose the destination, giving a more diegetic map selection experience?)

Right now, the root node of main.tscn is scaled by a factor of .05. I think this is because the textures are so big that they would take up the entire screen if they weren't massively scaled down, but this is a poor solution. We need to decide on standards for image size and/or move a similar solution elsewhere, maybe by scaling down the actual Sprite node instead the entire scene.

A system that assigns tasks to players based on various conditions, such as game options or the player's role. Features to include:

• Store a list that contains every task and info associated with it (type, which UI menu, role it should be assigned to, etc.)
• Easily expandable with more tasks
• Tasks can be assigned based on their role
• Smartly distribute tasks among players
• Ability for tasks to be disabled and not be assigned
• Customizable (how many of each task/task type should be assigned)

A basic system to assign roles to players. Features to include:

• Easily expandable with more roles
• Scales by the amount of players in the lobby
• Customizable (how many of each role should be spawned/what percentage of players should be x role, etc.)

In order for the game to be playable, even in the most basic form, we need at minimum one working task.

A system to manage and store info about maps. This info would be the name, file directory, what tasks are available on it, etc.. Features to include:

• Keep track of every map in the game and info related to said map
• Switch maps

As it is now we are mixing cases in files and directories.
My suggestion is to change it to all lower case, before we have all sorts of standards.
example: /src/Assets should be /src/assets
src/Scenes/UI/PlayGame.tscn becomes src/scenes/ui/playgame.tscn

This would not apply to md's/txt's etc in root directory.

I have "version = 5" under testing, after commit 769f394.
I tested with three instances running.

First instance starts a game as server.
Second instance joins the game.
I press "start game" on the server instance. The red dummy character appears on the screen, the "Lobby" text disappears.
Third instance joins the game.

The three players see each other, but while the first two instances have the red dummy character on screen, the third one sees the "Lobby" text.

Problem

Right now, main.gd is a couple hundred lines long and is responsible for a ton of completely different things at once. It's handling network sync for movement, player appearance, and soon it will also handle it for items. This is on top of handling player spawning and killing.

Solution(s)

1. Break main.gd apart into multiple scripts, attached to nodes in main.tscn. These specific scripts/nodes would handle their respective tasks. One script would sync appearance, another would sync movement, another items, etc..

If you can think of another solution, please post a comment!

Currently the game is forced to 16:9 by black bars, either on top and bottom or left and right.
It would be good to support more aspect ratios.

I wanted to use it, but it didn't work. i never use TypeScript, so maybe it is because of that, but when i try to compile it, or install with npm it gives out errors and does't work.

A system to manage what needs to be done before a task is completed and what happens after it is completed. Features to include:

• Keep track of which tasks are accessible to the player (based on prerequisite tasks or player location)
• Prerequisites (allow for tasks require certain conditions to be met before they can be completed. For instance, a task to open a door which requires you to complete another task where you grab a key)
• Effects (opening doors, unlocking another task, etc.. Will need knowledge of the current map for dynamic map objects like doors.)

README.md and CONTRIBUTORS.txt are outdated, and could do with an update to better match the current state of the project. Updating the list of contributors by maybe putting names, then the teams they are active in might be a good idea. README.md could link to the website, nextcloud etc. Maybe it is also time to remove "Placey" the placeholder alien.

Right now connection handling is split between main.gd and network.gd, when ideally it should all be in network.gd. This includes names, version checking, etc..