GENERATE AN ADAPTATIVE PARTY'S GOAL

   A more manageable problem was to generate a balanced party’s goal from the generated world. Depending on the radius of the game area (set up during the AR initialization), and on the picked WorldElementPrefabs, 10 of iron could have been generated as well as 100 of them.

   In order to handle all those cases, we decided that a single Construction will always hold the same Resources in the same amounts (ex : A weapon rack will always hold 2 irons and 1 wood). This allowed us to easily process the Resources quantity of each Prefab, and therefore of the total world. We then added an importance weight to each Resource, requiring the player to gather greater proportions of some Resources, like iron, which is the rarest Resource. This pushes the player to search for precise Resources at some point of the game.

PHYSICAL SYSTEM AND COLLISIONS

    The main feature of the game is to toy around with a bunch of objects, to pick them, to throw them at each others, to crush them with your giant hand… This basic principle required us to set up an architecture and system able to handle all those physical interactions, and play different actions depending on the collisions.

​

    The main physical objects are the Constructions (houses and stuff generated at the beginning of the game), the Resources (spawned by Constructions when destroyed, and used to complete the player’s goal) and the Humans (enemies of the game). These objects can receive and / or deal damages, which will define what happens when two objects collide with each other (ex : a house colliding with another house will likely result in both houses being destroyed since both can receive and deal damages).

PROCESS AND LOGIC

   All Physical Objects of the game inherits from the PhysicalObjectScript base class, requiring them to hold a Rigidbody, and giving them access to common behaviors and methods than our objects need to implement. This also allows them to hold common variables, like the “objectDamagingMass” variable, defining if the object is rather heavy or not. This defines if it will more likely destroy objects it collides with, or destroys itself if it hits a static object.

​

   All Physical Objects hold the “Throw” method, allowing them to receive a particular velocity. This method is used on many features of the game : Objects can be thrown from the player’s hand, Resources are expelled out of their Construction when it gets destroyed… This easily enables for more juicy objects' movements.

​

 Regarding the collision management, each Physical Object uses the “OnCollisionEnter” callback, and checks the nature of the hit object. If the hit object is not a Physical Object, the colliding Physical Object check if it is destroyed under its own velocity. If the hit object is a Physical Object, the “AskForCollisionTreatment” method from the CollisionsManager is called in order to process the collision between two Physical Objects. All these queries between Physical Objects are processed during LateUpdate, to make sure that all of them have been updated before treating the collision.

​

  When a Physical Object receives a collision, the “CheckForDestroy” method is called, checking if the object should be destroyed depending on the speed force it received. If force is high enough, the object is destroyed on the next update, just to make sure interactions between two Physical Objects are handled as they should. “DestroyPhysicalObject” is a virtual method, allowing for specific behaviors on destroy, like spawning Resources on Construction destroy.

REVIEWS

    Looking back at the projects scripts gave me the opportunity to realize bad practices I had while working on Long Giant. Now, I do my best to avoid those bad practices and work as clean as possible on projects.