Saturday, 31 December 2011

New Year Incoming

Happy new post apocalyptic year!

To the few readers of this dev blog - I'm happy you are interested in the project and will do my best with it for the new year.

Thursday, 29 December 2011

Weekly Break #2

Second weekly break? This cant be right :D

Ive had to basically redesign the whole player spawning and map transitioning system to make the player transition across maps without fear of losing his statistics, inventory or objectives.

The major problem I've encountered is that a mapobject can't have the player intellect set as parent. I do not quite understand why this is the case but i know it is hard coded to throw an exception upon creating it. So to go around it, I got the idea of storing a list in the player intellect which contains a "dumbed down" version of the player unit class (since this will remain the same with each map load and transition). Why a list? Well, I've created this system while keeping in mind that the user might want to be able to control multiple player units.

Therefore, the actual player units are not stored upon saving the map. After a map is loaded the intellect loads the list which contains what players it had, then physically creates them and applies the corresponding information.

Ive also modified the world creation function so now each map requires at least a spawn point. If one is not defined then it will search for a default spawn point. If any one of these does not exist then the game will throw an exception. Valve had a good idea to make spawn points mandatory with source, and im going with their method.

A quick example of a saved intellect below:

    type = PlayerIntellect
        type = ControlledObjectInfo
        name = Adrian
        life = 50
            itemType = WP_9mmAutoloader
            actionMode = 0
            juice = -1
            key = strength
            value = 7
        type = Objective
        missionFile = mission00
        logEntries = 0 1
        objStatus = 1
        type = Objective
        missionFile = mission01
        logEntries = 0
        objStatus = 0

Objective updating and log has been fixed as well. Map transitioning is still done by console only but its next on the list.

Wednesday, 28 December 2011

Weekly Break

More lua awesomeness
The more I work with lua - the more I love it. Its so flexible and dynamic, I feel that I made the perfect choice implementing it.

First van buren objective has been added into the game - Escape Cell Block 13 which completes immediately as the player leaves the map."Completes" is just a term right now as it only sets the mission status to a bogus number. I am going to have to decide how the system should work when completing an objective - keeping the objective and setting the status to an "end" number or removing the objective altogether. Im thinking of the latter, as the former would take unnecessary resources with already completed objectives.

Ive added a few events to the player intellect and objective to use with lua:
  • OnMapTransition (for the player intellect)
  • OnStatusChanged (mission status that is)
  • OnMissionEnd
Also in order to create a mission you must create the lua file as "mission0X.lua" in the Lua/Missions folder. This way you can use the command "addobj mission0X" when attempting to load it from the game console.

A command for loading maps has also been provided which can be used as "loadmap mapname". The engine will first search in the profile map folder to see if the player had previously entered the map, or simply load it from the default maps folder. Similar to the objectives, the maps must be placed in the default map folder.

Ive also fixed the pipboy objective window and it should show the correct updates. All the data for the objectives will be saved in the conversational database in order to make localizations later (that is if people are interested in modding this in their own language).

The problem which needs fixing at the moment is the objective status log. For some reason the log will not serialize the objective updates.

Monday, 26 December 2011

Evolution of the code #10 - Hearths Warming Edition

Ive been busy lately with the save / load, profile and map transitioning system.Ive also (hopefully!) fixed a few flaws in the objective system design.

I never thought attempting to remake some features from a game could create such coding horror stories. Really... I didnt...

The save and load system
As i have specified a few weeks ago, this game will heavily rely on the actual save system for map transitioning and simply copying the saved files into a different folder to back them up.

Therefore the map transitioning will behave as such:
Player attempts to transition from MapA to MapB.
  • MapA is saved.
  • MapB is loaded.
  • MapB and game world is saved as currentWorld.
and when returning to MapA
  • MapB is saved.
  • MapA is loaded.
  • MapA and game world is saved as currentWorld.
Ive also added a continue button in the main menu, which is visible if a previous game was started (and a currentWorld file was saved).

Why this system? Well, neoaxis can either save the map or the world and the map altogether. Naturally, the world should only be saved once. So i thought it would work by saving the world in a file, then the map in another file... which is not possible due to the saving issue specified before. Since that was impossible to achieve, i decided that saving each map in distinct files and a different currentWorld file which should contain the world and the last known loaded map. Its a lot more complex then i would like it to be but then again what isn't...

The objective system
Ive encountered two major problems with the old design:

