{"id":26184593,"url":"https://github.com/noelwidmer/unity-gameplay-framework","last_synced_at":"2025-04-14T23:51:01.591Z","repository":{"id":179082037,"uuid":"87178202","full_name":"NoelWidmer/unity-gameplay-framework","owner":"NoelWidmer","description":"[deprecated] A gameplay framework to simplify Unity development. ","archived":false,"fork":false,"pushed_at":"2018-05-22T20:39:07.000Z","size":757,"stargazers_count":45,"open_issues_count":0,"forks_count":5,"subscribers_count":6,"default_branch":"master","last_synced_at":"2025-03-28T11:51:08.160Z","etag":null,"topics":["actor","controller","gameplay-framework","pawn","unity","unity3d"],"latest_commit_sha":null,"homepage":"","language":"C#","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/NoelWidmer.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null}},"created_at":"2017-04-04T11:23:00.000Z","updated_at":"2024-08-19T23:27:11.000Z","dependencies_parsed_at":null,"dependency_job_id":"ae565e08-792c-4986-9fd6-fada959d00d4","html_url":"https://github.com/NoelWidmer/unity-gameplay-framework","commit_stats":null,"previous_names":["noelwidmer/unity-gameplay-framework"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/NoelWidmer%2Funity-gameplay-framework","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/NoelWidmer%2Funity-gameplay-framework/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/NoelWidmer%2Funity-gameplay-framework/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/NoelWidmer%2Funity-gameplay-framework/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/NoelWidmer","download_url":"https://codeload.github.com/NoelWidmer/unity-gameplay-framework/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248981259,"owners_count":21193144,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["actor","controller","gameplay-framework","pawn","unity","unity3d"],"created_at":"2025-03-11T22:59:48.014Z","updated_at":"2025-04-14T23:51:01.572Z","avatar_url":"https://github.com/NoelWidmer.png","language":"C#","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Unity3D Gameplay Framework\n\n\u003c!--http://doctoc.herokuapp.com/--\u003e\n- [Introduction](#introduction)\n- [Glossar](#glossar)\n- [The Gameplay Framework Classes](#the-gameplay-framework-classes)\n\t- [General](#general)\n\t- [Controllers](#controllers)\n\t- [Pawns](#pawns)\n\t- [Player Managers](#player-managers)\n\n## Introduction\n\nAll objects spawned in a Unity scene are \u003ccode\u003eBehaviour\u003c/code\u003es. For local games we work with \u003ccode\u003eMonoBehaviour\u003c/code\u003es and for networking games Unity provides us \u003ccode\u003eNetworkBehaviour\u003c/code\u003es. Aside from those there aren't many abstractions where Unity supports us. I came to the conclusion that great gameplay support should be a feature that ships with the engine, finding myself abandoning projects because it doesn't.\u003cbr\u003e\n\nI've worked with [Unreal's Gameplay Framework](https://docs.unrealengine.com/latest/INT/Gameplay/Framework/QuickReference/) which I really like and therefore want to improve Unity's gameplay layer by adding some of the things I have learned from UE4 ([Unreal Engine 4](https://www.unrealengine.com/what-is-unreal-engine-4)). However, the existing \u003ccode\u003eBehaviour\u003c/code\u003e code base cannot be removed as it lies at the heart of the Unity Engine.\n\n## Glossar\n| Terminology   | Description           |\n|:------------- |:--------------------- |\n| Player        | A player is a real human. Note that AIs (Bots) are not players.      |\n| Participant   | Players and AIs can become participants when they request to join a game. Participants are taking part in the game and can interact with the world. They can have a huge imapact on the outcome of the game. A player spectator that is not able to interact with the world is not a participant for example. |\n| Authority      | The authority can either be a local client, a remote client (Host) or a server. A networking game has many actions that require to be authorized before they can happen. Win/Loose conditions are usually evaluated by the authority to prevent cheating for example.    |\n\n## The Gameplay Framework Classes\n\nThe Gameplay Framework consist of a few classes that help to structure gameplay logic. \n\u003cp align=\"center\"\u003e\n  \u003cimg width=\"638\" height=\"910\" src=\"./docs/ClassRelationshipDiagram.png\"\u003e\n\u003c/p\u003e\n\n### General\n\n#### Game Class\nThe \u003ccode\u003eGame\u003c/code\u003e class is a Singleton that provides general interaction with the game. \u003ccode\u003eController\u003c/code\u003es join the \u003ccode\u003eGame\u003c/code\u003e to become participants for example.\n\n#### GameMode Class\nThe \u003ccode\u003eGameMode\u003c/code\u003e only exists on the authority. The authority's \u003ccode\u003eGame\u003c/code\u003e instance contains the only \u003ccode\u003eGameMode\u003c/code\u003e across all participants. The \u003ccode\u003eGameMode\u003c/code\u003e constantly evaluates the \u003ccode\u003eGameState\u003c/code\u003e for new events that require authorization. It checks win/loose conditions as a common example.\n\n#### GameState Class\nAll \u003ccode\u003eGame\u003c/code\u003es across all participants contain a single \u003ccode\u003eGameState\u003c/code\u003e that is synchronized over the network. As the name suggests, this class contains the state of the game. However, not all information about the game must be stored in this class. Only data that must be autorized is required to be available in the \u003ccode\u003eGameState\u003c/code\u003e.\n\n#### ParticipentState Class\nThe \u003ccode\u003eGameState\u003c/code\u003e contains a collection of \u003ccode\u003eParticipantState\u003c/code\u003es. They contain the information of a participant that requires to be authorized. All participants have a \u003ccode\u003eParticipantState\u003c/code\u003e.\n\n### Controllers\nA \u003ccode\u003eController\u003c/code\u003e represents the will of a player or an AI. It can possess a single pawn at the time and/or become a participant by requesting a join.\n\n#### PlayerController Class\nA \u003ccode\u003ePlayerController\u003c/code\u003e is a controller that represents the will of a player.\n\n#### AIController Class\nAn \u003ccode\u003eAIController\u003c/code\u003e is a controller that represent artificial intelligence.\n\n### Pawns\nAn \u003ccode\u003eIPawn\u003c/code\u003e is an entity that can become possessed by a single \u003ccode\u003eController\u003c/code\u003e at a time. When possessed, a pawn follows the instructions of its \u003ccode\u003eController\u003c/code\u003e.\n\n#### MonoPawn Class\n\u003ccode\u003eMonoPawn\u003c/code\u003es are \u003ccode\u003eIPawn\u003c/code\u003es that are used for local play. They inherit from \u003ccode\u003eMonoBehaviour\u003c/code\u003e.\n\n#### NetworkPawn Class\n\u003ccode\u003eNetworkPawn\u003c/code\u003es are \u003ccode\u003eIPawn\u003c/code\u003es that are used for network play. They inherit from \u003ccode\u003eNetworkBehaviour\u003c/code\u003e and are currently not implemented due to a focus on local play for a first version of the Gameplay Framework.\n\n### Player Managers\n\u003ccode\u003ePlayerManager\u003c/code\u003es are associated by \u003ccode\u003ePlayerController\u003c/code\u003es and handle the interaction between the game and the players. \u003ccode\u003eAIController\u003c/code\u003es do not require \u003ccode\u003ePlayerManager\u003c/code\u003es because an AI doesn't require visual feedback.\n\n#### PlayerInputManager Class\nA \u003ccode\u003ePlayerInputManager\u003c/code\u003e reads the input from the input devices of its player and prepares the information for its \u003ccode\u003ePlayerController\u003c/code\u003e. It does not interpret the input but is allowed to make device specific corrections such as applying a deadzone to an analogue stick.\n\n#### PlayerCameraManager Class\n\u003ccode\u003ePlayerCameraManager\u003c/code\u003es are the cameramen in a game. Their main job is to position and rotate the camera correctly as well as performing any post-processing on the rendered image.\n\n#### PlayerHUDManager Class\nA \u003ccode\u003ePlayerHUDManager\u003c/code\u003e is responsible to display a player's HUD (Heads Up Display). \n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnoelwidmer%2Funity-gameplay-framework","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fnoelwidmer%2Funity-gameplay-framework","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnoelwidmer%2Funity-gameplay-framework/lists"}