The GalaxSys sample project includes several assets which can be used for your own projects in CRYENGINE, along with a suite of extra components to ease development of your game logic. The idea is that you can use this sample project as a base for similar games, by leveraging the added components or simply expanding upon the current framework provided.
You can also delve into the code behind this project to learn about various systems and how to interact and expose various systems used in CRYENGINE. The purpose of this document is to provide a high-level overview of the project's general design and make-up.
The first thing you may notice when opening the level is that the layers do not contain many objects.
Level layers
This layer is used to hold entities that contain logic, or that are required in terms of stable gameplay.
The Audio layer simply houses the Music Entity.
This layer holds the Environment Probe.
The Arena layer holds all the static objects in the level, including the wave grid particle effect.
Most of the Entities in this project consist of Visual Scripting Entities, which can be crafted using the Visual Scripting feature of CRYENGINE.
In CRYENGINE 5.6, these entities are known as Schematyc Entities that use the experimental version of the Visual Scripting system. Here we briefly look at each Scripting Entity without going into too much detail. If you want to know more about how these Entities interact with each other, we advise opening them up and playing around with them.
Entity Assets
Various Entity components have been added to the sample project to enable much higher flexibility in development and feature iteration.
Almost all of the Entities used in the sample project make use of one or, usually, many components to build up the functionality of the Entity. This allows the designer much more control when designing the level and gameplay mechanics, without having to resort to programming.
Added Components
Provides an interface to the physics collision masks for this Entity. Collision Masks allow you to specify up to 32 types of Entities that can be ignored by each other. For example, given 3 Entities, A, B and C, with types 1, 2 and 3 set respectively, adding 2 and 3 to the Ignored Types list for Entity A will cause Entity A to not react to collisions with Entities B and C.
This special timer component provides much more control over timing within your logic for each Entity. With this timer, you can use the Stop and Resume nodes to "Pause" the timer at runtime, reset them and modify their intervals.
This component is designed to be used with Health components, but can also be used without, essentially making this entity invulnerable.
The Damage component will automatically react to collisions with other physical Entities, and apply the preset damage amount to the other Entity only if the other Entity has a Health component. You can also use the GiveDamage node to give damage to specific Entities with specific amounts arbitrarily, provided of course, that they also contain a Health Component that can receive the damage.
The Enemy Component is used essentially used as a proxy to provide some easily accessible settings that can be used when spawning. For example, the initial velocity and initial direction settings. The component itself has no logic in the code.
This component provides the ability to add exclusion zones to the enemy spawner component. This zones are essentially "No Spawn" zones to prevent enemies from spawning in that location. For example, the player uses a circular exclusion zone to prevent enemies from spawning too close, making the game too difficult.
The enemy spawner component controls which enemy types and the timing when each type is spawned. On the code side, this maintains the exclusion zone list added by Enemy Spawn Excluders, and sets up timers for each of the "Enemy Definitions" set by the designer.
This component provides an interface for interacting with Entity Links. You can create, rename, and remove Entity links between this Entity and other Entities. You can also get the Entity attached to the other end of an Entity link by name. This is used, for example, to setup the target Entity for the linkedenemyhost (2nd enemy) in the sample project.
This component allows the designer to add a physically explosive force to an Entity. The component can be automatically activated on initialization (when the owning entity is spawned), or on demand via the Explode node.
This is a dynamic component.
This means that this component is created dynamically based on the available Flash elements currently in your project. The Flash Element in this case is called HUDMAIN and is the UI environment you see in the sample project, from the health bar to the Press Start text. These components will automatically expose the registered functions and events defined in the UI XML prepared by the designer, much like the Flow Graph version.
The same FlashElement component on separate Entities will control the same Element (not accounting for individual instances). In the sample project, the Player Health, for example, is initially setup by the Game Entity, and is updated by the Player Entity when taking damage.
The Health component is only really useful when used in conjunction with a damage component.
When the health of this is affected, by a damage component for example, it will trigger an OnDamage signal to the owning Entity. Once the health property of the health component reaches zero, it will send a KillEntity signal to the owning Entity which can choose how to handle this Event. If the Entity is removed from the scene (via the entity:remove node for example), this component will broadcast an OnEntityKilled event to all subscribed Entities and components.
This component will affect the particle grid in the level. It is the effect seen around the player and around explosions where the individual particles are pushed away from the Entity.
The Play Arena component defines the playable boundary of the game.
It can also reflect physicalized objects off the inside edge of the boundary automatically, provided they are defined Entities such as the default projectile and enemies in the sample project. The arena uses an Area Trigger Component internally to signal an Entity when it has left the area. The player Entity uses the dimensions of the Play Arena in the level to handle its own boundary, which is slightly smaller than the playable arena.
We do this so the projectiles that are spawned do not spawn outside of the playable area when fired.
The Player component has two main functions, first being the player camera which is constrained to the Arena boundary by using the Arena dimensions, along with maintaining stability when moving and rotating the player. Second, this component exposes itself to the Visual Scripting system to allow other components and Entities to get information of the players position at runtime.
The Player Controller component defines the effect user input (either via mouse and keyboard, via Controller, or even a mixture of both) has on the owning entity. It also controls whether the cursor component is visible based on the last used device to control the player ship.
This custom component is designed to be used alongside the Player Controller. It defines several settings which the designer can customize such as the cursor texture, sensitivity and axis bias.
This component exposes a SpawnPlayer game node to allow the game Entity to trigger the player spawn.
The Weapon component is essentially a customize-able timer that can control the fire speed of the weapon.
It provides several nodes to enable/disable and handle firing events in the visual graph. The component doesn't actually spawn any projectiles, but sends a signal to the owning entity which can then be handled by the designer to control exactly how to interpret the various settings assigned to the weapon.
The Weapon Attachment component is used to hold the current weapon in use by the owning Entity. The weapon itself is spawned as a child entity and attached to the owning entity. This allows pre-defined weapons (entities) to be switched out on demand without adding and removing, and tweaking properties of components themselves.