1. Every objective was saved as a mapobject - that means each map was saving the objectives. These should be saved only once and remain the same regardless of any map transitions.

2. The objective list should have been saved into the intellect which controlled the entity and not the other way around. This means that the same objectives would remain - even if the user would control more than one unit.

So I had to rectify these problems and make huge design changes of which I honestly dont know which price these will come with. Right now i can only hope i won't run into any un-fixable issues later.

Well that should be about it for now. Happy holidays!

Sunday, 11 December 2011

Evolution of the code #9

Character creation window
This has to be the most annoying feature ive worked on as of yet - because im trying to do it as optimized / simple as possible and with no unnecessary code. This week ive got it semi-functional (as in the primary stats only can be manipulated so far). 

The problem i had was how to link the controls so that they would change the character statistics. Since all of the player statistics are stored into a dictionary (and dictionaries do not support indexes) I had to make use of the control names. So right now - to make a control manipulate a certain statistic (e.g. strength) you have to set the control name to that.

The upside to this system? 
Users who want to mod the game have complete control over the player statistics. For example you can replace or remove luck, intelligence or any other as well as add new statistics. Its just the simple process of adding the new statistic to the default player script file, then add a control using that statistic on the new game window and set it's name to manipulate it. After, make use of it using the lua script files.

I am sure this is better than using indexes or any other method, because the order of the statistics in the default script file or the order of the controls to manipulate them is irrelevant.

If there are any downsides im sure to find them soon. I really hope its done by next week as I want to continue work on other features.

Wednesday, 30 November 2011

Weekly Break

Lua script support added to every mapobject. Ive split the interactable object class into a luaobject class in order to make it easier for other inherited classes to include lua script support.

Lua and events added to spawnpoints. A script to add a main mission has been added as well as a new game starter map which is currently empty.

Functional tasks menu on pipboy. Of course it still needs proper positioning and detailing but the basis are there. If tasks are missing then there are none available to show.

Next on the list:
  • saving the world onto a file and the game map into another
  • detailing the pipboy
  • waiting and alarm clock
  • making the character creation window functional

Sunday, 27 November 2011

Evolution of the code #8

Right, enough skyrim and assassins creed - time to get back on the code.

Saving time and unit stats
Time can now be saved along with everything in the world. Unit stats (such as primary or secondary) are contained into a .NET dictionary regardless if they are player units or npcs. The problem is that serialization(or saving) of the instance is not included out of the box in .NET, but with a few tweaks im managed to force remember every data in that dictionary into the file.

Ive also managed to fix the player vs npc vs smarter npc problem which was present before. As i see it, in fallout there are 3 bases of units regarding the special character creation system. One which is very complex (the player), one which shares some features with the player (such as the primary status) and another which is simple (much like the non combatant standard civilian). The problem was that I had to differentiate these somehow and implemented the perfectly optimized solution.

Basically, right now every unit holds the character statuses in the .type definition file (including the player and those statistics will be set once the character creation window pops up). This ensures that no further memory is eaten up unless its needed. Once any of these statistics are modified, the unit will save the statistics differently from the .type file.

Having default statistics is as simple as setting the correct values into the unit .type file.
strength = 5
perception = 5
endurance = 5
charisma = 5
intelligence = 5

I suppose what is left now is to make the character creation window which spawns every time to work.

Objective window (and possibly other ones) will be non functional this week
Since I've begun working on the pip boy, I'm planning on doing a "modular" window similar to the one from the tech demo. Therefore some windows may not work until its completed.

Sunday, 20 November 2011

SVN link and some inspirational videos

Ive decided its time to make the svn available and let the public play with it. If anyone has any modeling skills available and can import models to neoaxis please do! If you dont know what version control is, check out Tortoise SVN.

Warning: Testing any of the features may or may not make the game unstable, crash or bug.

Link to SVN:

Somehow I always found this video very motivating when working on this project.

Sunday, 13 November 2011

Skyrim edition update

Skyrim menu style
Why? Because I could :D


This is going to be a very short update as I need to get back to my game :D
The progress has been show lately but I have managed to get the basic profile system done. User can now select a profile and save their settings there. Game time has been added but so far it does nothing except pass while a map is loaded. Will have to make it pass fast as user fast travels as well. I also got the chance to play with some of the particle effects and such. I just love that menu. It's so simple and yet well done.

The building roofs also need coding but the concept is already there. Its just a matter of entering a zone and hiding / showing a model as the player character enters or leaves it. No updates on the combat manager yet but I'm working on that as well.

