Another week, another set of work done, especially on the main game mechanics. Unfortunately my planned vacation ended up being postponed because of a mild flu, so I’ve been working on and off this week, so apologies for the lack of contents for this week. Hopefully there’s going to be a lot of contents to show, some exciting, some less thrilling, nonetheless, all pointing to progress.
 

Inventory

This week a lot of work has been put into the inventory system, so it is the perfect time to talk about it in-depth.
Basically an inventory system is just a list of array that contains the needed data for each item that exists in the game, followed by the item type. It handles the item type, name, and other UI related information.
However, the purpose of the item is dictated by the item type itself, which are being handled by a separate class. The item itself is an empty representation of the functions it provides. Here are some of the various item types, similar to the setup found in the original game: Weapon Melee, Weapon Firearm, Ammo, Armor, Money, Generic Items, Cosmetic, Powerup, Bloodpack and Hidden.
 
Weapon Melee and Ranged: The melee and firearm weapons will handle different attack types, melee being blunt attack while firearms will use bullets for attack. They will project the necessary projectiles, but the bullet itself drives the attack damage and damage types. However, the bullet damage for vampires for normal firearms are considered blunt ones.
Ammo: Ammo handles the data for the amount of ammo to add to the given weapon. As it is within the inventory system, it will not be drawn on the inventory interface, but will be added to the weapon’s ammo count instead.
Armor: The armor will handle the amount of soaking it does depending on the armor level. In the original game it changes the entire outfit for the player, something which we will want to change to accommodate the customization support on the player.
Money: It handles the amount of money the player has within his wallet. Any stored money goes there, from which the player will subtract money from. Or gain to. Depends on the player’s lucky gambling.
Cosmetic Items: They don’t serve much purpose except for the physical appearance on the player, this can be gender specific.
Generic Items: They don’t serve much purpose either, infact, many quest items fall into this category because you won’t be doing much with them, other than giving it to the person in quest.
Powerup: Powerup items are usually the Occult power up items, which acts as a passive booster for the protagonist’s power.
Bloodpack: It’s nothing more than a usual consumable item type, used for increasing the player’s blood pool.
Hidden: Self-explanatory, it only serves as a clean way for events to check if user has a certain “item”.
 
The progress on the inventory is going on nicely, dragging items, filtering the item types. There’s still some work to be done, but we’ll hopefully have some contents to showcase that soon enough.
 

Damage types:

There are a few important mentions regarding the damage types within Vaulderie with a brief description:
 
Bashing damage is done by blunt instruments (melee weapons), normal firearms and blunt trauma (falls). When a vampire suffers bashing damage, the damage is soaked using stamina and armor, then the total damage is halved, rounding down. Fortitude provides its level in automatic successes against bashing damage. Mortals and ghouls suffer bashing damage normally.
 
Lethal damage is done by cutting instruments (swords, knifes) and massive trauma (car wrecks, close ranged shotgun blasts). It is soaked using stamina and armor, and the damage is applied normally. Fortitude provides its level in automatic successes against lethal damage.
 
Aggravated damage is done by fire, sunlight and supernatural weapons to vampires. Fortitude does not provide automatic successes against aggravated damage, but you can roll a number of dice equal to your Fortitude level to soak aggravated damage, against a difficulty of 8. You cannot soak aggravated damage with Stamina, only with Fortitude. Armor soaks aggravated damage normally.
 

Quest Manager

The quest manager is the class that is going to manage the global quest states. It also allows you to mod the quests, along with setting the variables in real time, similar to the original game.
So how does the quest manager look like? It’s pretty simple. You get a quest table, which contains the quest entries, followed by their unique properties, such as title, ID, description, quest type, awards, and events, and so on.
 
Title: this is a simple text title, and what will be used to refer to it in dialog.

DisplayName: This is what will be displayed as the heading for this journal entry. These fields can be localized.

CompletionState: This container has all the various variants of a given quest, such as what happens if quest gets failed or if it succeeds.

ID: Each completion state must have a UNIQUE, NUMERIC ID. By default, a player is considered to be at completion state 0, when the quest is unassigned. The quest will not be displayed in the journal unless the player has a valid ID for the quest.

Description: This is what will be displayed as the journal entry for this quest

Type: This controls the font, colors, etc, for the quest. MUST be success, failure or incomplete.

Award XP: This is how many experience points to award to a character when they reach this quest completion level. Defaults to 0.

Award Money: This is how much money to award to a character when they reach this quest completion level. Defaults to 0.

Event: This is script data, such as a flag assignment or a function call, which will be passed to the script interpreter. By default, there is no event script called.
 
Most of the layout is done and since we’ve only started to rework our current system, it will take a while. The problem with rewriting any code, is that you’ll get better off rewriting it from scratch rather than improve upon it. Since the more you change, the more you need to change. Like art, you will never be satisfied with the results, and since this is programming, you’d always want to find a better way to code it, but sometimes keeping it simple is the best solution. As long as it does the job right.
 

Ads and Decals Concepts

Teemu has done a great job bringing some fresh life onto the forgotten city of Santa Monica, here are a few:

 

Physically Based Rendering

There’s this thing in the gaming industry and engines that started to pick up dramatically this years. Physically based rendering. But it’s not a new thing. It has been existing on paper for years now, only to be a trend, which is loosely defined, a real time rendering system. For those who don’t know, it’s a modern photorealistic rendering system, where everything is “shiny” and everything has Fresnel.
 
In short, this makes certain materials look photorealistic, in real time. Everything gets realistic the specular effect (which controls the mirror reflection, the lighting bouncing off the material). It’s been widely used since Unreal Engine 4, and the upcoming Unity 5 release, but it has been implemented before, in Unreal Engine 3 (Remember Me) and various Unity plugins (Marmoset Skyshop). In order to utilize this rendering system, the artist must get the textures to pass the needed requirements for the textures, which I will not get into too much detail. I’ve been experimenting with a few materials to be “PBR” ready, and I must say, the quality does differ from the regular shaders in Unity. For one I’m really excited to move into this pipeline once Unity 5 is released, although not to go too crazy and create an unpleasant visual result.
 
More information can be found here: http://www.marmoset.co/toolbag/learn/pbr-theory
 

Summary

Albeit things don’t always turn out the way they were planned, the project has received quite some nice progress even under given circumstances. I hope there’s more to show for the upcoming weeks (and hopefully no more unplanned events, then again that isn’t up to us). There’s always a lot of stuff that gets done but the excitement to show them has to be muted until it’s finalized.
 
We know development blogs meant to have any detail about anything, regardless on how little or how much has been done. It’s one of those times when a lot of the backend stuff don’t really have a proper result until you get around it.