View source for Beginner's Guide to Atomech Architecture


= Player and Monster Code Layout =

[[File:TechnicalInput Creature.png|right|thumb|border|Player and Creature file structure]]

All creatures are broken down into the following sections:

# *Prefab*
#* This contains the character's Unity created portions
#** Root
#*** XXX_Controller component
#*** Default AI Module
#** Spine GameObject (SpineFile)
#*** A variety of bones exposed for use by the gameplay system.
# *Controller Code*
## HammerKnightController.cs - the file that links them all together
## HammerKnightController.Abiliites.cs - the file that contains ability scripts
## HammerKnightController.Branches.cs - the file that contains the state machine for animation and combat
## HammerKnightController.Data.cs - the file that contains the combat data (damage, cooldowns, reaction stun time)
## AI_HammerKnight.cs - a special combat-only module that drives the controller input for the HammerKnight character.
# *Database* 
# There's a JSON database file that all characters point to which initializes their Properties table.

= Input Architecture =

[[File:Atomech Control Structure.png|right|border|thumb|Atomech Input]]

Atomech game characters can have a variety of inputs:

# DirectControl - source directly from a Controller
# NetworkControl - source driven by a remote server
# PossessionControl - source driven by another unit in the ecosystem
# AIControl - source driven by a simple module or state machine on the server

The above is an example of how objects can source input. In general, each unit is assigned an appropriate behaviour module by either being spawned with it (AI) or assigned it by a delegator that Alex hasn't written yet. 

In the future, this delegator will keep a local list of devices, when they are used, assign them to an available creature and allow players to jump in and enjoy. 


== Network Structure == 

'''This section is out of date as of the recent iteration where we attempted to use TrueSync from Photon. The concepts are reasonable to reuse though...'''

[[File:TechnicalInput NetworkV2.png|thumb|right|border|Client and Server UNet concepts]]

Atomech currently uses UNet. In order to support both client-side couch co-op and networked remote play. As a result several concepts are required to understand how input goes from a player to the game. In a nutshell, understanding Atomech's input is as simple understanding that a lot of work is done to map an '''InputDevice''' to a '''ControllableUnit'''. 

=== Classes / Components ===
* '''InputDevice''' - This is InControl plugin structure created to represent a controller.
* '''PlayerInputBinding''' - This is a collection of Keybindings assigned to a gameplay action. (Attack, Jump, MoveLeft, etc).  A special one is created for the Keyboard.  
* '''LocalDeviceManager''' - This is a client side structure which collects all InputDevices as a button is pushed on each. 
* '''LocalDeviceID''' - This is an enumeration to describe a generic ID for a given device:
*# Keyboard
*# Controller1
*# Controller2
*# Controller3
*# Controller4
* '''LocalSeatNumber''' - The concept of a Seat is a single human being. A given client may have 1-3 Seats.  Devices are assigned to a Seat automatically. 
* '''LocalSeatManager''' - This connects LocalDeviceIDs to a specific NetworkInput object.
* '''NetworkInput''' - Also known as the "PlayerController" one of these is created by the server and sync'd across the network. 
** These can execute [Command] by default.
* '''NetworkPlayerManager''' 
** TL;DR - This specialized manager is the Server authority on which players are connected and handles general networking. 
* '''UnitManager''' - This maintains the map of which server player numbers map to which unit. The server version is authoritarian and the client versions should be read only or used to request a new unit.
* '''ServerPlayerNumber''' - This is the unique number (1-4) for the Player. This maps to the traditional concept of Player1, Player2, Player3, etc.
* '''ControllableUnit''' - This class defines a type of unit which can be controlled by a client. The ServerUnitManager decides who is a valid unit and assigns one to each ServerPlayerNumber.
* '''NetworkIdentity''' - This is a unique identifier for every entity created by the server. It's a component that basically holds the ID and a bunch of other random stuff, like the connection pipe (socket) to the client or server.

== AI ==


[[File:Example AI Modules.png|thumb|left|AI Components]]
Atomech AI is its own hierarchy - commonly used features are collapsed together for quick reusability. 

Drop a prefab for a creature into the scene, then attach an appropriate AI component for how you want it to behave! 

Future Components should have spline movers, sequences and other things... someday.