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.