So far, I’ve not talked much about design in my posts. Or, rather, I have implied straight-forward design in most of the features. I’ve also implied that the features work together. Occasionally, I’ve clarified my intentions. But (besides some weapon balancing) I’ve never really justified any choices point-by-point.

So the goals are tasks for the player to keep track of and to receive awards for. They are fluff on top of gameplay. In many ways, I would describe them as “cheap”. But at the same time, they are rather important to convey their progress. Firstly, the player can see their increasing numbers in every category and so they see that the game tracks what they are doing. Secondly, they provide tangible goals, even if they are very much arbitrary thresholds. However, they do roughly serve to show how close the game is to completion.

I think that my goals will come in sets of 3 like the Kills 1/2/3. And I will award consistent, increasing bonuses for them, such as +5%, 10%, 15% extra weapon damage. Thinking more about it, I will likely do 10%, 25%, 50% instead. Basically, the values don’t matter as much when everything in the game is balanced to it anyway. But it feels better, like you’re getting a tangible reward. But not too crazy, like 300%, which just feels like random pointless numbers.

The difficult part would be to come up with sets of 3 for every goal. Or not make some obscure goal require 3 sets just because all have 3.

I am also considering “negative goals”, that is goals that are achieved by performing badly. Such as “damage taken” (but not “times died” though). Presumably, a very good player will never reach these and would have to deliberately stand in line of fire and die repeatedly to 100% the goals. So I have to be very careful how I approach these — they must complete themselves before the player ever reaches far enough to consider focusing on specific goals.

Anyway, I have some simple goals like “Kill Enemies” and “Kill Bosses”. But I can go more granular like that. This will highlight the different types of enemies that are there and make this difference more meaningful. For example, I can add the mob’s “category” to the mobs:

I currently have my pedal walking, my tank-threading driving, and my jet hovering enemies. So I’ll go with these 3 types for now. I can name them properly later. Then I can have my goals use a specific mob type for the goal:

I am also adding a bonus specific to that goal, like extra damage to those enemy types. In short, the more the player does something, the easier it gets. Same principle for different weapon types:

As for achievement-like goals, I can track specific lists of actions, like which weapons has the player used to get a kill with:

Similarly, this would work for mob and boss types killed.

Now one of the first things I can encode in my misc goal rules asset is the types of enemies that count towards the kills:

I can use this both for logic and for UI purposes to show the list in the right order.

Very similarly, I can list the weapons I want to get kills with:

And also bosses that I want to kill:

At this point, I already have a pretty good list of many goals:

These aren’t even that hard to add and wire, just somewhat tedious. There’s a lot of places that need small additions for each one.

In RPGish games, I always go for skills and perks that let me gather more skills and perks quicker. So I think I want to add something similar here. Firstly, scrap collection: I want more scrap to be dropped from chest and enemies. Such as chest looted and scrap looted ones:

All of these additions have to get tracked as statistics (and saved/loaded):

In fact, the more I think about goal rewards, the more I come to a decision that they should only provide one award, either experience or bonuses. In fact, just one bonus. There are so many goals and bonuses and numbers to track. I think it’s just simpler this way. Having systems that easily support complex options doesn’t mean I should use the complex options. Mostly, I just one the simple results. So I’m even going to highlight “wrong” selections:

While working with so many assets, it really becomes important to not make stupid mistakes where I forget to link something and spend minutes (that stack up to hours) on issues. For example, a really useful helper method can quickly check if all assets in the same folder as the parent collection are actually linked and provide a quick way to add them:

All my assets follow a similar principle where they are defined and looked up by an enum value, such as the goal type. So I can also add a check for the same assets and see if their contain this enum from all the enum values. And this works great, I actually found an error:

These also have the benefit of being a quick way to add assets instead of drag&dropping. Now that I am used to adding them quickly like this, I will (almost) never forget to add them. Of course, if I actually open the collection. I can also reuse this for other projects.

Now, I can’t actually create the asset, because it’s not going to have any of the other values. There’s no point for that code when I can just duplicate any other asset in the folder and change the type.

Anyway, back to goals. I’ve been thinking about my weapon design and I have way too many weapon types for use to comfortable oversee. I think I want to reduce the number of gun types. For example, I will get rid of (player) pistol and sniper rifle — I just don’t care about single shot weapons for my current gunplay — it’s too slow and precise. I will treat machine guns, SMGs and minigun as automatic ballistic weapons. That leaves shotguns — I think I will add a couple more variants for them, and have them be a separate class/type. This means I have to introduce a “weapon type”, because I’m using damage type for my logic. However, ballistic weapons are all ballistic damage, so I need an extra value to distinguish these.

And now I can have a nice shotgun-based goal:

This also forces the player to switch weapons, thus they get to see more of the game’s features, thus they inadvertently enjoy the varied gameplay more, even if they though they wouldn’t, because my goal is to make most guns usable and fun.

There are a bunch of other goals I am considering, mainly to do with healing/repairing and crafting/upgrading, but I need those systems running first, so I will mention them later when I actually make them.

Anyway, that’s a whole lot of goals right now and I think I need to do some UI before I add more. I am still not sure how it will all be presented.

MicroRogue DevDiary #79 – Goals
Tagged on:     

Leave a Reply

Your email address will not be published. Required fields are marked *