For this project I was given the art assets and a project requirements document which listed all of the features this game would have to include.
AsteraXRequirementsDoc
It was a tough
challenge to be given specific features and have to figure out how to implement them into the game, but felt very rewarding as I added each new piece.
I learned a lot about Unity's UI system while creating this game, and had quite a bit of trouble figuring out how to layer my UI so that I could have
a 3D view of the spaceship model when choosing space-ship parts in the customization panel. I ended up using multiple types of canvases for the different UI elements, such as
screen space - overlay for most of the basic UI, and then screen space - camera for the 3D rendering. However, screen space - overlay UI always appears on top of the the camera space UI, so I had to be
sure that different UI elements were activated and deactivated at the right times or else there would be unwanted overlap.
Another difficult task for this project was procedurally generating asteroids by picking from 3 random art models on a scriptable object and creating a new larger "mass" of
asteroids which can then be shot and have the smaller asteroids in the mass split off. There were quite a few difficulties with setting the parenting of asteroids in the clump,
making sure that the colliders and rigidbodies were interacting correctly, and making sure that the smaller asteroids spawned on the edges of the larger asteroids so that most
asteroids in the clump were visible. I ended up using recursion to create the Asteroid clumps by having asteroids call a method named GenerateChildAsteroids, and then smaller asteroids in turn
also call this same method on themselves. Any asteroid calling this method had to pass itself in as an argument of this method so that the child asteroids that were generated would know
who to parent themselves to.
Overall, some big takeaways from this project were the usefullness of scriptable objects to allow for quick and easy swapping of art models and any other data in the game, learning
about JSON files and how to implement them in a save system, and finally how important it is to keep in mind how you want to handle dependencies in your codebase. For this smaller project,
that I did not see myself expanding passed the requirements doc, I ended up using many Singleton managers to communicate between different systems and this quickly lead to some disorganized code.
For example, the code for the player shooting a bullet contains a reference to the achievment manager telling it to increment the bullet count by 1. This works, but in reality the code for shooting a bullet
should have nothing to do with the achievment manager. In the future, on larger projects, I will definitely keep in mind the importance of dependency inversion so that I can keep my code cleaner, and find
patterns that allow for unrelated systems to not directly reference each other. Although, for this small project I do feel that singletons were totally fine.
Singletons get a very bad wrap in the programming community, and I used this project as an opportunity to explore that concept and see why singletons can be so hated. In the end I feel that
Singletons have a place in small projects for quickly prototyping ideas, but that in medium to larger sized projects you cannot afford to have messy code like you can in tiny projects, and you must
have cleaner overall structure and more modular systems. Singletons therefore cannot be relied on asmuch because they tend to tightly couple your code, and often lead to sphageti.
Some strategies to keep your code more organized that I have been researching are dependency inverserion strategies such as dependency injection, event systems, and the service-locator pattern.
In my research it seems that many more organized approaches to programming in unity lead to extra layers of complexity which may not be necessary for smaller projects, and that it is
important to understand the scope of your project before deciding how you will organize your code and choose how you will alleviate dependencies.