During the AiGameDev Conference 2010 at Paris Claudio Pedica, a researcher at CADIA Labs, Reykjavik University, currently collaborating with CCP Games presented us their new social interaction system in a talk titled Human Territoriality for EVE Online’s Socially Smart Characters.

This was a short preview on how the space stations are going to be populated in the next EVE online expansion.

The main focus of the research conducted by CCP is based on the lack of feedback in games when it comes to interactions. For example if you pass besides a game character, he doesn’t notice you or in worse cases, if you bump into him, the most common reaction is that he won’t even step aside and your character stops dumbly like when facing a wall! Fortunately, not all games react like this. In GTA when you hit someone or pass close to him he steps aside or even says something to you.

What the guys at CCP are trying to do is to recreate an interaction system based on how humans practically cope with interactions and how they react to other people’s physical presence.

In the demos shown we could see the character move close to a group of NPCs; when close enough, the group understands that this character wants to be part of their group so they take a step aside to form a bigger but still homogeneous group.

The “circle” itself is, in this system, the interaction unit; each character and group possesses one and each unit is designed for a particular type of interaction.

1) First there is the personal circle which defines the limit of the body area.

2) The external circle is used for the close social interactions like dialogs or people walking near (also true for groups).

3) An inner circle is also defined by the participants of the group: a circle defines its body and the external circle of it. In another example we saw one participant moving a few steps from his former position and the rest of the group following him to recreate the circle.

I actually don’t play EVE Online at all and I don’t really know what they are planning to do with the new space stations system but having this feature is über-cool and I think it would really improve the experience of the players (at least contributing to a more immersive experience).

Having people walking from one spot to another or joining conversations or even reacting to the players’ presence will surely make us feel more in a real living world. When you think that some games only feature static NPCs, this talk gets even more impressing!

Human Territoriality for EVE Online’s Socially Smart Characters by Claudio Pedica can be downloaded from the AiGameDev website.

Luckily, they can discover the joy of working with the open-source “OS for the poor”, Linux!

We have already improved the most current platforms on the market with our kickass Mojito Engine, and we are now currently working on the Linux version.

And just because we like you guys, readers of this blog, we will offer you the exclusivity of the year : the first screenshot of a not-so-mysterious project, running on Ubuntu!

I know how much it’s beautiful, but don’t cry yet, keep your tears when it will be fully functional so stay tuned!

Compilers only allow TLS on POD ( Plain Old Data ) types, no object can be used. This extension allows to use all types of objects, as long as it has a default constructor.

Allowing complex types in TLS leads to 2 challenges : allocating enough memory to contain the object and calling constructors and destructors on thread startup and exit.

In the previous version, the memory used for TLS was a table of 4 bytes-long items. We could have used this system to store a pointer to the complex object, but we tried to avoid dereferences as much as possible. The system is then changed to contain any size needed. Each TLS instance contains the index inside a buffer. This buffer is created for each new thread and contains the memory needed to store all objects. The base class constructor now takes the size of the object and tracks the total size in a static variable. When the thread starts, the buffer is allocated and all objects are constructed inside this buffer. But more on this later. This technique has the advantage of allocating a single chunk of memory for a thread. It avoids memory waste of multiple allocations.

 
class ThreadLocalStorageBase
{
    static int m_buffer_size = 0;
    static TLSIndex m_tls_identifier;
    int m_index;
 
protected:
    ThreadLocalStorageBase( int object_size )
    {
        object_size = ( object_size + Alignment - 1 ) & ~( Alignment - 1 );
        m_index = m_buffer_size;
        m_buffer_size += object_size;
    }
 
    void * GetThreadLocalStorage() const 
    {
        char * local_storage_table = reinterpret_cast<char*>( TLSGet( m_tls_identifier ) );
        return &local_storage_table[ m_index ];
    }
};
 
template<typename T>
class ThreadLocalStorage<T> : public ThreadLocalStorageBase
{
    ThreadLocalStorage() : ThreadLocalStorageBase( sizeof( T ) )
    {
    }
}