That should be all for this week.

Sunday, 30 October 2011

Evolution of the code #7

Redundant code removal, interface log, camera improvements
Ive had to remove a lot of redundant code because everything was getting too blurry. This is also going to be helpful while porting to a newer version so I guess time was not really wasted.

The interface log really needed an update. The problem was that, the game is split into 3 DLLs - one which contains the interface, one which handles the actual engine and another which contained all of the entities. This created a major problem for the log with circular dependency because i had to send text updates to the interface from any entity. Thinking how I could solve the problem, I immediately remembered of the engine game console log. This log can be called to send an update or warning from anywhere so I figured this was the best method.

The problem? How do you catch an update sent to the console log in an interface control. Simple - by using a handler! This method is great as it does not need any extra code to generate that interface log, and I don't really mind if the console is getting spammed with in-game messages (hell, if valve did it with the source games, then i guess it should not bother me at all). So, currently, updates to the interface log can be sent from anywhere in the code (including lua scripts).

After working a bit more on the camera, it is now rotating as it should according the the azimuth angle (similar to the tech demo).

Ammo types in weapons, objective logs, turn based combat
Weapons now remember which corresponding ammo type it was reloaded with but does not affect the damage yet.

Objective logs have also been implemented and updates can be seen on the objectives window. Though it does not look rather good at the moment, until someone volunteers his awesome 2D graphics skills there is not much I can do. Its pretty optimized as it remembers only an integer array of the mission updates(with which updates are extracted by using it as an index into a database) rather than full strings.

Ive also updated the Anson mission lua code a bit: The locker can be looked into at all times but if the player looted the locker before he accepted the mission then a problem is generated; the "drugs" which are needed in order to accuse Marienne have already been taken. I solved this by adding new items in the locker(via lua) when the user interacts with it while the mission is active.

Regarding the turn based combat system - I think I broke it or there were some major flaws. I might have to literally get back to the drawing board with the combat manager next week...

All and all, everything is taking shape. Must take care of that turn based combat manager, implement a few features of SPECIAL, ammo and damage modifiers, missed shots, profile saving and loading system and I believe its ready to be remade the van buren missions on! Will post on a few places to get a bit more readers when that happens but for now that is all!

Sunday, 23 October 2011

Evolution of the code #6

Radiation, Geiger Counter
Today i wanted to implement the radiation zone and a geiger counter. After all, what IS a fallout game without radiation right?

The zone itself is nothing special - it simply checks each entity in the zone and notifies it that it entered a radiation zone, then  applies damage if its close enough. The geiger counter was also implemented and its sound delay is relative to the distance the player is close enough to the actual damage zone, instead of the center of the radiation zone.

Empty clip sounds, Reloading and more lua
I have also added the small details to weapons and sounds can be set now. Due to the way neoaxis is made sounds for deploying and holstering an item can also be created. Since last week ive exposed a function to lua in which any property can be set - this week i decided to expose every public function the entity has. This basically means that, as of now, any mapper can do pretty much anything with a lua script.

In the video below I tried to show a bit of the updates (turn based combat was disabled).

Wednesday, 19 October 2011

Evolution of the code #5

Doors, lockers, generators
First of all, sorry for not updating during the weekend and hope i dont lose the few followers i have but as previously stated this is a hobby project which took a year so far, so bear with me.

This week I attempted to add a bit of new code / lua into the game by creating status objects (objects that need to be somehow enabled - similar to locked doors, lockers or broken generators) and keys / keycards (or general objects that are needed).

Since I'm always going for generalization, all of these are derived from one new base class named StatusObject (which stores a new boolean used to decide if the object is enabled, and a string of the object key type which is unlocked by). I have also added two new functions to c# and exposed them to lua where the mapper has access to any property of that object.This makes mapping and luascripting loads easier so I will pat myself on the back for now since I'm the only one using it :D

Lets take for example the situation below. I have a console (or generator), but it is deactivated and nothing will happen when the user clicks on it.

In another chest is a red keycard. When the player equips it and clicks on again the generator/console is enabled and can be used to toggle a light with a bit of lua code.
function OnInit(instance)

function use(prejudicial)
    if IsDisabled() == false then
        local light = GetEntityByName("Light_1");
        local isOn = GetProperty(light,"AllowDynamicLighting");
        if isOn then isOn = false else isOn = true end
        SetProperty( light, "AllowDynamicLighting", isOn );

