04/06

What We Did

This week we worked on basic game components including the grid, player controller, robot controller, object holders, holdable objects, floppy disks, car parts, object spawners, and assemblers. The grid is the walkable area for the player and is composed of square tiles. Each tile contains up to four adjacent tiles that the player can move to. The player controller takes in player input and moves the player’s avatar throughout the grid. The player is also able to rotate and interact with “interactable” game objects like spawners and object holders.

If the player is holding a “floppy disk” they can record a series of actions (movements, rotations, and interactions) that can be placed on a “floppy holder” associated with a robot. The robot controller then takes these actions and loops through them. The robot can thus be trained by the player to pick up objects, interact with things, and move in the same order that the player performed the actions.

The car parts are the various components of each car that the spawner can create. There are three types of parts, the wheels, body, and engine, and three different types of each part, a, b, and c. The object spawners can spawn the various car parts as well as the different types of car parts. Once spawned, the parts can be brought to the assembler where the parts will be assembled into cars that can then be scored.

What We Plan to Do

For Thursday, we plan on implementing a minimal playable version of the game. For this to be possible, a few additions need to be made. One such addition includes blueprints for cars so that the assembler can determine if it has all the car parts required to make a car. This action can be coupled with the GameManager to determine game progression.

Other usability additions include the use of a texture that shows the edges of each tile so that players can see the grid. Also, we plan to add a GUI above each spawner so that players can easily see what objects the spawner creates. Along with this, we plan on having a GUI associated with the assembler so that players can see what objects the assembler contains.

What Challenges We Faced

Though no major issues came up, certain challenges made this week’s work take longer. An example of this is the level of complexity required for the player controller so that actions can be performed and recorded as needed. The script has to take in input, determine what that input translates to, and then determine if the action is valid. This same process is necessary for the robot except instead of input, it relies on pre-recorded actions by the player.

Another challenge was organizing the object hierarchies. We have various classes that inherit from others to reduce redundancy and increase code efficiency. Therefore, careful thought went into how these hierarchies were created in order to support future development of the game.