Saturday, 24 September 2011

Evolution of the code #2

The items
In fallout there are two main types of items.

- The ones that are useless when holding - much like the rocks, or if anyone can remember the magic 8 ball from fallout 2 which i will attempt at remaking later on.

- Consumable item. This means anything that "uses" something in order to have an effect. For example health items can only be used a few times or the weapons which use ammo unless they are reloaded.

Therefore the base classes of the items should be split as such. This leads us to the following chart:
 Although all items are derived from the multiple action class it is because the item actions are defined in the class type file. I found this useful as in each item action we store the action text which shows on the HUD and the number of action points it takes. For example a weapon would read like this:

actionModes
{
item
{
actionPoints = 4
useText = SINGLE
}
item
{
actionPoints = 6
useText = BURST
}
item
{
actionPoints = 2
useText = RELOAD
}
}

The magic ball
Basically it is an entity that stores an array of strings and prints a random string when it is clicked on. Since there is no baseclass that does this, i had to create a separate item class for it:

public class StringListItemType : MultipleActionItemType
{
[FieldSerialize]
string[] stringList;

public string[] StringList
{
get { return stringList; }
set { stringList = value; }
}
}

public class StringListItem : MultipleActionItem
{
StringListItemType _type = null; public new StringListItemType Type { get { return _type; } }

public string GetRandomString()
{
int index = new Random().Next(0, Type.StringList.Length);
return Type.StringList[index];
}
}
Simple enough, right? Let's take a look at the type file:

