Project code

Hi. I'll tell you about how the code in the project works, what I adhered to, and what had to be changed. There's a lot to talk about. I will share my experience.

Access limitations

As I wrote in a previous article, namespaces are a great way to delineate the islands of game logic in a project on a large scale. At a lower level, there is a division into classes. Remember, the Divine object is an antipattern. By the way, one customer knew a little bit about programming and seriously wanted us to make divine objects in games.

Then another tip. You are a specialist in your field who knows the technical details of the project implementation, and it is your responsibility to insist on the right informed technical solution.

Almanac

Do not forget about abstraction. If the situation requires it, first we make an abstract class or interface, then a more specific implementation. Don't worry, it's never too late to start extracting methods and allocating classes.

An interface or an abstract class? It is more appropriate to use an abstract class with an obvious commonality of heirs, while the interface is only a behavior model that objects that have nothing in common can implement.

The Council. Learn refactoring, it's really useful. Learn keyboard shortcuts in a programming environment, it's really useful. At my new job, I learned a lot from my senior colleagues, and at the same time I also had something to tell and show them.

An example of abstraction. When the main character gets acquainted with a new type of enemy, the player is shown a description of the new enemy and its features, characteristic features of behavior. The same thing happens with the new scrolls picked up by the player. It is logical to make some kind of basis in which the details will change. Therefore, the scroll data and the new opponent data are inherited from the general class from ScriptableObject. The description page of the enemy and the description page of the scroll also have similarities, but in the description of the enemy we also show a list of characteristic features, and in the scrolls there is only a description.

Only after a couple of years of programming practice do you begin to understand the principles of SOLID and OOP for real. For a reason, in every video, in every article or interview with developers, it is repeated like a mantra: each mechanic is a separate island that works independently of others; removing one component, the other should not break… Try to adhere to the principles of programming, it will be cheaper in any case than to redo everything later, correcting one thing, thereby breaking the other. 

The Council. Do not stop changing the naming of fields, methods, and classes until you are satisfied with them as much as possible. Naming should convey the essence concisely and that's it. Classes are named as a noun, methods as a verb. Events are usually written with the word On (OnHit, OnLoaded, onError), but the methods that subscribe to them must convey their essence (GetDamage, Unfade, SetDefaultValues). Remember, most of the time you read the code first, rather than writing it directly. It is much easier to decide on changes in the code if you have a good command of the IDE (for example, renaming and extracting a method).

The Council. Use the field keyword in attributes, it allows you to perceive properties as fields, displaying them in the inspector, but still encapsulate the data. Do not neglect the restriction of access to data. This trick reduces the number of lines by 2 times, Carl! This dozen lines could look like 20 lines.

Spawn opponents

Everything seems to be simple here. Enemies appear in waves. Waves, the number of opponents and the period of their creation during the wave are determined in SpawnerData. They can appear throughout the entire wave, they can appear at the beginning of the wave or only at the end; one per second or in a group at once.

From the very beginning, I did not fully think through exactly how the opponents would appear in the arena, and I really wanted to bring some originality to my game. Therefore, I had to redefine the architecture of this part of the code. Now the point of occurrence and the logic of this event are delegated to a separate SpawnDealer class. He became responsible for exactly how and where the enemy would appear. For example, arachnids appear with the help of the Nidus worm, if there is no such thing on the stage, the worm will appear first, the animation will be played, and only then an opponent from it will appear. Spirits appear only in dark areas of the arena, and demons in points where there is fire (torch, bonfire, fire). Some opponents appear with the help of lightning, only in open-air areas of the arena.

Red dots mark dark places for the appearance of Spirits, and white dots under the open sky to create lightning and spawn opponents from them.

Damage and Health

This part of the game also had to be rewritten after the first attempts. The result was the abstract class Health and its heirs HealthPart and HealthParent. It was assumed that hitting different parts of the body (HealthPart) gives a multiplier for the damage received, transferring the values to the HealthParent, which the enemy has in a single copy. This is a solution from a shared folder with a codebase, in fact, only HealthParent is used in the project.

Since the game has elemental damage and various meta-data of damage (from which side the blow came, the point of impact, the physical force of the blow, hit prefabs), I made the HitData structure, as well as the DamageDealer for the convenience of filling in this data.

The Council. Try to subscribe to events (if they are not child components), rather than directly linking external objects to each other. This will reduce the coherence of the project, allow you to remove or add something to the scene, without breaking the rest.

Completion

Do you understand class diagrams? Is something worth fixing? What do you think? Is there any benefit from what you have written? Criticize, write, read. I really hope that I am doing some useful work in the hope of improving my and your literacy in writing code.

Developer page | Project page | YouTube | e-mail | Support