Projects
Projects
These projects range from board game development to app designing to hologram making! But most importantly, they focused on working as a team on a project for
These projects range from board game development to app designing to hologram making! But most importantly, they focused on working as a team on a project for
Game Engine Architecture
ABOUT
Game Engine Architecture focuses on software design principles and architectural coding patterns that are especially pertinent to game engines.
Many of the projects were based on examples from David Baron's Hands on Game Development Patterns with Unity and Robert Nystrom's Game Programming Patterns.
SOLID
PRINCIPLES
The SOLID principles are five design principles geared towards making software designs more understandable, adjustable, and maintainable.
The theory of these principles was introduced by Robert C. Martin in his paper, Design Principles and Design Patterns, while the acronym was introduced later by Michael Feathers.
S
ingle-Responsibility Principle
When a class is created, it should only do what's required to meet its single responsibility.
O
pen-Closed Principle
Open for extension, closed for modification.
L
iskov Substitution Principle
A class that inherits from a base class should be able to be substituted for the base class.
I
nterface Segregation Principle
No client should be forced to depend on methods it does not use.
D
ependency Inversion Principle
"Depend on abstractions, not concretions."
Projects
SOLID Selection Project
.png)
This project was an example of using the SOLID principles to implement and refactor an object selection system.
Using Charles Amat's tutorial (Infallible Code), examples of each principle was given. The tutorial started with a Unity scene, with a few objects in it acquired from the Asset Store. A couple of the objects in the scene are selectable. The objects are able to be selected by hovering over them, which results in the object's material changing colour. When the object is no longer being hovered over, its material returns to the default material. The tutorial went over how to add another selection response, which is shown above. The added response was an outline that would appear around the selected object.
I added a few more selection responses. The first one makes a glowing, yellow cube come up over the selected object and the second one makes a text box displaying "SELECTED" appear above the selected object. The different selection responses can be cycled through with the key "n" on the keyboard.
S - The selection manager was refactored to have one responsibility. The class was separated into multiple classes to accomplish this.
O - The selection response was made so that it was open for extension while being closed for modification.
L - Instead of relying on a particular implementation of a selection response, the selection manager class was changed to rely on a selection response interface. This interface could then be substituted by any subtype of it. This fulfilled both the Open-Closed principle and the Liskov Substitution principle.
I - Instead of having one general interface, many smaller interfaces were made, each one to control their own things.
D - The selection manager was altered to depend on an abstraction of selection response, instead of on a concretion of it.
Spatial Partition Project
.png)
This project was an example of using a spatial partition to organize objects optimally. It was accomplished by implementing a grid system to organize the objects within it.
Based on Robert Nystrom (Game Design Patterns, Chpt. 20), this project was made from the tutorial by Erik Nordeus. His tutorial implemented a grid system on a 2D plane. On the plane, enemy entities wandered from grid cell to cell while friendly entities directed themselves towards the nearest enemy.
I added on this concept and made it not only in the x and y direction but in the z-direction as well. I also changed the aesthetic of the project to look more pleasing.
Abstract Factory Project
.png)
This project was an example of using a decorator pattern to enhance the abstract factory pattern.
This project is based on David Baron's application of an abstract factory (Hands-On Game Development Patterns with Unity 2019, Chpt. 5). An abstract factory's main purpose, in Baron's words, is to organize the manufacturing process of objects into related groups.
It also implements the decorator pattern (Hands-On Game Development Patterns with Unity 2019, Chpt. 14), which allows the addition to objects at runtime without altering the objects in the process.
The project uses the decorator pattern by adding specifications to a base dish and then putting that into the abstract factory to be created into the proper dish.
I made this unique by changing the specifications of the items, and the items which the factory creates. I also added some illustrations (only the Vietnamese dishes have pictures.)
Event Queue Project
.png)
This project was an example of the implementation of an event queue.
This project is based on David Baron's application of an event bus (Hands-On Development Patterns with Unity 2019, Chpt. 15) and Robert Nystrom's event queue (Game Programming Patterns, Chpt. 15.)
The event queue stores a series of requests in a first-in, first-out order (FIFO.) It allows for the events to be processed and then run at a later time.
In the case of this project, the Launch action is stored in an event queue. The other actions can be run at any time, but if there are Launch events queued up, they will be run one by one until the queue is empty.
Finite State Machine Project
.png)
This project was an example of the implementation of a finite state machine.
This project is based on Robert Nystrom's execution of a state machine (Game Programming Patterns, Chpt. 7) and David Baron's state machine (Hands-On Development Patterns with Unity 2019, Chpt. 10.)
The finite state machine limits something to only ever be in one current state at a time. (The player cannot dive while in the spinning state) In the case of a finite state machine, there is a set number of states that the object can be in. Each state has different transitions that point towards a different state.
For this project, I added on to the tutorial code by making additional states for the turtle to be in. I also customized it slightly with the turtle. (Note: There is a bug where the turtle does not enter the jumping state unless the player double jumps. This means for his first jump he immediately returns to the standing state while in the air.)
The states are:
Standing (Default state)
Jumping (Press "space" while standing)
Diving (Hold "ctrl" while jumping)
Ducking (Hold "ctrl" while standing)
Spinning (Hold "s" while standing)
Rude (Hold "r" while standing) (The turtle sticks his tongue out)
Cubethon Project
.png)
This project was an example of the command pattern.
The project implements David Baron's example of the command pattern (Hands-On Game Development Patterns with Unity 2019, Chpt. 8.) The original Cubethon project is a tutorial by Brackey's, where he teaches every aspect of the simple game.
The command pattern allows the centralization of the process of invoking specific commands on an object. This allowed for the creation of a replay system. The player's input is registered into a command log, and then it is played out in the next scene on the object to simulate a replay of what the player did.
For this project, I made it unique with a custom aesthetic. This included assets (one was obtained from the asset store) and level design.