Interaction System news

If you haven't heard about From Earth before, read the outline of the project here.

One of the biggest systems in From Earth is the complete overhaul of how weapons and items work in Source. Early on I completely discarded the default weapon classes, removed all their references from the source code, and started working on my own. I even completely removed viewmodels, since I render the player's world model even in first person.

Redoing the weapon and item system was necessary, because how differently I needed to do things. Item have functions, such as pressing the trigger, or pushing buttons in them. The player character, however, doesn't always know what they do. The player can examine items, and see all the different buttons and triggers on it, and which mouse and keyboard keys activate them. I needed to integrate all the data about the buttons, and how they should be visible in the HUD during the examination, into the models and the item base class.

I also wanted to have pick up, drop, holster, and deploy animations so that you can see the player character place the item on her magnetic belt. This meant I needed to handle the way weapon animations work, and have different states for when the item is being picked up and so on.

Not only does the player entity handle items differently, but NPC's handle them differently as well. In Half-Life 2, the way most weapons are used by NPCs, is coded into the NPC's AI, and usually are limitied to playing a single animation for pressing the trigger. In From Earth I needed to be able to do something little more complicated in case of some of the items. Each item can have their own specific instructions when or in what kind of situations the NPC can use the item, how to use it, how to run the AI task and which animations to play.

It's pointless to do redo work you don't have to, but sometimes better to start from a scratch than to work on top of someone else's code. If I would have used the existing weapon classes as basis, it would have meant I would have had to edit their behavior and structure significantly anyway.

There's three type of interactive entities.

Items:
Items can be picked up, and in most cases, can also be holstered to inventory. They can have up to three buttons, and the item can be examined with a press of a key to show the different buttons on the HUD. The three button (or rather three function) limit comes from the number of attack keys: +attack (default mouse1), +attack2 (default mouse2), and +attack3 (default mouse3). This limitation can
be restrictive, but it's the best way to give the item easy functionality. The item model has all the data about where in the model the buttons are, and what type of buttons they are. Some items can also be combined with each others, such as attaching an ammo clip. Items can be placed into Interactive Machines.

Interactive Machines:
Interactive Machines are stationary machines in the world. They can have as many buttons as you want, since the player simply looks at a button and always uses the +attack key. The +use key is used to place Items into item slots. We use a different key for this action, because in some cases a button and a item slot can overlap, and it would be annoying pixel hunt to get the action you want.

Just like with the Items, the Interactive Machines have built into them all the data about the buttons and where the player should move to use them. Interactive Machines also have attachments for Inverse Kinematics, to tell the player entity where the hand should be when pressing a button.

$keyvalues
{ 
	"hlss_settings"
	{
		"continuous" 		"0"			//some interactive machines can be entered inside
	}

	"hlss_buttons"
	{
		"Button"
		{
			"attachment"	"Button"		//name of the attachment on the model
			"type"		"normal"		//there are different type of buttons that have different behavior
			"hitbox"	"1"			//the hitbox helps to define how the button is drawn on the HUD
			"position"	"position"		//the name of the attachment to where the player entity will move to use this button
		}
	}

	"hlss_useposition"
	{
		"position" "1"					//reference to the position attachment and which hitbox in the usebox hitbox set to use
	}
}  

Currently the player entity doesn't have a navigation system, meaning it only knows how to move locally. This is, because the AI navigator class in Source 2007 requires it to be embedded into a NPC. The buttons in Interactive Machines can only be used if there's an empty spot in the use position, so only having local navigation for the player is enough.

Interactive NPCs
The third type of interactive entity is the NPCs. From Earth doesn't have any kind of dialogue trees to choose what the player wants to say to an NPC. Instead, there's only simple Output function that gets fired when the player tries to comminicate with an NPC. The Level Designer can hook this to a choreographed scene or scripted sequence. You can also trigger a Response Rule or Pointing Mode similiar to that of Water.

However, if the NPC is holding an item, the player can ask a question about it by looking at it instead of the NPC. Similarly, if the player is holding an item herself, the player will automatically try to ask a question about that item. The response can be anything from simple bit of dialogue, the name of the item in the alien language, a small shake of head or nod, to giving the item to player, or firing an Output function.

They use Interact Scripts to define what action or output they should fire when the player tries to communicate with them. This came from the need to be able to easily define bunch of different reactions depending on what item the player is holding. Without using some kind of script file, it would have been nearly impossible. There would have had to be several different logic_relay and logic_branch Hammer entities and filter_classname entities to make sure the right output is fired in the right time. The only downside of the scripts is that it can cause part of the map's outputs to be hidden from the Level Designer.

	"hlss_bottle"					//in this case, the classname of the item
	{
		"type" 		"item"			//we are responding to an item the player is holding in her hand
		"point"		"1"			//the player should do an animation of pointing at the item before the NPC can fire the response
		"response"	"take"			//the NPC should take the item from the player
		"name"		"wantbeer"		//name of the entry which can be referenced to by level designers to enable and disable responses
		"enabled"	"1"			//if disabled, the entry is ignored

		"requirements"
		{
			"beer" "yes"			//special requirement to make sure the bottle is not, you know, empty
		}
	}

In this example, the "wantbeer" response can be disabled after the NPC has his beer bottle. There's also the option to set the item classname as "ANY", to give a generic response the any item the player might be holding. The code will go through all the enabled entries in the script, and it will pick the entry that has most unique conditions. For example, if an entry has the class name set as "hlss_item" and a modelname defined, it will choose that entry over any entry that doesn't.

In Point Mode the player can simply point at items or Interactive Machines the player wants to ask about.

Thoughts

The system for Items, Interactive Machines, and Interactive NPCs has been improving and growing since we started the project over an year ago. I have also been redoing parts of it to make it better. the current system allows for a lot of things including wearable items as well as combining items together.

Next month we will tell you a little bit more about the Climbing System in From Earth.

Looking for help

We are still looking for people. If you are interested to apply, you can send me a message on Moddb, Twitter, Facebook, or e-mail me at au-heppa@hlssmod.net.

Level Designers
We are looking for two different types of Level Designers. Firstly, we need people that can bring existing levels an aesthetic quality, and are experienced with lighting, texturing, and the general make up in Hammer. Screenshots and/or example maps are required.

We are also looking for puzzle designers, such as anyone who has a lot of experience designing different types of puzzles for games like Portal 2. Source engine or Hammer experience is not necessary.

Concept Artists
Most of the concept work will revolve around the industrial era Alien technology and architecture. Samples of previous work required. We already have a strong set of existing concept art for you to draw on.

Voice actors and actresses
Although the script is nowhere near ready, we are looking for people to play the parts of Zenaida, Anthony, as well as the generic voices of aliens, both male and female actors. All voice actors applying should provide some kind of samples. You should be able to do big range of emotions. Some lines might be delivered at a later date.

The aliens will be speaking an alien language specifically designed for this mod. Their dialogue is partly already written and ready for recording. Examples will be provided if you are interested.

Other
We are interested on getting any help we can get, especially world texture creators and prop modellers.