Ramblings

You are currently browsing the archive for the Ramblings category.

World of Warcraft

July 8, 2008 in Ramblings | 2 comments

Last semester I was unceremoniously captured and tormented by the game we all know as World of Warcraft. During my adventures as a mage in this game I progressed as far as the first boss in black temple before wow-quiting. As I am sure many fellow gamers can understand, one day the game finally clicked for me and I did not sign on it for weeks, only to be destroyed when I reformatted last week.

But enough about that, I learned quite a few things from this game, and I would like to share some of the more practical lessons. I have compiled a mage ‘guide’ that I believe might just be the most comprehensive on the internet, concerning addons, macros, and gear tips anyway. You will still have to read elitistjerks to learn how to play your class.

I was the mage officer for my guild and so I had a big thread that detailed what I expected each mage to do, and various tips and tricks I had picked up. So without further delay, here is quite possibly the longest post I will ever make in one sitting.

Raiding

In order to raid you must first have the appropriate gear and stats. As a general rule of thumb, mages should have around 8k hp unbuffed. Usually that number is 8.5k, however mages do have a lot of survivability so I lowered it a bit. If you want to raid please get the appropriate gear either through badge loot or a few lucky heroic/kara/gruul runs. When picking who I will take to a raid you can follow this list.

  • Have the time
  • Know your class
  • Know the fight
  • Have the gear

I consider all these when choosing who to bring to a raid, please be aware of how you score and how you can improve.

Mage Sweet Information Thread
http://elitistjerks.com/f31/t18441-mage_sweet_informational_thread/

Consumables

Flasks
[Flask of Pure Death] +43 dps
[Flask of Blinding Light] +43 dps
[Flask of Supreme Power] +38 dps
[Flask of Distilled Wisdom] Acceptable for arcane mage use, 1125 mana, 1% to crit
[Shattrath Flask of Supreme Power] +38 dps

[Unstable Flask of the Sorcerer] Only for gruuls

