Happy new year! Once again, I’m Joakim and I will be talking about designing a system for sky conquerors weapons to simplify weapon creation and weapon balancing.

By now, we have taken huge steps forwards since last time I wrote. Let’s take this chronologically.

Since I now knew what stats I wanted the weapons to handle, I wanted a base that used those and that wouldn’t need a lot of copying for each individual weapon. After trying various methods with a testing rifle one of our programmers had made, the Gunparent was created.

The Gunparent is a component that other weapons can use as a parent class. This lets all other weapons use all the Gunparent’s variables and can use its blueprints with their own values.

Since all weapons uses it as their parent class that means other blueprints, such as the player character, can easily call upon its events without needing to know which specific weapon it holds.
Now that I’ve teased about it enough let’s have a look at the Gunparent’s blueprints.

First off the variables:
The Gunparent has all the variables that the excel sheet listed, and a few others for functionality. About half of these variables does not have a use yet, mostly relating to rocket-based functions. Only a few are used in the actual weapon blueprint and most are carried over to the bullet.

Now for the events:
The Gunparent has most of the functions required to fire it built into itself. The player character does not have to check if it is cooling down or other things that should depend on the weapon.

The accuracy of the weapon affects how much the aim can differ from where the player is aiming. The method built uses a system that affects rapid fire more similarly to Team Fortress 2, compared to Counter Strike 1.6 where the first shot would have better accuracy.

The firing section is mostly dedicated to carry over values to the bullet but also contains a loop for firing several bullet. This is of course there in order to simulate a shotguns spread.

The bullet, like the rifle, mostly contains functions that would be expected. It uses the speed that is carried over, the damage etcetera. All weapons uses the same bullet.

With all of that said, how does it look in game?

Pretty terrible.

The gun works but since we’ve focused on building the game and not on any sound, UI or more than the basic animations the gun does not give of a sense of weight. And this is reflected in the variables, none of them contains screen shake or other visual aids.

This was fascinating to notice when we played the game online against ourselves in the team. That it was so static that it barely felt like a shooter. This isn’t any of our goals, but it needs to be rectified to get the proper criticism that the game needs when we test it.

Finally, let’s take a look at that Excel sheet I mentioned in the last post.

I have started sorting it out, but the math proves to be difficult. Let’s go over this. The creator has 100 weapon points to spend on the stats. The document is set up so that it counts together the values in the “Spent points” column, and if “Is warhead” is 1 then the “Spent points” column in the warhead-section is added as well. Otherwise they are ignored.

Point value is an estimation of how much that stat affects the gameplay. Lowest and highest value is what is actually used in game. And then there is the current big problem, value.

Value needs to be a representation of what the points spent represents. In order for this system to be effective this is something that should be calculated quickly. But each stat needs their own equation since they have different amounts of points and very varying values.

At this point, Project Sky Conquerors can be played over a network, plays can die and respawn and there is a level to play on. The game now has a base to be built upon so our team will keep building, and I’ll be back with more progress next week.