Seeing Through the Problem! An Abstract Solution

Ryan Yamura
4 min readDec 8, 2020

We’re nearing the finish line folks, just about one more week till the initial goal of 59 days comes to pass. And though the program might have been extended, the deadline for the team project has not.

So it was with great gusto and a bit of uncertainty that today, we dealt with a lot of challenges that are sure to come up in the developing world of tomorrow. The challenge? Collaboration between 6 individuals all working on a single project. Now, this may sound like more of a solution, right? And it really is.

The challenges lie with the learning process in which is the best way to approach this.

I have to give this team credit, I don’t think I could have lucked out to be in such a fantastic group of individuals willing to put in the time and commit to the project. Today, we spent approximately 8 hours in meetings and workshops in order to be crystal clear about what our project goals, timeline, workload, expectations, and collaborative avenues would be.

Yep.

8.

Hours.

Some of us skipped lunch!

The best news is that everyone had a part in this, we all, as a team came up with ideas, clarification, questions, and answers to the problems and challenges that we faced with the upcoming deadline fast approaching.

And one of the more challenging problems, actually presented an opportunity for a great solution:

How do we streamline and achieve modularization of our enemies in the project?

The answer: ABSTRACT CLASSES!

Now, there is a lot more to abstract classes than meets the eye. However, basically an abstract class is a script that can inherit and bestow its behaviors on to other scripts. A template of sorts, that can be used on objects or concepts that may use a more modular approach, with the flexibility to change if necessary. In addition to this, the abstract class itself can inherit behaviors too! So if you had an abstract class that inherits MonoBehavior, any script that inherits the abstract class, also by association and inheritance, takes behaviors from the MonoBehavior. It’s quite fascinating. For example: We wanted a system where we could create a diverse enemies, but still be able to call upon similar system and functions.

So, as a group we decided our abstract class would cover some basics for enemies:

  • Speed
  • Health
  • Weapon Systems
  • Damage
  • Basic movement

With these features in mind, we set out to collaboratively create an Enemy Abstract Class.

A sneak peek.

This also brought up the third type of declaration for variables that I had not learned about yet: Protected.

As private keeps the variables private to the script, public available well, to the public, protected allows the variable to be both gotten and set as long as the communicating script is using the abstract class.

This “protected” declaration for variables also carried over to functions! I don’t claim to know 100% about abstract classes, but basically this means that another script that inherits the Abstract class can call these functions like a public function with the added benefit of being able to override or change some aspects of that function.

The really neat thing? You could have a blank script that inherits the abstract behavior and it would run perfectly as long as the abstract “template” script had working functions in it! This brings us to overriding via script, where if you wanted, lets say movement to differentiate from the basic abstract class movement, you could simply call the function and override whatever you pleased, or even add to the action.

For example, if your abstract class had a movement function to move down, you could call that move down function’s base and either change the speed, direction or add another direction to it!

Abstract classes are wonderful tools that not only help speed up development, but creates a more efficient and clean code in which to develop in. I’ve only been exposed to them for a day, but it is definitely something that I will be looking into more in the near future.

Though we did not get the opportunity to get much of the project “work” done, we most definitely set ourselves up for success, all pulling a new baseline build for the project to work from fresh, tomorrow.

So until then, I’ll see you tomorrow!

— Ryan

Clearly Gitting There!

--

--