The same will be applied for all of these objects, but currently the repair or lockpick skills remain to be added.

Sunday, 9 October 2011

Evolution of the code #4

New game
Ive been trying to set up a proper new game system for some time now and finally managed to get a little bit work done on it. So far everything it does is - when the game starts and the main HUD panel is shown, it checks if the player has any primary statistics points available to spend and immediately shows the new game panel. After that simply checking if the player has spent all his available points in order to close the panel should be enough. This means you must load the first map each time when trying to start a new game and then building the character. I cant really say this should have any negative effects since other games have done this. Will have to set up the proper perks and how to actually modify the character stats corresponding to the window in the future.

I have made some modifications to the save system as well because the game will heavily rely on it. Most notable fix is that the actual item in a character's hand is not saved in the map anymore. The inventory remembers what items it has in each slots and creates them on load. 

As i have previously said I am planning on using the save system in order to transition between maps. So when exiting a map, the map file will be saved and another saved map will be loaded. What i find very useful with this is that, in theory, all the items dropped on the ground should be available each time the map is loaded.

Bugfixes, ammo count, HUD
Some bugs were fixed, others were generated but currently the action point counter works as it should. I have also added an ammo counter next to the item selection control for the consumable items, so the user should know how many times an item can be used from now on

This week ive added two more base classes for the items: health and explosive; I dont know if any improvements should be made to the health item class (except differentiating the effect type and value wich i will probably do as arguments in the script file in the future) but the explosive still needs improvements. I have also added a window class which returns a TimeSpan value so the timer can be properly set.

That should conclude this weekend update. I also realize that these graphics may look badly or non professional but keep in mind im using paint and free resources from the tech demo and only prefer focusing on the actual code.

Monday, 3 October 2011

Weekly Break

Well, apparently i am still going to hold all of the formulas in one lua file. Yay for moddability. Heres a video of the current combat, items and inventory system.The weapons do not use any ammo, some of the physics is chaotic and no one knows whats going on with the HUD but progress is being made. Dance ragdolls dance.

Saturday, 1 October 2011

Evolution of the code #3

Time for another update. Since I've felt a bit tired over the week (and this is a hobby project) i will probably update the blog in weekends (and sometimes during the week) from now on.

Implementing SPECIAL (or simple)
I decided it was time for the early stages of the character creation implementation. Ive started reading the manual of the fallout pnp and let me tell you, its a lot more complex than i thought. As I am trying to go for maximum moddability i was thinking of doing all of the formulas in one big lua script that applies to all the npc's. The problem is that - as i see it - every instance of a character class would open an unnecessary instance of the same lua file. That would be a resource hog; I could also do a static version and hold all the formulas needed in a lua script and the entity logic(if it exists) in another - but again that would mean extra unnecessary resources used.

I am thinking of abandoning the plan and simply code the formulas in C#. Thus one would have to recompile the solution if he would try to mod the game. Still thinking about this and i really wish i knew someone that is experienced enough with lua implementation and code optimization.

Ive also added all of the stats, skills and traits into a dictionary class rather than an array and i think it will remain that way since its easier to access data even from lua.

Unarmed attacks - from hard coded to items

Initially when i started working on the item system i hard coded the unarmed attacks with two simple options. I didnt like the idea and got to the conclusion that these need to be recoded as items. The system is simple - Check the active item and see if the slot associated to it returns an item class. If not create the corresponding melee items. Indeed, Ive taken measures to prevent these "items" to be traded or seen in the inventory (imagine how funny it would be to barter your punch or kick skill with someone).

I really like this system as, in theory, it would be possible to control 3 or more characters - each with his own unarmed skills. This also made me update the item action system with requirements. For example you cannot perform a haymaker attack without Unarmed 75%, Agility 6, Strength 5, level 6 and thus it does not appear in the action modes while selecting through them.

Thats about all for now so i must get back to work. And ponies.

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:

actionPoints = 4
useText = SINGLE
actionPoints = 6
useText = BURST
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
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
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
value = What kind of an asshole question is that?
value = Your hands are warm.
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.

function OnInit()
local target = CrateEntity("Girl");
function target_death(prejudicial)

- OnInteract (activator)
- OnDeath (prejudicial)
- SetMissionStatus (int)
- GetMissionStatus (returns int)
logUpdate = "";
function OnInit(instance)

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);

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.