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.

Comments

Popular posts from this blog

Back to Vinland.

I'm going back to my real time tactics project, Vinland 1936.
While working on the other project I overcame the problems which were stopping me from saving/loading the game and also cleaned up the base code a lot.

After a few weeks I'm getting near the the state I was in before.


Infantry are back to their previous state, and vehicles are running OK.
This time I'm going to push ahead with mocking up the combat system though before I work any more on the vehicle builder or graphical aspects of the game.

Rockets

I finished working on the code for adding foliage and having some extra time I decided to experiment with the code for rockets.

The original idea I had was that rockets would be large vehicle components that can be fired very quickly, regardless of how much manpower is used for reloading.






They would use up a lot of ammo, so they would run dry after a short but devastating barrage.
The problem here is that it's easy to take advantage of this by adding a lot of ammo, which is much smaller than in bulk than the rockets.

There's also the problem of firing large caliber rockets. In real life rockets of up to 30cm were used, but I think that will be too powerful for the scale of combat in this game.



lol. Somehow that one trooper survived the mother of all explosions...

A 30cm rocket could contain nearly 30KG of explosive. That would be a very large explosion.

I've tried to balance the game by using a simple equation to make bigger guns more powerful, but hopefully not too powerf…

Infantry combat and entering buildings.

I've been working a lot on the game recently and I've nearly rebuilt it to the level it was before. Past that maybe, since now I have the beginning of a working combat system and the ability to save and load the game.


Infantry can now occupy a building. It's quite an abstract representation, since they stay at the door and turn invisible. But they can then fire from one of the windows and take damage from shots at the windows too. I think I've set it up well so that when building damage and destruction is working then the system should continue to work.

For combat I tried some new ideas, but they didn't work out that well. It seems that it's important that viewing range should be further than shooting range. Now shooting range is pegged at 18 units of distance, while viewing range can extend out past that.

In the above image one unit has an officer, so has further viewing range. The other can only see as far as they can shoot, a dangerous situation since the en…