So you may have noticed that there hasnt been a post in quite awhile. Basically we are making some major changes to the project heading tword a demo… We are not ready to reveal the changes as of yet but they are pretty drastic to say the least. We will be heads down for another month or so re-tooling the project, so stay tuned for updates.
Well after months of trying to find a name for our latest project I think we finally settled on one. We are calling it: Ares Fall. The name has quite a bit of meaning as far as the story goes. I don’t want to give anything away so I wont say what the connections are. We can now begin the process of coming up with a logo and graphic. Sometimes I really enjoy doing that kind of work. It’s very refreshing to get away from the 3d stuff.
At a certain point in the game you will be able to purchase a buddy. He is called a War Construct. It’s leftover tech from some ancient conflict. He will follow you around and assist in killing baddies using a spike launcher.
We wanted to start posting videos of things we were workign on. Currently the inventory system is getting the most attention so it seemed a good canidate. Now remember this is a work in progress and will change quite a bit.
Resource management is a crucial part of any game engine, so I’m going to give a quick rundown on how we’re managing resources for the new game. During my time at Oddworld I became thoroughly addicted to C++ templates, so our resource management system uses templates. I’m also a huge fan of smart pointers (thanks again to Charles Bloom and the Oddworlders). There are a lot of haters out there who have bad things to say about templates and smarties, but they don’t know what they’re talking about, so just ignore them.
Okay, so the first step is defining what a resource is. In the most general sense a resource is a chunk of data that is used by the game. For the purpose of this post I’m just going to talk about file based resources. The majority of resources are file based, so that covers almost all of them. Some examples of resources are: models, textures, shaders, effects, fonts, etc.
In our engine all resources are loaded and accessed the same way, through the resource manager. The resource manager exposes resources through templated functions. Here is an example of how we load a texture in our engine:
WMV FORMATTexturePtr spTexture =
ResourceMgr::Load<Texture>("data\texture\my_texture.dds");
Similarly there are methods for getting a resource as well:
TexturePtrC spTexture =
ResourceMgr::Get<Texture>("data\texture\my_texture.dds");
TexturePtr spTexture =
ResourceMgr::GetMutable<Texture>("data\texture\my_texture.dds");
Now if we want to get a Model resource we simply point the path to the model file and wonderful magic of templates works out the different type.
ModelPtrC spModel =
ResourceMgr::Get<Model>("data\model\my_model.gr2");
With this example you can see that loading and accessing resources is a common interface no matter what type of resource you’re loading. Adding new resources is really easy because all of the code to manage loading and accessing is already done in the resource manager. It also means that no matter where you are in code you always have access to all your resources through the resource manager.
We’ve added an additional construct to our resource management system that allows for factory creation of resources. We enforce some rules for how our resources are laid in the file system and use those constructs to determine the type of the resource. All of our resources register class factories that use their class name as the factory key. So, for example, a Model registers the class factory “Model”, and a Texture registers the class factory “Texture”. When we want to load a generic resource without knowing what type it is the engine determines the type by looking at the parent directory names to find a class factory. If the current directory doesn’t match a registered factory then it continues to walk up the directory chain until it finds one. I find this also keeps the resource data in a clean and orderly state by keeping our resource files organized in the same way they are organized in code. In addition these rules aren’t too draconian, and they allow room for Ryan to have sub-directories to keep his assets organized within these “factory” folders.
You might be wondering why we would need to go through the trouble of having a mechanism for creating a resource without knowing ahead of time what type it is, so I’ll go through an example. Having a generalized system for loading resources is useful for things like game objects. Let’s say we have a treasure chest and it contains a number of game objects that are defined as a list files. For example:
m_vContents:
{
#: "data\GameObject\WeaponDef\ice_rod.txt"
#: "data\GameObject\MeleeWeaponDef\sword.txt"
#: "data\GameObject\ShardDef\blue_shard.txt"
}
As you can see we have three very different things in this treasure chest (an ice rod, a sword, and a blue shard). Now we need to spawn these items when the treasure chest is opened, but because we have a generalized resource manager we don’t need to know anything about what type of game object we are spawning. The code just looks at the resource path to find the appropriate class factory and loads the correct game object definition. Then we use the game object def to spawn the game object. This means we can always just add new game objects, and they will work with everything (in this case treasure chests) without the need to retro fit. When we first started making the treasure chests we filled them with pretty standard stuff, but then I told Ryan that you can put *any* game object into the chest. Naturally he tried putting some spine slugs into a chest, so you open them up and blamo you’re getting attacked by spine slugs! Sweet! Of course we probably won’t have enemies hidden inside treasure chests, but it just goes to show how flexible class factories make the code.
Here is the initial layout design for the basic inventory system. We have it partially implimented currently. Drew has added some nice animations for when you swap items. There will also be a outfit page that slides in that will allow you to see exactly what items you have eqquiped. We also want to do a bunch of work so that its super easy to see how each item compares to the one that you have currently eqquiped.
Once we have it fully implimented I will make a video to show the features in motion.
Along with the random item work we are doing we have begun to work on the inventory syste. Its important for us to make using the inventory a satisfying and simple process. Players should look forward to using it, it goes along with our philosophy that every task should be fun and rewarding.
We have begun the design process on our random loot drops and inventory system. It’s pretty complicated stuff to work on, but it is really rewarding in that it is such an important pillar in this type of game. We are really going to spend a ton of time on how the inventory system works. Nothing ruins a loot game more than a horrible management UI. Once a few things have settled about our design I will post in more detail.
We got treasure chests implemented today. We set them up with animations and sound as well as the ability to spawn items. So I have spent all day making different types of chests. Some of them are affected by time of day, such as Moon Chests which can only be opened at night. We have a few other ideas of unique things to do with chests but I don’t want to spoil the surprise.
I just finished up the textkey editor. It handles all the attribute creation and management for the user. All you have to do to create a textkey is start the editor. It then generates all the proper attributes on the ROOT bone and creates a UI that is connected to those attributes.
It also auto generates a popup list of the bones in the scene so you can just select which bone you want to have the textkey on. It does the same thing for the effects. I can’t stand typinf that shit in so I like to make tools that do it for me.
Here is the .mel I used to make the editor. The stupid blog software kinda messes up the formatting.
global proc vs_textkeyEditor()
{
string $bone = “TMP:ROOT”;
//Check to see if a ROOT bone exists. If not error out.
if( `objExists $bone` != 1 )
{
error(”No ROOT exists, so what the hell are you doing?”);
}
//If the window exists delete it and recreate.
string $winName = “VSTextkeyEditorss”;
if (`window -exists $winName`)
{
deleteUI $winName;
if (`windowPref -q -ex $winName`)
{
windowPref -r $winName;
}
}
string $window = `window -title “Textkey Editor” -widthHeight 400 300 -rtf 1 -s 0 -menuBar false $winName`;
string $form = `formLayout -numberOfDivisions 100`;
string $column = `rowColumnLayout -numberOfColumns 3
-columnWidth 1 45
-columnWidth 2 95
-columnWidth 3 250`;
text -l “Frame” -p $column;
text -l “Bone” -p $column;
text -l “Effect Path” -p $column;
// Gather all the bones into an array to generate a popupmenu
string $allBones[] = `ls -et joint`;
// Make sure all the proper attributes exist on the ROOT bone
vs_textkeyAttributes;
// Loop and generate all the UI widgets for editing the textkeys
for ($i = 0; 10 > $i; ++$i)
{
intField -p $column (”vs_Frame_”+$i);
// Assume the attribute extists at this point and connect the UI widget to it
connectControl (”vs_Frame_”+$i) ($bone+”.vsFrame”+$i);
textField -p $column (”vs_Frame_Bone_”+$i);
// Assume the attribute extists at this point and connect the UI widget to it
connectControl (”vs_Frame_Bone_”+$i) ($bone+”.vsFrameBone”+$i);
// Generate a popupMenu of all the bones in the scene as a shortcut for the user
popupMenu;
for ($ii = 0; `size($allBones)` > $ii; ++$ii)
{
// Create the command string for when the user selects this item in the popupmenu
string $commandString = (”setAttr -type \”string\” ” + $bone + “.vsFrameBone” + $i + ” ” + $allBones[$ii] + “”);
// Create the popup menu
menuItem -l $allBones[$ii] -c $commandString;
}
textField -p $column (”vs_Frame_Effect_”+$i);
// Assume the attribute extists at this point and connect the UI widget to it
connectControl (”vs_Frame_Effect_”+$i) ($bone+”.vsFrameEffect”+$i);
popupMenu;
// Generate a popup menu for all the effect files in the effects dir to save the user time
string $effectPath = “d:/VoidStar/Games/Legends/Data/Effects/EffectDef/”;
string $allEffectFiles[] = `getFileList -folder $effectPath -filespec “*.txt”`;
for ($ii = 0; `size($allEffectFiles)` > $ii; ++$ii)
{
// Create the command string for when the user selects this item in the popupmenu
string $commandString = (”setAttr -type \”string\” ” + $bone + “.vsFrameEffect” + $i + ” \”Data/Effects/EffectDef/” + $allEffectFiles[$ii] + “\”");
// Create the popup menu
menuItem -l $allEffectFiles[$ii] -c $commandString;
}
}
formLayout -e
-attachPosition $column “top” 0 0
-attachPosition $column “bottom” 0 100
-attachPosition $column “left” 0 0
-attachPosition $column “right” 0 100
$form;
//Display the window onscreen
showWindow $winName;
}
global proc vs_textkeyAttributes()
{
string $bone = “TMP:ROOT”;
//Check to see if a ROOT bone exists. If not error out.
if( `objExists $bone` != 1 )
{
error(”No ROOT exists, so what the hell are you doing?”);
}
// Loop and generate attributes on the ROOT bone if they do not already exist
for ($i = 0; 10 > $i; ++$i)
{
if (`attributeExists (”vsFrame”+$i) $bone` != 1)
{
addAttr -ln (”vsFrame”+$i) -at long -min -10000 -max 10000 -dv 0 $bone;
}
if (`attributeExists (”vsFrameBone”+$i) $bone` != 1)
{
addAttr -ln (”vsFrameBone”+$i) -dt “string” $bone;
}
if (`attributeExists (”vsFrameEffect”+$i) $bone` != 1)
{
addAttr -ln (”vsFrameEffect”+$i) -dt “string” $bone;
}
}
}