Group script

Assigning something to happen when an enemy or character dies is quite common in video games. Sometimes you may want to update a journal or mission, start a conversation, provide a reward, or any number of things. I've discovered there are a number of different ways to do this.

The most common one that is used is the OnDeath script. This is a script placed in the OnDeath tag of a single object. This fires when that object dies. It works well if you only have one enemy that is going to provide an update. If you have a number of combatants and assign the OnDeath to a single one and wish to start a conversation, it can be quite clumsy. Everquest 2 and World of Warcraft use this type of update more than any others.

A Body Count variable is a better way of doing an update with multiple objects. You would assign an OnDeath script that would fire a modifier to a variable of “iBodycount”, for example. If you had five combatants, you would assign an OnDeath on all of them that would add “1” to the “iBodycount” variable on that object's death. The object that is going to give the update would have an OnHeartbeat script that looks for the “iBodycount” variable to be at least “5”. Since the OnHeartbeat scripts fire every 6 seconds, there is going to be a delay of six seconds, at the most.

I discovered another way that I much prefer for multiple objects. It is called the Grouping script.

Here is the sample Grouping script that I tested:

#include “ginc_group”

void main()

{

AddNearestwithTagToGroup(“turds”, “turd”);
GroupOnDeathBeginConversation(“turds”, “jones”, “speak1”);
}

I took two zombie templates and placed them in a zone. I gave both of them the Tag “turd”. I then placed an umber hulk template down and gave him the Tag “jones”. I made a single conversation script and called it “speak1”.

This script fires when the player crosses a trigger on the ground. When it fires, it takes all the objects with the Tag of “turd” and places them in a group called “turds”. When all the objects in the group have been killed, “jones” starts up the conversation “speak1”.

Its pretty simple to use, but you have take note of all the groups you will be using in the module so you don't reuse them. Of course, you need to be sure that the object starting the conversation is set to Static FALSE, otherwise they won't do a goddamn thing, no matter how well you script.

Couple of Useful Scripts

I've been going through some scripts from the OC in an attempt to iron-out some from faults in some of my own scripts that have not been functioning as I had hoped.

It seems that when I "ChangeToStandardFaction(STANDARD_FACTION_HOSTILE)", the mobs fail to directly attack unless they are attacked first. Going through some OC scripts, I discovered that their is no direction solution to this, other than to create a valiable that determines the player's ability to survive the attack.

Rather than trying to script OnDeath scripts for all the opponents followed by the local variable that will determine what happens when the battle is one, the OC script adds the opponents into a single group that only requires a single OnDeath script. I'm gonna play with this tomorrow and see if I can get some of these to fire properly.

Ambient Life

The project continues as always with quick pieces and slow pieces. Recently, I have been working on some slow pieces. I have decided to move on ahead a little ways with a module that I knew was going to take a long time. While the player is not set to travel here, yet, this is the direction in which they are heading.

This is another cultivated precinct. It's far more advanced and populated than the small village I started out with. Given this, I have been deeply involved in creating realistic ambient life. This seems to be my weak-point, but I'm learning quickly with it.

I would like to give credit to Jeff Husges, a designer at Obsidian, for a counsel on a commonsensical way to create a "slumbering" npc.

Bug Fixed

Well, tonight I fixed a bug that was causing the game to crash when a certain conversation was started. It was a simple fix, but it took a while I figure out what was actually causing the error. I had set the conversation to use different dialogue depending on how far along the game was. I had placed one variable, but forgot to place the second one. That would be like someone telling you, "If the door is open, clap your hands. If the door is closed." I actually discovered the bug on accident. I don't know when I would have noticed if I hadn't stumbled upon it.

Rough Night

Rough night. I have definately earned myself a beer. Very early on in the developement, I worked out an answer to a question that I had about how to get companion non-player characters to join the player. I was unsure of how to do this, because I knew that this newer engine did not use the same system as the previous one. I figured out how I was gonna do it for a single-classed character, but put off working out a system for a multi-classed character.

I decided that while I was writing the script for the latest non-player companion and had some time to fully play-test this, I was gonna work out a multi-class system. More or less, I just wanted to see if it was possible. If it was not possible, I had a “work-around” in mind that should have taken care of it from a game play stand point.

So if the player is 2^nd level and a non-player joins the group, the non-player will automatically level up to level 2. That wasn't a problem with a single-classed character. The problem, however, lied in the multi-classed. I set up a non-player to be a rogue/cleric, both 1^st level. When the non-player joined the 2^ndnd class rogue. The secondary class was completely ignored. level player, they leveled to a 2

That would pose a problem when the player joins up with a monk/blackguard/warlock later on in the game. This non-player is part of the storyline, so having all three classes is of major importance.

After playing around with a number of different options, I found the final solution to be really simple. The reason the non-player was switching to a single was because of their “Starting Package”. This is basically a blueprint of how future leveling will occur. If I simply remove the starting package, the code that planned future leveling does not fire and the initial level in classes remains untouched. The non-player is then leveled in the standard fashion.

The most amazing part about this is that the engine does not crash when it fails to find a script that it expects. That was worrying me and was the main reason I did not think of trying this earlier.

