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.