Skip to main content

Asset Creation: Shields.

I've not had a lot of time to work on the project lately, just 30 minutes here or there when my baby is sleeping so I couldn't move forward with the next stage of coding so I've been doing a little more on asset creation.

Sometimes I try something and it just doesn't work out, for example adding glasses to the character model:
A thief tries out some new smoked glass spectacles, just the thing for a hot summer's day, but near worthless in a dark and dismal dungeon.

They looked good, several versions were available, including sunglasses or regular lenses, but they are just too small. You can't see them on the player model. So although glasses will be available as in game items, they won't be included in the in game player model.

More successful was the new iteration of shield designs:
Can you spot the two identical shields? I'll have to add a transfer to one of them before they get used.

There are three types of shield, light, medium and heavy, and each type has 20 different visual variations. The game will choose a visual identity for the shield when it is first generated, this will be based partly on its quality, partly on a random element, and partly on any over-riding attributes of the shield. Low numbers are bad, high numbers are good (top three rows are low numbers, bottom are high).

All weapons, armor shields, helmets, books, potions etc... can be given random extra attributes when they are generated, they might be good or bad, and there may be up to three different special attributes on a single item.

Here are some examples for edged weapons (combat values likely to change with testing):

Heavy= Weight + 10%
Weighted Blade= Bludgeon damage +10%
Rusted= Chance of breaking +20%
Sharp= Cutting damage + 5%
Wickedly Sharp= Cutting damage + 20%
Etched blade= GP cost + 5%
Exquisitely Etched blade= GP cost + 20%
Well balanced= To hit bonus +2

Attributes will be a combination of a base attribute and an optional comparative modifier for example:
"very " + "heavy"
or "badly" + rusted
or None + "well balanced"

You might therefore have a "Very Heavy and Wickedly Sharp Longsword" which does does extra damage but is heavy to wield, drains your stamina faster and takes up more weight in your backpack when carrying it around. When the item is created only the relevant stats will be saved in its unique item dictionary, in this case, the dynamic name, current state of repair, cutting damage with bonus, weight, visual identity and parent key. Any info which is not in the dynamic item dictionary will be picked up from the static item dictionary using the parent key to search for "longswords".

Here's some for potions:

Very Strong= Potion effects + 20%
Almost Empty= Potion effects - 20%
Unlabeled=  Potion name not shown, replaced with semi-random color
Spoiled= causes nausea in addition to main effect
Large= max charges +10

Because of being unique, potions won't be stackable in the inventory, but they will have multiple charges, and so will be less common, less easy to make and more expensive than other games.

Whether an attribute is added to the dynamic name depends on your party's combined intelligence score, modified if you have a player with an appraisal skill.
You might find a "Very large and half empty yellow potion", or if your characters are good at appraising loot, it could be a "very large, spoiled, half empty healing potion".

For shields:

Simple= Repair cost - 25%
Reinforced= Wear and tear from combat -50%
Frightening= Increases terror effect when trying to scare enemies
Very Badly made= AC value - 20%

Shields are very important in medieval and dark age warfare, and I intend to show that in this game. having a shield gives you excellent protection against enemy attacks, but shields don't last forever, if it absorbs enough damage it will be destroyed and you'll have to equip another one or fight on without a shield. Shields will wear out much faster than weapons and armor so I've made 20 visual variants instead of 10 as I did for armor or weapons.


Popular posts from this blog

Make your game models POP with fake rim lighting.

I was watching one of my son's cartoons today and I noticed they models were using serious amounts of simulated rim lighting. Even though it wasn't a dark scene where you'd usually see such an effect, the result was actually quite effective.

The white edge highlighting and ambient occluded creases give a kind of high contrast that is similar to, but different from traditional comic book ink work.

I'll be honest, I don't know if there's a specific term for this effect in 3d design, since my major at university was in traditional art. I learned it as part of photography.

You can find plenty of tutorials on "what is rim lighting" for photography. It basically means putting your main sources of light behind your subject so that they are lit around the edges. It can produce very arresting photographs, either with an obvious effect when used on a dark subject...

..,or as part of a fully lit scene to add some subtle highlights. See how alive the subject look…

How to... build a strong art concept.

So you want to make some art assets for your game. The first on the list is a Steampunk Revolver for your main character to shoot up Cthulhu with. Quickly opening your internet browser you start with a Google image search. Ah, there is is!

It might be a good idea to find a few influences so you don't accidentally end up copying a famous design.

Just mash them up and you're ready to go! Off to your favorite modeling program.
But wait! isn't there more to building a strong design concept than that?

Of course there is.
One of the diseases of modern design is that of recursion. Everything is a copy of a copy of a copy. This is especially a problem with "historical" concepts. Over the course of that recursive process the concept becomes infected with modern design elements, and ends up looking very similar to everything else that anyone else has ever made.
If you want to come up with a really fresh idea, you have to get beyond secondary references and go look at real …


Ok, so it's not exactly skynet, but I have got my first AI state working, kind of.

The first state is "HOLD" in which case the agent stays in place where they are and shoots at any unit that comes in range. When I started writing this module, I found that the existing method of triggering actions wasn't good enough to allow the AI to choose the best weapon or target. It worked by simply sending a command to the unit to trigger the currently selected action.

If the action is valid, it triggered, if not it didn't.
That's fine for play controlled units, as that's all they need to do. But AI needs to know in advance if the action is valid. The player can get that info from UI feedback, but that wasn't available to the AI player.

There were three problems:

1. The UI feedback duplicated code in the action trigger function. These  two sets of code could get out of phase so that UI feedback was wrong.

2. The action trigger didn't give enough feedback for …