My first impressions of Qualcomm: Building Q are all positive ones. The campus is beautiful, and the rows of computer laboratories, circuit fabricators and servers are a wonder to behold. I was given a relatively quiet workspace with all the resources I need to work on my project. The other members of the team are all easy going and fun to talk to, and have no issue explaining their role in the company. It's been awhile since I started on this project and actively worked on it. I learned as I moved along, meaning some implementations were done cleaner than others. I spent today re-familiarising myself with the code I wrote, as well as meeting Qualcomm employees and touring other buildings. Looking back, I saw some things that weren't implemented very well, and needed to be fixed to move forward with a strong foundation. When someone remodels a bathroom, they must tear it down. That's what I'm doing to the underlying code for the towers. Currently, the 3 fundamentally different tower types (mortar, minelayer, and normal) are all sloppily written and intertwined into the same class. The way it is written doesn't allow the expandability I need to ultimately have tens, if not over a hundred tower variants (lightning, nukes, rail guns, bow and arrows, sniper rifles, flamethrowers, the list goes on!) So I spent today attempting to refactor the tower class to allow the creation of derived classes that all share the common traits of towers- such as being able to place them and being able to see their stats- but still function in fundamentally different ways. This will result in much more organized development and will save me a lot time moving forward. It will also allow me to avoid the bloated, confusing, and redundant inspector (allowing the external modification of values within the script) I currently have to work with. However, I haven't finished yet. More things are currently broken than when I started today. Snippets of dependencies are all over my codebase. When I attempted to separate the code for the mortar tower from the rest of the tower code and instead make it inherit properties from the tower class, I broke the ability to place a target, and spawned an infinite number of seemingly entirely unrelated null reference exceptions. These are all side effects of the unfinished implementation, and is the nature of ongoing development. I will continue working on this tomorrow. All in all, I didn't achieve much in terms of concrete changes, but I have a defined goal and direction. If you're confused, let me try and help: To further explain my workflow, it is important to note that the game is not programmed in one giant code document. C# is what's called an object oriented language. This means that the code I write is separated into many different scripts called classes that serve different functions. Multiple instances of the same class can exist at once and can both run separately and contain separate values. This is very easy to visualise with Unity, because the classes quite literally run on tangible objects. For example, both the basic tower and the rocket tower run the exact same Tower class. The rocket tower simply has a different value for the property explosion radius than the basic tower (2, instead of 0). In addition, every tower placed by the user is running a separate instance of that same code. Both of these towers shoot bullets towards the enemy when the enemy comes into range of that specific tower. Each bullet is a separate instance of the bullet class, with different values for speed, damage, and explosion radius that aren't affected by any other bullets (unless I want them to). See where I'm going here?
The end goal is that these classes all work together and communicate with each (by passing values and functions) seamlessly and effectively. When that goal is achieved, the application can be expanded as much as the user wants. I can place and run three hundred mortar towers if I want to, only limited by my computer's processing power and how well my code is optimised. That is the general idea of C# and the Unity game engine. Moving on, I will be referring to this summary if a reader is confused about the general process of my workflow.
0 Comments
Leave a Reply. |
|