type IT_8ball
{
class = StringListItem
soundTake = Types\VBEntities\InventoryItems\HealthItems\Health.ogg
physicsModel = "Types\\Dynamic\\SmallBox\\SmallBox.physics"
allowEditorCreate = True
networkType = Network
attachedObjects
{
mesh
{
meshName = Types\Items\BulletItems\SubmachineGunBulletsItem\SubmachineGunBulletsItem.mesh
castShadows = True
scale = "0.5 0.5 0.5"
}
}
weight = 2
itmvalue = 3000
invIcon = Gui\HUD\interface\inventory\ITEMS\IT_8ball_INV.tga
actIcon = Gui\HUD\interface\inventory\ITEMS\IT_8ball_INV.tga
stringList
{
item
{
value = What kind of an asshole question is that?
}
[...]
item
{
value = Your hands are warm.
}
}
actionModes
{
item
{
actionPoints = 2
useText = SHAKE
}
}
And after putting it all together this was the result:


Now what else should we look for with these useless items? Well if we have an ammo type in our hand we should try and reload the first weapon in our inventory which uses it.

Weapons and health items
In order to create weapons, grenades, heath kits and other items we simply use different base classes.

Monday, 19 September 2011

Evolution of the code #1

Confound this inventory code!

Sometimes everything gets more complicated than it should...

I have decided to use the term "inventory object" rather than a character because in this game characters are derived from lockers! Hey, both are entities capable of holding objects right?  :D

How it works:  In simple terms, an "inventory object's" inventory list holds instances of a class which, in it's turn holds the reference of the actual inventory object type that should be created along with other data. Thus when an object is picked up from the ground it is removed from the world and in it's place a class is added to the inventory list which holds the item's data. In the same manner when one object needs to be discarded it removes the entry from the list and creates the actual object in the game world.

Initially i thought this was a bad idea! During my first attempt to code the inventory system, I somehow figured that simply making the "inventory object" hold instances of items should work out well. How wrong i was. One of the major flaws is that every item in the inventory must have an instance on the map. That is a major resource hog and not optimized at all. Ignoring that, this would also make a very bad idea for mappers as they would have to create every instance on the map, set it as invisible and manually add it to and "inventory object's" inventory list.

Thinking about it a bit i thought of this idea of replacing it with a more simpler class as described above. After that i discovered that was the initial inventory system implemented in neoaxis. Lesson learned - lurk more code before attempting to reinvent the proverbial wheel.


So why is this all complicated? 

The interface
The interface is based on a few custom controls that are more complex than i would like... Fallout has two types of inventories: Player inventory where the player interacts with the items he owns or multiple "inventory objects" where items are swapped between them.

When a player inventory is created on the screen, the gui control list must be filled with a "slot" class for each item in his inventory. This slot class must know which item in the inventory it links to, if the user wants to relocate that item into another slot (or another inventory) or similar events.

That takes us to what i like to call "holders". Each slot must remain in a "holder". Holders can be the actual gui inventory on the screen or holders for primary or secondary weapons, armors and such. Thus, each holder that is considered an inventory must have a link to the actual "inventory objects". Therefore we assure a way to swap items between these "inventory objects".

I know two objects to "barter" are more than enough, but with a few extra lines of code, I used lists to make it possible for any number of "inventory objects" to trade. I like how it turned out! :D


 The items
So now that we can manipulate these lists a bit we need to actually make the player hold something. After lurking a bit from the existing neoaxis code i have found that the best way to do this is to store an ActiveHeldItem variable. By my logic, this should be updated every time the player switches between the primary and secondary weapon slots and when the player set a new item in one of these slots. This is where i need to work on a bit more... :D

I will get to those in the next update...

Sunday, 18 September 2011

First update

A bit about neoaxis first.

When i first started working with it if felt different, coming from the source engine especially since the documentation doesnt really exist. The engine is very capable and as with most engines the quality of the project depends on the resources imported into the engine and not the engine itself. Here is the perfect example screenshot:


Now onto the project.

First of all the project has no custom content whatsoever. Every resource which i have used was included in the engine demo. It would be nice to have content from the VB tech demo imported but i would rather work more on the programming aspect of the project. What i am after with this project is provide the tools necessary for the community to say create a fallout style game / mod / whatever and since the van buren tech demo resources and design documents are fully available i think this is an excellent opportunity.

As i've said neoaxis is very capable. One could remake any feature from say the source engine into it (custom loading per game progress menu, the entity input and output events, game rules and such. Its just a matter of recreating the code or importing it to C#).

Programming wise, all of the features in the project are done in C# and lua. Since neoaxis cannot create logic dynamically while a map is running (everything has to be "compiled") i have decided that lua is the best way to go and so far it has not proven otherwise. The actual code is on an older but stable version of neoaxis which was available when i started working on the project about an year ago - so after most of the features are working everything would need importing into the latest version.

The project currently has many features working but at the same time not enough. Some of them below.

The dialog system is based on a modified version of the conversational library for neoaxis which i found here. Ive expanded it to include alternative replies based on intelligence, visibility options (regarding mission(s) status or anything that needs to be checked for a reply to appear or not) and engine commands which are used to affect the actual game world by having a dialog with an npc (giving an item to the inventory, starting the combat, changing faction relationships, quitting the game and so on).

The combat manager ive programmed myself from scratch. It is basically an entity that decides which character has the turn and is saved along with the other entities. This makes the save / load system easier to work with and is capable of saving the combat status.

The quest system is another feature i have made from scratch. It is very flexible in my opinion and can be used to create a quest only with a few lines of code and character dialog manipulation. As with other entities, it includes lua so events of the quest can be accessed easily by mappers/scripters. It still needs work on the quest log updating and the quest interface.



As i have said my goal is to provide the community the tools necessary to make a fallout related project, not to develop a game. Therefore, I plan everything to be open source and included into a subversion in the near future.

--[[
MISSION TEMPLATE
--]]
function OnInit()
local target = CrateEntity("Girl");
target.OnDeath:Add(target_death)
end
function target_death(prejudicial)
EndMission();
end

--[[
ENTITY TEMPLATE
ENTITY EVENTS
- OnInteract (activator)
- OnDeath (prejudicial)
FUNCTIONS
- SetMissionStatus (int)
- GetMissionStatus (returns int)
--]]
logUpdate = "";
function OnInit(instance)
instance.OnInteract:Add(use)
end

function use(prejudicial)
if GetMissionStatus("mission01") == 0 then
logUpdate = "You found Anson's drugs. Looks like Marienne has some explaining to do.";
SetMissionStatus(prejudicial, "mission01", 1);
end
end

This concludes the first update. Since i prefer to show pictures rather than words, this blog will contain a lot more pictures in the future.

Saturday, 17 September 2011

Project updates blog

This blog will be used to keep track of the project development updates.

The van buren project is a remake attempt of Interplay's cancelled game Fallout Van Buren on the Neoaxis Engine.
http://fallout.wikia.com/wiki/Van_Buren
http://www.neoaxis.com/