Wednesday, 12 June 2013

Evolution of the code #13

First companion implemented! As expected, the AI class is a subclass of the standard NPC AI, except that it helps you in combat and follows you around when you command him. To make things more interesting, I also added him a conversation file where you can tell him whether to follow you or not, or to use his best weapon or holster it. So far he is really helpful in combat and for the upcoming demo I doubt it needs any improvements.

Menu and HUD improvements
Remember that small menu that popped up when we wanted to do an action on an object? Well its here and currently has the first interaction buttons. The only difference is that it activates when right-clicking on an object (similar to VB) rather then when holding the left button longer. A clock has been added on the HUD so the player can tell the game time as it passes (I used it to tell whenever the player regeneration rate had passed or not).

Two new controls have been added to the base UI controls. The CommandButton is a simple button that triggers a console command. The PlayerPropertyDisplay class is used, as suggested by the name, to display and update any player property on the HUD. This can be either the Name, Health, WorldClock, the item he currently has in the inventory, etc. I found these controls necessary as I felt the need to add windows or controls on the HUD without changing the actual code in the executable.

Skills and SPECIAL
Skills have been implemented and they are partially working. I say partially because the code to apply a certain skill has not been implemented yet. It is surprisingly easy to add a new skill or delete the existing ones without any changes to the code.

I am planning to add every engine calculation that was done in fallout in lua files, for maximum flexibility. This would mean making changes to the game's basic calculations only in script files. Lua files have been added to player classes which contain a few formulas.

For now, a skill is firstly defined by its button name and the function it does is defined in the player lua file by the same name.

Basically, in order to add a skill the steps would be: add a button to the skill panel containing its name (note that the text formatting can be a problem and may cause errors), go to the player lua file and define a new function which is named as the button in the first step. This will make the button trigger the function in the lua file when needed, provided the names are the same. This may be a problem with localizations later but I'm planning to replace all of these with command buttons so that the actual names will no longer be relevant.

Tuesday, 21 May 2013

Evolution of the code #12

Inventory system bug fixes
Since the inventory system has been remade from scratch, it was bound to have problems which were supposed to be fixed later on. One new feature I added was to make sure that multiple items of the same type stack each other instead of creating new entries into the inventory list. The (sort of) problematic issue here was that, each entry in the list was associated with a certain item in the inventory. So, if multiple items were found, an existing entry was updated with the most recent count of the items.

If the user would drag at least two stacked items of the same type on the primary and secondary slots, then new visual entries pointing to existing instances would have to be created. This was resolved by storing all of the "unreferenced" items in the inventory into a separate list and when needed to create a new entry simply get the first entry of that item type from there.

Combat Manager finally working, some AI tweaks
Indeed it's finally working... I hope :D There was nothing special to do here except create a new entity each time combat was started (so that the combat status could be saved along with everything else in the map) that would freeze everyone in his place and take care of the turn based rules. Weapons are finally working as well (unarmed and the pistol) and don't crash the game anymore. Each weapon now has action modes which are define by entries like the one below:

actionPoints = 4
useText = SINGLE
command = firearms
damage = 6
useDistanceRange = 0 40
playSound = Sounds\weapons\9mm\fire.wav
betweenFireTime = 0.3
actionPoints = 6
useText = BURST
useDistanceRange = 0 35
command = burst
actionPoints = 2
useText = RELOAD
command = reload
playSound = Sounds\weapons\9mm\reload.wav

As it can be noticed, the unarmed attacks have been implemented as weapons as well. This was done for easier implementation of unique characters. For example if we would want a raider to have a very powerful melee attack, we would simply have to add that as default item in his definition file instead of extra scripting.

Since i always avoided having to do AI I am trying to keep it as simple as possible. Right now the opponents have the basic intelligence of attacking, following and switching to better weapons in their inventory if any is available and has ammo in them.

One more change that I felt was necessary was now the characters walks to an object before he interacts with it. Until now picking up a weapon or talking to a person was done without checking the distance between the characters or any other requirement. This was fixed and now the player must walk to the object before interacting with it. (yay!)

Plans for the next updates

  • Separate the interface items such as the log, combat interface, weapon holders, etc for a more modern look
  • Further bug fixing
  • Implementation of SIMPLE rules and character system 
  • Implementation of visual resources; its time to get rid of those placeholder models and make way for something better
  • Next milestone: complete implementation of the Tibbets prison level to act as a demo
Please note that help is still needed. A few people replied but it never went past the email stage.

Sunday, 13 January 2013

Back in action

I have decided to restart working on this project as I would not want all of the work to go to waste. However help is needed as I would prefer not working alone on it as before. If anyone would be interested in helping with ANY of the below areas and has modded games or worked with engines before please feel free to contact me at once at

  • Creation and/or implementation of graphic models and resources into the engine format [Required most of all]
  • Implementation of the character creation and damage probabilities
  • Implementations of the quests and quest order while getting the info from wikipedia or the released design docs [lua scripting knowledge optional] 
  • Any other skill one might help with (creating music or ambiance for the game, helping with code development, helping with putting together design documents, etc)
  • Achievements design and/or implementation while talking into consideration the existing mission designs of VB

Sunday, 26 February 2012

Temporary break

I honestly knew this post would come and rejected the thought but here it is...

Since now I have to focus more on the university and the thesis (not to mention job) I have taken a break from the project for the moment in order to tie some loose ends.

The good part is that I might be using this project in my thesis presentation so will probably have to get back to work on it in the following weeks.

Bottom line: I do not know when i will post a new update (maybe a few weeks from now or maybe next week...). Plese use the RSS feeds if you want to keep up with the project updates and I wanted to remind everyone that before I started the devblog the project was already an year old. As long as distractions are out I plan on sticking to it.

Also as a reminder, the source and content is available for download.

Saturday, 7 January 2012

Evolution of the code #11

Early weekend update. Achievements partially implemented.
Ive never been a fan of achievements in games - especially the ones that require much grinding but I do like it when they add a fun factor to them (such as performing an evilness and getting an achievement). Regardless I always wanted to implement something like this as the actual achievement system is what I find interesting. Some time ago i made a lua script which required a key card to turn on a light. I decided it was the perfect test site for an achievement. So, without further ado, pic below:

When i said partially implemented I meant that the lua scripts can be used to trigger predefined achievements but the game does not store them. The achievements are stored into a file in the definitions folder and they are defined as such:
title = achievement title
image = picture path

and used like this to trigger from a lua script:
There are a few things to look after though - since all windows get cleared when loading maps the achievements should only be triggered when a map is fully loaded and ingame.

Map transitions
Ive modified the change map region entity so it can now be used as an exit grid (if a map name is not specified in the map editor) which triggers the world map (although it is not functional yet) or a map transitioning zone to travel across zones within an area. The mapper can also be used to specify which spawn point should be used but it is not mandatory (a default spawn point shall be used in that case).

Next on the list should be fixing the combat manager, implementing more features from special and the world map window.

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.