I'm so lucky

I am so glad I started backing up my work at least every 30 minutes. I was trying to load a module for a play-test and the engine crashed. My 171mb data file went to 43mb. Thats a lot of missing data. Luckily, I was able to load a previous back-up and carry on.

Weather Effects

For whatever reason, weather effects are not the easiest thing in the world to input. On the previous engine I worked with, there was a setting for “Weather Effects.” You would change Rain FALSE to Rain TRUE. Simple enough. This engine doesn't make it easy. I was able to write a script for WEATHER_TYPE_RAIN OnEnter. It makes sense, because I could create a similar script to start rain, snow, or lightning when the player reaches a certain point. It boggled me at first, but I think I can get used to that method of weather effects.

Wooden Area Complete

I completed the exterior forest area in just over four hours. I will add the sound effects and encounters tomorrow. A battle will take place in this heavily wooded area. I am sure that it will be chaotic in the darkness and rain.

New Area, New Zone

Another day of development has passed on by. I started constructing a new area that will signify one of the last missions for this zone. I created the blueprint for a semi-playable non-player character. I won't give too much detail, but this character will follow the storyline into the next area and appear later on in the game. The current area will include an exterior grid involving a “game of cat and mouse” in the darkness and rain, followed by a lengthly multi-level interior. This interior will include the newest non-player and an uncommon boss. This boss will also reveal a little more of the storyline and deepen the plot. I have been taking it slow this week. I've been putting in an average of 35 hours a week so far, so I have spent a portion of my time just sitting here in my chair this week.

No Spawning, Only Jumping

I had a good couple of days with game design. I discovered something that doesn't seem to work the way it did in the old engine and I can't figure out why.

In the old engine, I wrote a simple script to spawn non-player mobs without difficulty. For some odd reason, this new engine recognizes the script, but fails to fire it. I was able to come at it from a different angle. By placing the defined mob in another location, I was able to get a script to “jump” them to set waypoint. In this case, I just made a room inaccessable to place all the area spawning mobs. As long as their AI is disabled until I fire the “jump” they ignore each other, even if they would normally be hostile to one another. I don't see this causing any future problems, yet I am curious why my older script fails. I remember that id Software's “Doom” did something similar with their spawning mobs.

I also need a better system of setting up proper camera angles. Right now, I have to “eyeball” them then check them out through a play-test. It's not the fastest system in the world. Perhaps I could give them a set facing towards a waypoint or a small floor mounted trigger.

I bought a new notepad, because I was tired of using sticky notes to document my local integers. I originally thought it was good idea to use sticky notes, until one floats away and I have to backtrack to remember what I set.

The story unfolds...

The first actual scene takes place where more of the player's past is revealed. Although a little bit is unfolded in the start of the game, this encounter actually uncovers the tie between the player and the storyline. In addition, something of the past of the player's first companion is also revealed. If the player had played the OC, they will not learn anything new. In the game setting, this will be the first time the actual character will learn something of this companion. The conversation ends in a battle, which during the play-test, I found to be a little too difficult. As I have done before, I will back down the attacker a notch. It's still too early to be killing the player.

Swamp complete. Ruins in process.

The swamp area has been done for a couple days now and I have been working on the interior of the ruins. The swamp looks good and it's complete with lighting and sound effects. The interior ruins has proven to be a little more challenging to my creative side. The player isn't gonna be powerful enough yet to survive a larger interior area, but I wanted to make this place seem large. Without adding meaningless twists and turns, I'm enclosing the walkable area with rubble and debris. It should give it a large appearance while still keeping the layout streamlined.

Depressing play-test and additional scripting

I had a depressing play-test the other night. I started from the very beginning of the game and starting working my way through. While doing this, I discovered several bugs I hadn't seen before. The most unnerving bug I found was that several of the animations assigned to various non-player characters were not running properly. The strange this is how fickle they were. Sometimes they ran; other times they did not. There seems to be no pattern to why or when they fail to run. I suppose I will have to check, re-check, then check it all over again.

On the bright side, I successfully implemented the first "mission". It is simple enough, but seems to run just fine. I have a second mission planned. This one will be much longer and more detailed. I had to consult with my technical director on a storyline aspect before I wanted to dig too deep into this second mission.

Normally, mission updates can be done through a single journal script. I tried using this when I was building the first mission, but found that it lacked the depth I needed to create some truly unique scripting. I decided to add a secondary floating variable to accompany all missions with the same tag-line. It will involve me adding additional scripting, but I think...correction...I KNOW it will benefit me in the end. It also means that I will need to be careful with mission scripting, as I will be relying on two scripts to fire properly rather than just a solitary one.

How much work did I just make for myself?

Good granny. I just completed the conversation and variable scripts for the "Artifact Recovery" mission. I am pretty damn certain that I made that overly complicated. I worked it out so if the player speaks to the same NPC at different stages of the mission, he will give a different response. That is how I wanted it, but I'm now worried on how long this is gonna take to test all this. It really sucks to not have a play testing team like the "big boys" have. I guess I have all week to test the eight pages of code that I wrote for this single task.

While everyone else in the country was out celebrating the New Years, I was writing code. How many other people would do that?