Author Archives: atrblizzard

Friday Devblog 6

by
Project Vaulderie - Discipline

Hello Kines and Kindreds, this is going to be a rather traditional and short development blog, mainly discussing about the more transparent work. As a short reminder, things are still picking up slowly on my end, from the incident last week, so I do apologize for any lack of real content.
 

Level design

Getting the maps converted from Source to Unity is no simple task, it requires a lot of reworking off the original map layout. However they allow far more control over them in Unity, and here is it why. 
Continue reading →

Friday Devblog 5

by
Project Vaulderie Gangrel Wallpaper

Hello Kines and Kindreds. This is going to be a short one, possibly the shortest. There were some unfortunate circumstances happening in my life which I won’t be entering into too much detail, involving a funeral of a distant family member. Even so, the show must go on.
 

Playable Characters

As we discussed in the prior blog post, character creation for a game such as Vampire the Masquerade: Bloodlines would be ideal, however the effort to this would be tremendous and cannot be fully achieved without the help of the community once we’re comfortable enough with the measurement and skeleton rig necessary to carry on not only player movements but cutscenes as well.
Continue reading →

Friday Devblog 3

by
Project Vaulderie - Character Sheet v2

Another week, another set of updates to talk about, even when we are light on media.
 

Level properties
 
Gameplay is very crucial, and in order for the player to be able to interact with the world, we need to implement those features from scratch. Since we’re aiming for modding to be as close to Source in terms of how these entities communicate with themselves, it’s important to set them in a manner that is as user friendly as possible.
 
One of the major differences between the way Source handles entities and with Unity handling its GameObject, are the way they are initialized. In Source, in order to give a certain function to a entity, we tie that entity to a specific entity. For instance, if we were to place a model into the map that has no purpose other than behave as a prop, we set it to be a prop_static for a static prop and from there we select which model we want to use. But on Unity, and on most modern engines, it’s the other way around. We add a mesh into the game that in turn creates a GameObject rendering given mesh. In order to add any given behaviour or purpose to this game object, we attach a stript to it that handles that. Since we attach scripts, we can attach as many scripts as we like, while also keeping them modular.
 
Continue reading →

Friday Devblog 2

by
Development Blog Header 2

Hello Kine and Kindred alike! As the day approaches, here’s some good progress going on. This week, most of the focus was put on the UI, the lobby system and AI.

 

Ai
Development on the AI continues, but since we’re building it from scratch, we’re experimenting with various ways on improving it from the original game, making them perform well.
 

 
Right now we’re experimenting with the monster AI since we’re still getting the weapon management to be set up for the multiplayer which we’ll be adapting to NPCs as we progress. The way the models and animations were setup in Source require some extra work and since we are using legacy animation (more about it later), we’ll have to resort to blending them in various layers, which is near perfect and will probably be replaced once Mecanim suits all of our needs.
 
Monster AIs are great to experiment with because they resort on a few states to get the behave as intended without worrying too much on the visual part, such as the animation layers and other movement blending. Almost all monster AIs use a “forward path” movement which means they’ll be moving towards you and start attacking you without much strafing.
 
Since we’re doing basic AI right now, we are planning on using dynamic pathing using A* AI. This gives us three main focal points for our AI navigation system:
1.) A* pathfinding
2.) AI scheduler (for more realistic ambient NPC example, people going to the diner, walking to the club, random alley fight, etc)
3.) The use of cone of vision, line of sight, auditory sphere of influence for reacting to environment sounds are a few to.
The A* will prove all the needed features so the NPCs can intelligently follow the player through complex layouts of a map.
 
The way Troika originally created the NPC system is far from being perfect, from having them write their own AI code from scratch in such short time lead them to create an AI system with huge ambition but little time to improve. Improving the AI pathfinding can improve the life of the game a lot, creating a more dynamic environment populated with NPCs that can perform far more tasks than just move between points. We’re excited to bring more news regarding the AI system in the near future.

Continue reading →

Friday Devblog

by
Ocean House

Welcome to our first Friday Devblog. A lot of people are grumbling that we’re not giving enough updates on the development of Project Vaulderie. We thought it’d be best to keep we start posting weekly about what we’re doing, in order to keep you kindreds posted about what’s happening and why it this damn thing going so slow. Even if that means if nothing significant was done over the week.

 

Bringing the game alive

So this week I’ve been taking a closer look at the various entities the original Vampire the Masquerade: Bloodlines game had and how we would approach this on Unity. This sounds easy right? Well not at the beginning not, since Stephen is working on the editor, most of the work I’ll be doing will have to be rewritten in order to fully work with it once it’s done. But what the hell, experimenting is always fun, isn’t it?

 

As I’ve heard from a lot of you folks in the past, if we can’t get the haunted props to work in the game, then the game has no meaning to be done, right? Not anymore, here’s some spooky prototype that’ll bring you the chills and make you skip the Ocean House even more than before.

Continue reading →

Forum is now open!

by

We have a little something we’d like to share, is that our new forum is now fully live!

Registration is open and feel free to post your questions! For easier registration, we’ve also included support to register via Facebook Connect for easier use.

 

We’re hoping this will help keep things a little more active and interesting if we can get a few more stuff going, not only from our end but from the community. Since the forum is mostly focused on the development side of the project, and since we’ve been getting a lot of attention from modelers and coders who wish to be part of the development process, we want to make sure we’re providing a centralized place for that.

 

As always, we hope you enjoy your stay and be sure to keep an eye on more development content!

 

Lip synching - The Face That Built Bloodlines in Source

by

We’ve been asked a few times by now, how do we handle the lip syncing in game with Unity? There isn’t a lot of rocket science behind the way that works, but I hope I can make some sense out of this.
 

Since the original game was built on Source, it was already built with such features in mind that can help us get more or less the same results: blend shapes. For a little behind the scene part, Source utilizes flex blends or morph targets to control the facial expressions and lip sync. Each of these expressions are implemented into each character model, mostly exported as a separate vertex animation data file, based on FACS (Facial Action Coding System). that results into realistic facial expressions. Each of these expressions are stored as presets, where each preset has a set of flexes configured for each phoneme or expression. For example, an expression can have multiple flexes turned on to create the appropriate expression without creating new blend shapes for each minuscule changes.

Continue reading →

From Source to Unity

by

For working with Source engine for these past few years, there’s only one thing to add: it’s horrendous. Source was built on the Quake branch, from which GoldSource was born and later on followed by Source. There was always an imprecation with creating mods on Source. The time it takes to develop a game can add up to months, even years compared to what modern engines can do. Unfortunately, Source always suffered and were criticized for their “painful to use” tools and the lack of providing a fully fledged engine and SDK to work with.

This is when we said, enough is enough. Bloodlines Resurgence always suffered because of that. Lack of programmers experienced with the Source engine, facing difficulties with engine branch versions, painful tool sets. The art pipeline is not much friendlier either. Creating models need to append to the QC files, compiling and so forth, but we will get into these details soon. It’s a lengthy process without leaving much reward behind it. Because of these, the project never really lived up to its expectations: to have a fully ported version of Vampire the Masquerade: Bloodlines. The only reason why multiplayer was taken into consideration rather than the single-player due to the expectations that are required for a fully finished RPG game: skill points, game mechanism, inventory system and so on.

Continue reading →