OS TLS has the property to initialize the value to zero the first time a thread accesses it. As we support any class, we need to provide a way to construct the objects. We decided to initialize all variables before entering the thread function. If variables are not used frequently, a lazy initialization mechanism can be implemented. In Mojito, a class encapsulates the OS thread object. We have then the place to call this initialization. The best mechanism depends on the way you will use TLS variables.

In both cases, when the thread is about to end, the allocated memory must be freed. So a call to the TLS finalizer must be done. ( pthread allows a destructor function to be registered, so you can take advantage of it ). Once again, in Mojito, the thread class is taking care of it.

A question that might have arose : how do you have access to all variables spread across the code? The trick is quite simple : in the constructor, register the variable into a single-linked list. This technique ensures that as soon as main is entered, the linked list is complete. I discovered this trick in the command line option package of LLVM

As we have a class for each type, a base class has been created. It takes care of creating the list and provides the functions to initialize and finalize the variables. It also keeps track of accessing the thread local buffer.

class ThreadLocalStorageBase
{
    ...
    ThreadLocalStorageBase * m_next;
    static ThreadLocalStorageBase * m_first = 0;
 
public:
    ThreadLocalStorageBase( int object_size )
    {
        ...
        m_next = m_first;
        m_first = this;
    }
 
     static void StartupOnThreadEnter()
     {
        void * local_storage_table;
 
        local_storage_table = malloc( m_buffer_size );
        memset( local_storage_table, 0, m_buffer_size );
 
        TLSSet( m_tls_identifier, (void*)local_storage_table );
 
        ThreadLocalStorageBase * current = m_first;
 
        while( current )
        {
            current->InitializeObject();
            current = current->m_next;
        }
    }
 
    static void CleanupOnThreadExit()
    {
       ThreadLocalStorageBase * current = m_first;
 
        while( current )
        {
            current->FinalizeObject();
            current = current->m_next;
        }
 
        free( TLSGet( m_tls_identifier ) );
    }
 
protected:
 
    virtual void InitializeObject() = 0;
    virtual void FinalizeObject() = 0;
};

When the base class is in place, here are the modifications made to the subclass

template< typename T >
class ThreadLocalStorage : public ThreadLocalStorageBase
{
public:
    operator const T&() const
    {
        void * thread_local_storage = GetThreadLocalStorage();
        return *reinterpret_cast<T*>( thread_local_storage );
    }
 
    ThreadLocalStorage & operator=( const T & value )
    {
        void * thread_local_storage = GetThreadLocalStorage();
        *reinterpret_cast<T*>( thread_local_storage ) = value;
        return *this;
    }
 
protected:
 
    virtual void InitializeObject()
    {
        new( GetThreadLocalStorage() ) T();
    }
 
    virtual void FinalizeObject()
    {
        static_cast<T*>( GetThreadLocalStorage() )->~T();
    }
};

We now have a complete implementation of TLS that supports all types of object. But what if you wanted to initialize your variable to a specific value. This last modifications uses the container object to store a default value and use it when initializing the TLS instance.

The code is very simple. We just include a constant instance of the variable’s type, that we fill using the constructor. We then provide this instance to the constructor.

template< typename T >
class ThreadLocalStorage : public ThreadLocalStorageBase
{
    const T m_default_value;
 
public:
    ThreadLocalStorage( const T & default_value = T() ) :
        ThreadLocalStorageBase( sizeof( T ) ),
        m_default_value( default_value )
    {
    }
 
protected:
 
    virtual void InitializeObject()
    {
        new( GetThreadLocalStorage() ) T( value );
    }
 
    virtual void FinalizeObject()
    {
        static_cast<T*>( GetThreadLocalStorage() )->~T();
    }
}

This concludes this pair of posts on Thread Local Storage as we use them in Mojito. Comments are warmly welcomed. Special thanks to Bjoern Knafla for his comments.

The source code can be found here