My favorite technology so far during development is Blender, with Affinity Photo as a last-minute runner-up. My least favorite software would have to be Adobe Photoshop.
Blender
I have extensive experience working in Blender for manifold 3D modeling. However, game design has honed my skills in creating efficient topology along with new methods of texturing 3d objects. Further, creating a full game scene has given me ample practice in creating assets rapidly during our fast-paced development cycle.
Affinity Photo
This software takes everything that is good about Photoshop and packs it into a more intuitive, aesthetically pleasing user interface. And not to mention, for a one time price less than three months of Adobe’s “competing” subscription. I don’t think I will ever be going back to the Adobe suite after discovering Affinity’s products.
Unity
I had difficulty learning certain aspects of the Unity Editor as it is a large application with many different modules. Particularly, it was hard for me to learn how to use materials created in Blender and imported into unity. Now that I understand how to extract materials and associate them with textures, it is intuitive and quite useful to be able to manipulate those materials within Unity.
If I could start over, I would consider using Godot as the game engine. We are only really using Unity for its grid system at the moment, so I think Godot would have allowed easier flexibility in how we integrated the code base. That being said, I believe we will be using more of Unity’s modules in the next sprint including the grid system and animation.
As we begin the development cycle of our Let’s Launch a Game project, now is a good time to review general guidelines for writing clean code. While we have been working to maintain uniform formatting, informative naming schemes, and explanatory comments, there are other development philosophies that we can focus on to improve our code. Personally I found my research into common code smells the most useful. One design pattern that I think I often fall victim to is having Middle Men functions.
A Middle Man is a function that relies mostly as an intermediary between other functions. Removing Middle Men improves readability and can prevent potential downstream issues in future development cycles. Where I run into this issue most often is when I am contributing to an established codebase and don’t fully grasp the scope of an established function. I will often add additional functions within this function to do the bulk of the work. Paired programming and code reviews are one way to avoid this misunderstanding.
The figure below is an example of a middle man function. Within “Minion”, the main functionality is referencing is_frontline, this could be updated to a single call within action.
Going forward I intend to avoid using Middle Man functions.
Something I would like to start doing more of is writing shorter functions. This may seem to be an opposing issue to writing fewer Middle Man functions, but I think writing shorter functions can actually facilitate a clearer hierarchy. When a function isn’t bloated and sticks to its intended utility, the code becomes much more readable and reusable. In terms of design principles this might often be referred to as using SRP or the Single Responsibility Principle.