Elixers
[Adept's Elixir] BATTLE ~+20 dps
[Elixir of Major Firepower] BATTLE +30 dps
[Elixir of Major Frost Power] BATTLE +30 dps
[Greater Arcane Elixir] BATTLE straight up damage, no crit

[Elixir of Draenic Wisdom] GUARDIAN
[Elixir of Major Mageblood] GUARDIAN +16 mp5
[Elixir of Major Fortitude] GUARDIAN If you need a little extra hp

Oils
[Superior Wizard Oil] Cheapest and easiest
[Superior Mana Oil] If you need the mp5
[Brilliant Wizard Oil] Damage and crit

Food
[Blackened Basilisk]
[Crunchy Serpent]
[Poached Bluefish]
[Skullfish Soup]

Potions
[Super Rejuvenation Potion]
[Major Dreamless Sleep Potion]

[Destruction Potion]
[Flame Cap]

Spec

Mages have 3 possible specs

2/48/11
http://www.wowhead.com/?talent=obZxgRzfcIoeRtVhM0o
40/0/21
http://www.wowhead.com/?talent=oi0ic0czxIziZZVA0coc0o
10/0/51
http://www.wowhead.com/?talent=obhVZZVAGcofLoiqt

Macros
There are a lot of things that help a mage get max dps and macros are one the top ones. Here are some handy macros I use, consider integrating them into your ui if you have not already.

Firstly, the most important,

/cast [COOLDOWN]
/stopcasting

Make a macro for all cooldowns you pop, including trinkets and gems. You might notice that when you use a cooldown you get global cooldown. This is not suppose to happen and can severely cut your dps. When you use stopcasting it will cancel the global cooldown. For example, as 40/0/21 I keep this macro

/cast Icy Veins
/stopcasting
/cast Cold Snap
/stopcasting

This pops both cooldowns at the same time and I can immediately follow up with a spell and save myself 3 seconds of global cooldown.

Second most important, focus targeting

Every mage should use these macros for cc. The command is simple, its just /focus
That will set a target as your focus. For those unfamiliar with focus targeting, think of the focus as a second target. You have your main target (the skull) and your cc target (star) both targeted at the same time. In this way you can easily see the timer on your sheep AND you can easily resheep without changing targets. Obviously this is a big deal, so use it. Here are the macros

/focus mouseover

then

/cast [target=focus] Polymorph

I bind the mouseover focus to mouse 3, or the middle button. When I click that on a mob I set my focus target. When it comes to cc I have polymorph target set to F and polymorph focus set to ctrl+F. I highly recommend the use of the modifier key, that way you can have one ‘sheep’ button, but it can do 2 different things.
If you have any questions about this please talk to me in game.

This handy little macro will delete any Mana Emeralds you have in your inventory and conjure a new one. Good if you want to replace the one that only has 1 or 2 charges left.

/run for x=0,4 do for y=1,GetContainerNumSlots(x) do l=GetContainerItemLink(x,y) if l then if GetItemInfo(l)==”Mana Emerald” then PickupContainerItem(x,y) DeleteCursorItem() return end end end end
/cast Conjure Mana Emerald

Addons

http://files.wowace.com/scorchio/scorchio.zip
Lets you know how long the scorch debuff has left, regardless of who owns the stack

Aloft
- Better overhead enemy health bars. There is also an option to include a sheep timer and cast bar

Banzai Alert
- This addon will tell you the second you pull agro or are targeted by an unfriendly mob/player

BigBrother
- This addon will tell you who breaks your sheeps, and has an optional announcement feature for parties and raids

Bongos
- Very customizable action bars, and easy to use key bind system.

Distance2
- Addon that scans your talents and displays an approximation of how far you are away from a mob

DrDamage
- Calculates your expected and effective dps given your talents, gear, etc. Displays damage for spells on your action bars, and much more

ElkBuffBars
- Very nice and clean buff bars

ErrorMonster
- If you are tired of all the ‘You Cannot Use That Item’ blah blah error messages, use this addon to filter them out.

FreeRefills
- Auto buy stacks of reagents

Grid + Click2Cast
- I use grid for my raid frames and love it. You can also combine grid with an addon called Click2Cast and effectively make decursive, removing an extra addon you dont really need. You will need some prowess in order to set it up but it is worth the trouble.

ag_UnitFrames + MobHealth
- ag_unitframes will replace blizzard’s default ui with a much cleaner and nicer ui. I combine it with mobhealth so that I can get really good approximations at how much health the boss really has.

OmniCC
- Will place a countdown on your action bar for your cooldowns.

SCT + SCTD
- Scrolling combat text and more importantly, scrolling combat damage. Can be easily configured to show you when you are taking damage and such.

Talented
- Allows you to store templates for other specs and even will respec for you. Combine this addon with Talented_DrDamage, and DrDamage will tell you expected dps with whichever spec you have open in talented

WitchHunt
- Will display a message when an enemy within range casts something, anything.

You might notice that a lot of these addons are ACE addons. I did this on purpose for if you download the ACE Updater you can easily update the majority of your addons in 1 click. Its just my preference though. Happy tweaking.

Gear (Mainly badges)

[Scryer's Blade of Focus] : 150 Badges

[Chronicle of Dark Secrets] : Rage Winterchill

[Wand of the Forgotten Star] : High Astromancer Solarian

[Cowl of Tirisfal] : Lady Vashj
- [Chaotic Skyfire Diamond]
- [Runed Crimson Spinel]

[Adornment of Stolen Souls] : Prince Malchezaar
[Loop of Cursed Bones] : Zul’jin

[Mantle of Tirisfal] : Void Reaver
- [Potent Noble Topaz]
- [Infused Amethyst]

[Brute Cloak of the Ogre-Magi] : Maulgar

[Tormented Demonsoul Robes] : 100 Badges
- [Brilliant Dawnstone]

[Cuffs of Devastation] : Rage Winterchill
- [Runed Living Ruby]

[Enslaved Doomguard Soulgrips] : 75 Badges
- [Brilliant Dawnstone]

[Belt of Blasting] : Crafted
- [Glowing Nightseye]
- [Veiled Noble Topaz]

[Corrupted Soulcloth Pantaloons] : 100 Badges
- [Runed Living Ruby]
- [Runed Living Ruby]

[Boots of Incantations] : 75 Badges
- [Potent Noble Topaz]

[Band of the Eternal Sage] : Exalted: The Scale of the Sands

[Fused Nethergon Band] : 60 Badges

[Hex Shrunken Head] : Hex Lord Malacrass

[Serpent-Coil Braid] : Morogrim TideWalker
[Sextant of Unstable Currents] : Fathom Lord Karathress

When all is said and done, according to thise nice dps calculator you should end up with about 1920.64 dps fully buffed.
Obviously this gear is geared more towards an arcane mage, so get to know and love the arcane mage rotation. I suggest occasionally spec’ing 40/0/21 and doing 5 mans to get the hang of it.

Stats in this gear (unbuffed)
7933 hp / 10691 mana
30% crit / 10% hit (3% off cap [buffs increase this])
1249 Spell Damage

Stats (buffed)
8603 hp / 13226 mana
40.51% crit / 13% hit
1481 Spell Damage

Buffed stats assume a shaman and moonkin in the group

Total Badge Count: 560

Gear (PVE [aka lazy])

[The Maelstrom's Fury] : High Warlord Naj’entus

[Chronicle of Dark Secrets] : Rage Winterchill

[Wand of the Forgotten Star] : High Astromancer Solarian

[Cowl of Tirisfal] : Lady Vashj
- [Chaotic Skyfire Diamond]
- [Runed Crimson Spinel]

[Adornment of Stolen Souls] : Prince Malchezaar
[Loop of Cursed Bones] : Zul’jin

[Mantle of Tirisfal] : Void Reaver
- [Potent Noble Topaz]
- [Infused Amethyst]

[Brute Cloak of the Ogre-Magi] : Maulgar

[Tormented Demonsoul Robes] : 100 Badges
- [Brilliant Dawnstone]

[Cuffs of Devastation] : Rage Winterchill
- [Runed Living Ruby]

[Enslaved Doomguard Soulgrips] : 75 Badges
- [Brilliant Dawnstone]

[Belt of Blasting] : Crafted
- [Glowing Nightseye]
- [Veiled Noble Topaz]

[Leggings of Channeled Elements] : Kaz’rogal
- [Runed Living Ruby]
- [Runed Living Ruby]
- [Runed Living Ruby]

[Slippers of the Seacaller] : High Warlock Naj’entus
- [Runed Living Ruby]
- [Runed Living Ruby]

[Band of the Eternal Sage] : Exalted: The Scale of the Sands

[Ring of Captured Storms] : High Warlord Naj’entus

[Hex Shrunken Head] : Hex Lord Malacrass

[Serpent-Coil Braid] : Morogrim TideWalker
[Sextant of Unstable Currents] : Fathom Lord Karathress

When all is said and done, according to thise nice dps calculator you should end up with about 1810.60 dps fully buffed.
Obviously this gear is geared more towards an arcane mage, so get to know and love the arcane mage rotation. I suggest occasionally spec’ing 40/0/21 and doing 5 mans to get the hang of it.

Stats in this gear (unbuffed)
7173 hp / 9791 mana
32.5% crit / 11% hit
1289 Spell Damage

Stats (buffed)
7763 hp / 12251 mana
43.69% crit / 14% hit
1566 Spell Damage

Buffed stats assume a shaman and moonkin in the group

Total Badge Count: 175

Tools and Resources

There are quite a lot of tools and such mages can use to figure out how they can be better. Here are some of the programs and web sites I use to keep tabs on everyone.

Rawr
http://www.codeplex.com/Rawr/Release/ProjectReleases.aspx?ReleaseId=12354
Gear comparison, dps calculator, spec inspection, this is by far the BEST mage program

Loot Rank
http://www.lootrank.com/wow/rank.asp
Does almost the same thing as Rawr but provides a bit more info and easier to use in a certain respect. The thing with loot rank is you have to assign numbers to stats for it to choose the best gear for you. These numbers can be tweaked a bit depending on how you feel, but here are some example builds.

High priority on stam and haste, not the best for all of us atm.

This weighting is more suited for our mages at the current moment. Check it out.

I might make some tweaks based on layout here or there but this guide is not going to change much so consider it current to today’s post date.

Tags: , , , , , ,

Data Driven Apps!

March 17, 2008 in Programming, Ramblings | Permalink

Ok ok, I am writing again! If you read my previous posts on dynamic npc actions then this is an update on my progress. If you have not, this is about how to create good file formats for your applications.

As some might have expected this project is taking more time then expected, partially because I am currently downing bosses in WoW, and partially because its very hard. So lets just cover what has been going on since my last post.

I spent a lot of time thinking of the best structure for my idea in terms of objects and file formats. I do not know if I covered this before because I am to lazy to view my past posts so heres a recap of the basic composition of what I have been calling a ‘Puppet.’ A puppet is a game object with x number of movable joints. These joints are built in a tree structure and move based on messages passed to his parent. These messages are generated from a actor class who learns actions and movements as I previously discussed. When I was designing the puppet class I hit a big fat road block. I wanted the ability for a puppet to be independent of his underlying joint structure. That way I could have a puppet control everything from a human to grass. So you might think, ‘No problem, do some tricky interface work and have derived classes for each type of puppet.’ WRONG!

See I myself have read many articles about component game object design, and I do believe I wrote an article on this in the past. However do not get the wrong idea, what I did is not EXACTLY component objects, but kind of close. Because when I thought about components I also thought how to best describe them in a file format. And after thinking about that I decided that I wanted a global file format to describe not only each type of puppet but the entire world. And that the entire game will be built out of components in a tree structure built at load time from this file format. I am getting a bit ahead of myself here so lets get some examples here.

<world>
<name type=string>Main</name>
<description type=string>
Big world for which to run tests in
</description>
<floor type=plane>
<p1 type=vector>-1000 -1000 -1000</p1>
<p2 type=vector>1000 1000 1000</p2>
<material>dirt01.mat</material>
</floor>
<joint>
<position type=vector>0 0 0</position>
<orientation type=vector>0 0 0</orientation>
<puppet>arm.puppet</puppet>
</joint>
</world>

This is my toy world I am working in. The file format is xml and I use tinyXML to load and parse these files. For those familiar with ogre, I made a resource of type XMLFile to load these. Now here comes the clincher, this XMLFile resource will load every type of game object I desire, regardless of type or purpose. Not only that, but I only added 2 methods to the class.

So let me explain a bit about these methods, they are named ‘build’ and they are called usually immediately after loading the file. Basically what they do is look at an element in the xml, find a builder for it, have the builder build it, and attach the new object to the world tree. In this example, the world has no parent and all elements inside the world tags are children of the world. I use the type descriptors so that I would not have to write many classes that do the exact same thing. Elements that load another file, like the puppet tags, will load that file in their own world and all objects created from that are children of the puppet. After the build the main program is not aware of any object other then the world. Messages are passed to the world when need be, however most thought processing is done in the world object, not by the game engine.

Lets get an example puppet up here:

<puppet>
<name type=string>arm</name>
<description type=string>
Generic arm
</description>
<joint>
<name type=string>shoulder</name>
<gib>upperarm.gib</gib>
<joint>
<name type=string>elbow</name>
<gib>forearm.gib</gib>
<joint>
<name type=string>wrist</name>
<gib>hand.gib</gib>
<joint>
<name type=string>pinky</name>
<gib>pinky.gib</gib>
</joint>
<joint>
<name type=string>ring</name>
<gib>ring.gib</gib>
</joint>
<joint>
<name type=string>middle</name>
<gib>middle.gib</gib>
</joint>
<joint>
<name type=string>index</name>
<gib>index.gib</gib>
</joint>
<joint>
<name type=string>thumb</name>
<gib>thumb.gib</gib>
</joint>
</joint>
</joint>
</joint>
</puppet>

As you can see this file format is very flexible, the same structure that built the world can build a puppet and also a gib:

<gib>
<name type=string>forearm</name>
<notes type=string>
Fore arm gib
</notes>
<mesh>forearm.mesh</mesh>
<input>
<name type=string>shoulder</name>
<position type=vector>0 0 0</position>
</input>
<output>
<name type=string>elbow</name>
<position type=vector>7 0 0</position>
</output>
</gib>

I want to clarify one thing before I go on. Elements called position or orientation, these attributes are not given any attention by the builders. Instead those objects simply exist on the tree for someone else to read them and make the correct adjustments. For example, the puppet’s name element simply sits as an element on the tree until a debugger opens and the entire tree structure is displayed. At that time the debugger will go through each element and find name tags that it will use to give more information on the node. And the description works the same way.

They are both created by the string builder, as denoted by the ‘type=string’ attribute I give them. The value is assigned and the name of the new object is set, but the type is always a string.

So what exactly is required to declare a new type of object? Just a builder and an actual object. Take this example of the string object.

class ScktString : public ISocketable
{
friend class StringBuilder;
public:
void setValue( std::string val ) { _string = val; }
std::string getString() { return _string; }
private:
ScktString( std::string propName ) : ISocketable( propName ) {}

std::string _string;
};

class StringBuilder : public IBuilder
{
public:
StringBuilder() : IBuilder() {}
Socket* build( std::string element, Socket* parent );
const std::string& getType() const;
static std::string BUILDER_TYPE_NAME;
private:
static const StringBuilder registerThis;
};

As you can see its relatively easy to create a new object. Lets start at the builder, when the xmlfile is building it will search for a builder based on its type name, which is assigned by you. A builder list is created at the start of the program, as each builder has a static ‘registerThis’ variable that adds it to the builder list. Those familar with static factories should be familiar with this. The builder’s build method gets called with the name of the element and its parent’s socket. A socket is an object that accepts links from children. The builder then builds the object passing its name. The sockable base class is for objects that can be socketed or linked with a parent.

So the string object is created and the string builder passes back the parent object. This is done in case the new object has a socket himself. In that case he would pass back his socket and the builder would build his children and attach them to him. In string’s case however, there is no socket and a little while later the builder assigns the string object a value by calling the setValue method in the parent object with the objects name and value as parameters.

After all the work we are left with one tree that contains all objects in the game. Kind of like a scene manager, but for ALL objects, not just renderable ones. And oh, don’t forget that the entire tree was created by one instance of XMLFile. As programmers we should always strive to achieve the cleanest and most powerful format we can muster. This format is not only really easy to implement, but also holds unlimited power. You want to load a texture? Create a texture socketable object, and implement file specific loading inside it. You want to script AI? Either create an AI socketable object that reads children objects that decribe a strategy, or create a python socketable object that will load your ai scripts and parse them. In this way our file format can act a proxy for another format or as the direct format. The most important thing however is that none of our in game objects need to give file formats a single thought.

Tags: , , , ,

Team Fortress 2 Critical Hits

December 8, 2007 in Experiments, Ramblings | 8 comments

A little while ago, Valve had been quoted as saying that critical hits in Team Fortress 2 are skill dependent. That the chance to get a critical hit increases the better you do. A couple of weeks ago I made up an experiment to test these statements out in game.

First off, I should explain that I wrote a plugin for Team Fortress 2 called TFTrue. This plugin maintains critical chance and damage for server owners wishing to change the default settings. To make the plugin I had to study the take damage function in the game to figure out where the percentages were coming from ( which if you are curious, default you have a 5% chance to crit with weapons and 15% chance to crit with melee ). I thought this statement was weird because after all my searching I never came up with any ‘skill’ variable that increased or decreased the crit chance. I setup my test to work out all the unknown variables in the game code and find out whether or not score has an impact on your crit chance. I will summarize my data here, if you want to refer to the hard data, see the end of this article.

I setup a private server with TFTrue installed and crit chance set to 50%. I made a test map with 1 spawn point and set the respawn time to 0. This made my bots all spawn in the same place with little death delay. I expended 80 rounds of rocket ammo at a wall and observed my critical count. For my control test I ended up with exactly 50% critical chance, so far so good. Next I stepped it up, introducing 7 bots on the opposing team to test the idea that being out numbered helps. After firing all 80 rounds, my crit chance still remained 50%.

Next test involved killing the bots enough to achieve the ‘domination’ status with all of them. With my high score and high skill (according to the game), I fired 80 more rounds at the wall. Still 50% crit chance. What does this mean? It means being consistently better than the other players will not increase your crit chance.

The final test I did was tacked on as a side note when I noticed something interesting while killing the bots. It appeared that I was getting all crits when constantly killing the bots as they spawned right in front of me. So on a hunch I started firing constantly into the crowd of bots and low and behold, 100% crits for all 80 rounds. Upon further investigation I found that after killing 2 players in quick succession increased your crit chance about 4 times. Meaning default crit chance would become 20%. This effect lasted a variable amount of time depending on the weapon type. I timed the demoman’s sticky grenades to last for a bout 20 seconds, however the rockets only lasted about 5. To figure out what specifically influences this behavior we must look back at our code.

Before the Nov. 7th patch, Valve had kept private critical chance variables in the game. Namely, tf_crit_chance, tf_rapid_crit_chance, tf_melee_crit_chance. The first and last variable are pretty much self explanatory, however, what is rapid crit chance I wondered. Back then I decided that it was the chance to crit while firing rapidly. However after reviewing my test results I now believe that maybe this rapid chance is what determines critical chance when killing players rapidly. This is all theory and I have not tested it, but I do think that while playing if you kill a player the game rolls a number to compare to the rapid chance and turns crits on for you if you are lucky. After the Nov. 7 patch the TFTrue plugin treats both those numbers the same, they are both controlled by tftrue_crit_chance. And after further reviewing the code it supports this idea. So if we do work with this theory lets walk through a typical game.

Player Spawns
Player Shoots gun at wall (5% chance to crit)
Player runs to enemy territory
Player kills enemy player (5% chance to start “crit chain,” if the player if lucky he will now shoot crits for X seconds)
Player kills another enemy (5% chance to start “crit chain,” regardless if they are in one or not)
Player shoots (5% crit chance, unless in crit chain, then its 20%)
Player Dies.

I think if you are a hard core tf2 player you can easily identify with this result, just remember that this senerio is purely hypothetical. I have not done any tests modifying rapid crit chance. Like I said earlier however, the code supports this situation.

Now we must turn back to our original hypothesis. Does the critical hit chance get bigger the better you do? In one word, no. However I think we can easily see how Valve would mix up this system with a skill reward. In this system you can be a complete noob and get 1 kill to put you in a crit chain. Your skill as a player has no bearing on the crit chance. How you get more crits in tf2 is to kill more people. The more people you kill, the more shots you have at hitting that 5% chance on the nose.

Test Data:

Test 1: 15 / 40 crits | 24 / 40 crits
Test 2: 18 / 40 crits | 20 / 40 crits
Test 3: 22 / 40 crits | 18 / 40 crits
Test4: 39 / 40 crits | 40 / 40 crits

Tags: ,

Article Backup

December 7, 2007 in Ramblings | Permalink

I have quite a few articles regarding my game design sitting in the draft section incomplete. A number of issues have cropped up during development that I would like to write about but have been unable. I would like to save the ‘implementation’ post for when I have this thing working. Recently I have been working on a more concrete project called TFTrue. It is a plugin for Team Fortress 2 that gives server owners control to change critical chance, respawn times, damages, ect.

I wrote up a couple articles regarding how crits work and various technical aspects of TFTrue that developers of other plugins might be interested in. These articles will tie in nicely with my COF Plugin series so I will be posting those soon as well.

Tags: ,

Compiler

September 15, 2007 in Game Design, Programming, Ramblings | Permalink

So heres the deal, every game needs some sort of script compiler. Regardless of how its designed, there will always be a time when the ability to edit the game without recompiling is key. But thats not the only reason, scripts allow us extra layers of abstraction so we can do complex things such as ‘pickup( itemid )’ with ease. But I am getting distracted.

I have been working on this component AI idea and have come to the point where I need to start defining actor actions through scripts. How I have it setup now is the npcActor’s state will slowly degrade over time (think the sims) and when it reaches a threshold they go and search for an object that can alleviate their problems. Its a pretty simple design for a simple test. As mentioned in previous posts, I want these npc’s to learn from interacting with the environment. This combined with the mbti structure and other things should produce reasonably agile AI (see previous posts for specifics).

I thought of making this post to stress a key factor in my decision making process as it pertains to this project. And that is abstraction. The abstract is key to this project. In an ideal world, nothing here should be hard coded, unfortunately that is a little hard to do, especially right from the get go. So what I decided to do was to brute force my way to a reasonable demo app and work backwards from there. Removing static code as needed to perfect the design. For instance, I have pretty much decided on a syntax for my scripting language, but I have left much of the interpretation to genetic algorithms in the compiler. Here is a sample script


using actions
using health

_actions::sit $this
$sitting = true
callback -actions::stand _stoodup
{ $health::comfort +1 / 5 } while $sitting

_stoodup:
$sitting = false
::
I am not going to explain the syntax because to any programmer the intentions should be clear. The problem I have been facing is how to keep the intentions abstract enough to allow multiple interpretations. I want Bob’s sitting to look different from Kim’s. I have currently setup a system where the compiler creates these jobs for each script and at the appropriate times sends messages to actors to handle actions. It is then completely up to the actor as to how to handle the action. For instance, when the compiler runs over ‘_actions::sit $this’ it will send a message to the host actor to sit on the target object. In this case the message will not be as simple as

msg.id = ACTION_SIT;
msg.target = 0x01234567h;
msg.brainless = 1;

Instead the message will contain a number of input to be inserted into a designate neural network, which would have been trained earlier to sit when given those inputs (exactly how they sit is up to the GA).

So then how to handle direct variable access like the ‘$health::comfort +1/5′ line above. Well some messages will have to be specially constructed to be brainless. I figure I will have a range of message id’s designated for variable access, neural network input, etc. So a msgID of 1 would be to set a variable, and 2 would send the incoming data into the NN.

This is not the final system, just what I am currently using for testing. However this is the current framework for future applications. The goal of this first program is to weed out any bugs and get a clear understanding of how I want this thing to run.

You can notice how this solution offers a direct line to the actor’s state of mind without hard coding everything, which is exactly what we want.

Tags: , , ,

Short Post

July 28, 2007 in Ramblings | Permalink

I am going to sum up the past month or so of inactivity here. I have been working on a concept design of my component ai idea. Once I finish it to my liking I will post it here. I have not had much time to work on it with my job and home projects so it will be a little while longer. Just wanted to say that I will still be posting stuff here.

Also, I am going to write more about the cof plugin soon, most likely I will pick it back up after I finish the tech demo. I was writing it as a reference for when team fortress 2 comes out, I can already tell through the various promo videos I have seen that the cone of fire is going to be as broken as dods. I should have the whole series done before Valve finishes hacking together 2 years of what they call work.

Tags: ,

Designing Component AI

June 21, 2007 in Game Design, Ramblings | Permalink

In a continuation of my last article, I would like to record the process I have been taking to creating and designing the component AI I described in my last post. Component AI is my term for this idea right now, I really have no idea if it has been done before so for right now its what I call it. Now, for those of you who might be familiar with component based object systems (Game Programming Gems 5), this concept will not be to hard to understand.

Basically, we want the npcs to operate off of components they learn about through their training. I know I did not mention training in my last post, but it is necessary for the npcs to not look like mindless zombies through half the game. Each npc will have to be fed through a virtual school where they will learn, through various tests and challenges, how to operate in their world. But I am getting distracted here, back to the design.

Component based objects can be summed up as imaginary containers that are filled with components that operate the object. For example, one component might be a renderer, another holds a model, and one more holds animations. These three together form a solid object that will be displayed in game. They are attached to each other solely through the object manager, but nonetheless are able to effectively communicate with each other through interfaces and a messaging system. I wish I had GPG5 around me so I could yank their example, but I think you get the general idea.

Anyway, objects communicate with themselves through messages, and each of the components that make up an object can subscribe themselves to different messages. A render component would subscribe itself to a ‘draw’ message, that way when the game sends a ‘draw’ broadcast, all objects that have the render component will draw themselves.

That is how component object systems work, when we introduce the ability to pick up new components during run time through actions, we have component AI. The npcs will be equiped with the simple components, model, render, animate, physics, ai, etc, and they will be able to pick up new components from the world to plug into their brain for future use. These types of components can subscribe themselves to messages, and even communicate with each other to achieve the best results. Some form of genetic training will have to be used to teach these components how to effectively communicate. When the npc comes across something new that it doe not know how to handle, picking up a chair for example, it will need to know things about weight, body position, what limbs to use, how to grip it, pretty much everything, and the only way he will know is if the components in his head know how to communicate effectively.

Yes I did mention body position and dynamic animation. I already mentioned the fact that objects themselves will hold data on how to handle them, generally. Then after the npc does that action he will gain a new component for handling that object. This system does not conform very well to static animations like most games keep. So animation will be dynamic and learned by the npc over time. This allows npcs to gain their own style of movement and actions.

Yes yes, I know I am going a bit over board again, running 8 or so npcs each tugging about 10,000 or so AI components will probably be a big load. That is why I need to write a demo application one of these days to see how much this will cost. For right now I am planning to go all out, screw the cpu, but most likely for slower computers we can introduce a system to merge and combine components to save processing time. However the more components you combine the more hard coded the npc becomes.

Tags: , , ,

Human AI

June 13, 2007 in Game Design, Ramblings | Permalink

I had a thought today while walking outside about human-like ai. This is of course, in relation to the game idea I posted a few days ago, but the gist of my goal is to have npc’s that can successfully animate and control characters designed from popular animes.

The idea is pretty simple, the npc’s will derive their actions off objects, not off of themselves. In other words, they will look at the object to determine how to handle it, not depend on preprogrammed responses to objects that are a chair. The objects will store data that the npc can use to lets say, pick it up, throw it, eat it, ect. And the npc will use their MBTI to determine what should be done in the given circumstance.

Part two of the idea is that these objects will also hold ‘experience’ data that the ai will pick up and remember for certain lengths of time. This data can be pugged into their design making structure and called on during other circumstances to determine what to do or how to interact.

Heres a live example,

The npc walks up to a wooden chair
He sees that the chair can be picked up, sat on, broken, and burnt

Along with these verbs are tags that help the npc with the decision.
Example, ‘sit down’ is tagged for resting
‘burn’ is tagged for warmth

He thinks about it and determines that he needs a rest so he sits down
His fatigue goes down and the chair teaches him that sitting down makes him rested
After that he thinks again and determines that he is really cold, so he finds an object that will light the chair (oil and matches) and does so

This demonstrates another part of the idea, in which objects must interact with each other using the npc as a medium. The matches will be tagged as ‘makes fire’ the oil would be ‘spreads fire’ and the chair’s ‘burn’ tag will say that it needs something to start and spread the fire, in order to be used. Sort of like, requirements for an action. To discover the tools, the npc must be able to scan local tags.

The chair is lit and the chair teaches the npc that burning things will make him warmer
However this chair exists in a hay barn, and now that there is a giant fire in the room, all the hay ignites

This is can be accomplished by state broadcasting. In which objects changing state ( eg. Stable to ablaze ) will broadcast the change to all other objects and and objects listening to such a change will decide what to do. ( eg. burst into flames )

So now our npc is to hot and the hay teaches him that hay + fire is not good.
He leaves the barn because the environment outside is not on fire

This action causes a conflict in his code.
On one hand he learned that fire is warm and thus good when cold
On the other hand he learned that hay on fire is bad and makes him to hot
This is not exactly what should be learned here, but I never said this design was perfect

And so our npc lives to see another day, only slightly smarter then he was before. But he gained some valuable survival skills.

This design still needs some tweaking, but at least now we have a working model that I can start writing and testing.
One other thing I should mention though, as these npc’s collect environment data from these objects, certain ideas and concepts are going to collide and others will become useless. We should also account for the human’s ability to forget ideas as well. Some form of garbage collecting will have to be done to clear out bad data. Just keep that in mind.

Tags: , , ,

The blog, my work, and you

May 30, 2007 in Ramblings | 1 comment

I have long been wanting to create a system where I can freely express my trials and errors while working on a variety of projects. This is the result. In this blog, once I get it going, will feature many open source programs I write along with my ideas, thoughts, and general how-to’s.

I am a computer programmer, so expect most posts to involve code in some way, but some days I might feel like just writing about a story or idea I had. Sometimes when I am trying to think of a solution I type myself long paragraphs to record my thoughts. I promise to not post them all, but if at a later time I think my ramblings blog worthy there will probably be a new post.

First thing I am going to do is post up some open source projects I had been working on, one being an auto updater for steam mods, as well as a tutorial for changing shot distribution in half life source, day of defeat source, and team fortress 2.

For those who might know my work, I wrote the cof plugin for day of defeat source, the same version CAL uses in their Sentential plugin. I also was the programmer behind Prodod, a competition mod for day of defeat source which ended up going nowhere.

Most of my experience is dealing with C or C++ and assembly systems, however I do mingle in network systems and pretty much anything that ends up in my way. For instance, the source mod auto updater was written in VB .net, a language I hardly knew until my second rewrite of the program.

I want to write more but this post is getting kind of long so I will stop here, soon this web site will be filled with tutorials for doing this or that, basically, whatever ends up causing me some trouble.

One last note, if you came here looking for the golden sun project, you are in the right spot, I am currently moving all my source and work here. I decided to not have a single dedicated web site because I am the only developer and its more of a hobby project of mine. But fear not, there will be quite a lot of posts here about that.

Tags: ,

Newer entries »

Charles Solar is Stephen Fry proof thanks to caching by WP Super Cache