Another week, another set of updates to talk about, even when we are light on media.
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.
Another major difference with Source is the way these entities communicate. You can set up relay triggers, you can set up event based input/output that is pretty much the core of the map and the way entities behave. Including AI and other game logics. In Unity however, we can set up a similar way to have them communicate between themselves. From various input and output methods to delayed actions.
It’s relatively easy to add functions to any objects. For instance, you just set up a door to use the doors script and everything is handled by the script: open/close when being “used”, be able to be locked/unlocked with our without the doorknob speciality. In the original game the doorknob entity handles the lockpicking mechanism checks, like the player’s lockpicking skills and then passes it to the attached door. There’s not much of that to show yet but soonish we’ll get there too. There’s a lot of stuff that we can improve within the core mechanism but that also comes in a later update.
Here’s an example of simple functions mimicking their action similar to Source:
The work on the AI is going good. We’ve switched to A* pathfinding in order to grant us intelligent path finding, for example the AI to be able to follow the player properly until certain circumstances occur, such as loses sight of vision for too long. It will try to hunt you down until it gets “confused”.
The next thing we’ll be implementing are behaviours. Depending on which behaviour is set, the AI will act accordingly. These can range from simple stances to follow player or attack the player. They can also be set to use certain custom scripted activities by the modder, to do specific actions when triggered. Similar to Source’s scripted sequence and activity behaviour combined.
AI attributes can also depend on the relationship between the rest of the NPC or player. These include aggresion, confidence, assistance, if it’s a boss enemy, and of course, the Vampire the Masquerade discipline abilities.
The progress on the multiplayer backend still goes on strongly, although we don’t have much to show yet, Stephen will have a surprise for the next week to showcase it.
Teemu has once again got us by surprise with these fantastic new concepts:
Even if we’re light on media at the moment, we’ve done quite a lot of progress on the game mechanics and AI that aren’t shown here, because we wish to show something done and working rather than bits of updates each time, or at least on a functional state. There’s a lot of progress being done on the core elements of Bloodlines (something that involves computers), but that’s for the next time as we still have a couple of stuff to crunch down before we think it’s ready.