ShiVa Networking part 2: Sessions, Events, Broadcasting – ShiVa Engine

ShiVa Networking part 2: Sessions, Events, Broadcasting

Last week, we introduced the fundamentals of working with ShiVa’s networking and wrote a simple program that connected to a remote server session. This week, we are going to build a simple chat application that allows 2 or more clients to exchange text messages. Along the way, you will learn more about sessions, multiplayer events, the user API, and common pitfalls for communicating between remote AIs that you are probably not aware of if you only ever developed single player games.

Chat application blueprint

Before building any application, you should sketch out the steps involved and the rudimentary control flow. For our simple chat, we are going to do the following:
1. connect to server (last week) and select a session
2. load a (shared) scene, since broadcasting commands are bound in the scene API
3. invoke a chat HUD instance
4. populate the userlist by scanning the scene for connected users
5. use broadcasting to transmit a message to all scene users
overview editor

Player ID and custom info

Just like with the server info, we need a central storage container for all player info. We can edit last week’s NETWORK_connect.onInit to reflect that:

function NETWORK_connect.onInit (  )
    -- fill server info table with some default data
    local serverinfo = this._htServer ( )
    hashtable.add ( serverinfo, "ip", "" )
    hashtable.add ( serverinfo, "port", "5354" )
    hashtable.add ( serverinfo, "session", "Default" )
    hashtable.add ( serverinfo, "isConnected", false )
    hashtable.add ( serverinfo, "isPending", false )
    hashtable.add ( serverinfo, "hasScannedForSessions", false )
    -- same for player info
    local playerinfo = this._htPlayer ( )
    hashtable.add ( playerinfo, "id", 0 )
    hashtable.add ( playerinfo, "name", "ShiVaUser" ..math.floor ( math.random ( 10, 100 ) ) )

A user ID other than 0 will be assigned to you by ShiVa automatically as soon as you connect to a server, while the name is something users will want to customize on their own, which must therefor be transmitted to remote users manually.
Changing your player ID from 0 to something else is one of the first things the server will do to a client after a successful connection. To store your new ID, you have to capture the event and modify your hashtable value:

function NETWORK_connect.onUserIDChange ( nOldUserID, nNewUserID )
    log.message ( "EVENT: " ..nOldUserID .." changed their ID to " ..nNewUserID )
    -- overwrite player ID in info hashtable for easy lookup
    local playerinfo = this._htPlayer ( )
    local playerID = hashtable.get ( playerinfo, "id" )
    if playerID == nOldUserID then
        hashtable.set ( playerinfo, "id", nNewUserID )
        log.message ( "My new Player ID is: " ..nNewUserID )

Multi-session servers

One server can multiple sessions at once. On the other hand, clients in one session cannot interact with the other sessions, and only one session (“current session”) can be active on a client at any time. It helps to think of sessions as chatrooms, where you can only send messages to the people in the same room you are connected to.
Last week’s connection code simply assumed that there was only one session running on the server – but this is not always the case. Before you connect to a server session, you can scan for what is already running. Staying with the chatroom metaphor, you can use this to show users a selection of available chatrooms. The modified connection loop from last week’s sample would look something like this:

function NETWORK_connect.connection_onLoop ( )
	-- server connection stuff comes before here
    hashtable.set ( serverinfo, "isPending", false )
    -- if multiple sessions are running on the server, tell us
    if hashtable.get ( serverinfo, "hasScannedForSessions" ) == false then
        local nSessionCount = server.getSessionCount ( hCurrentServer )
        if nSessionCount > 1 then
            -- run through all sessions and check if the name exists
            local sname = ""
            for i=0, nSessionCount-1 do
                sname = server.getSessionNameAt ( hCurrentServer, i )
                log.message ( "Server is running a session: " ..sname )
        hashtable.set ( serverinfo, "hasScannedForSessions", true )
	-- etc.

Since we are operating in an onLoop state, we have to introduce another control variable “hasScannedForSessions” into our serverinfo hashtable, otherwise the session info would be queried every time the loop is executed: Since the loop runs for at least 3 frames (server pending/connect, session connect/pending, session connected) you would dump the same info into the log at least 3 times.

server.setCurrentSession ( hCurrentServer, "myCoolSessionName" )

Executing server.setCurrentSession will always create a new session of the specified name on the server if no such session is already running. If you want to prohibit that behaviour, you either need to hardcode session names into your program, or only allow users to choose from the scanned list you obtained through server.getSessionNameAt in the previous example.

Session events

Sessions have two events: onUserEnterSession and onUserLeaveSession. When a new client connects to a server, the “Enter” event is triggered for all clients, but in different ways: Already connected clients will see only a single event with the new client transmitting its ID, while the new client will get an event for every client already in the session. Keep this in mind, since the onUserEnter/LeaveScene events work differently.

Loading a scene

After you have successfully connected to a session, you need to load a scene, since a lot of broadcast and remote user commands are bound to the scene API. If you do not intend to load any 3D content, like we do in our chat, we might as well load an empty dummy scene – but load one we must.
Loading a multiplayer scene is essentially the same as loading a single player scene. It only becomes more complicated once you have multiple scenes, as you need to communicate the different scene names with all users in the session, so the same scenes are loaded for all users.

Scene events

Scenes have two events: onUserEnterScene and onUserLeaveScene. When a new client connects to a scene, the “Enter” event is triggered only for the clients having already loaded the scene, but not for the new client. In order to see who has loaded the scene before you entered, you must scan the users in the scene:

    -- load dummy scene
    application.setCurrentUserScene ( "COMMON_dummy" )
    local hScene = application.getCurrentUserScene ( )
    if hScene == nil then
        log.warning ( "NETWORK_chat.chat_onEnter: could not verify scene handle" )
        -- get all users in scene for username table
        local nUsers = scene.getUserCount ( hScene )
        local rUser = nil
        for i=0, nUsers-1 do
            rUser = scene.getUserAt ( hScene, i )
			-- don't worry about the following event, we will explain it later
            user.sendEvent ( rUser, "NETWORK_connect", "onQueryPlayerInfo", "name",  user.getID ( this.getUser ( ) ), "NETWORK_chat",  "onReceivePlayername"  )

This listing will include your own player ID. For our chat, this is wanted behaviour, since we want to list our own name in the userlist, but you might not want to in your own game, so keep that in mind.

A simple chat UI

For our UI, we will need a list component for the chat lines, another list component for the connected users, an edit box for the text put, and a button which submits the text.
ui pic
The button itself connects to a custom event in the ChatAI, which takes the input, clears it from the field, and broadcasts it to all users in the scene:

function NETWORK_chat.onSendButtonPressed (  )
    local hUser = this.getUser ( )
    -- check if we are allowed to send
    if this._bChatting ( ) == false then return end
	-- boring: get UI component, getLabelText, setLabelText="", return text
    local m = this.getInputLineText ( )
    if m == nil then return end -- ignore if empty
    -- broadcast section
    local hScene = application.getCurrentUserScene ( )
	-- call a custom event which returns the name of your own player
    local myname = user.sendEventImmediate ( hUser, "NETWORK_connect", "onQueryPlayerInfo", "name", nil, nil, nil )
	-- broadcast the name to a custom AI Event (which all users have) which adds the player name to a table
    scene.sendEventToAllUsers ( hScene, "NETWORK_chat", "onReceiveChatmessage", myname ..": " ..m )

Remote custom event chain

Generally speaking, you can target custom multiplayer events to users in two ways, either as boradcast (scene.sendEventToAllUsers) or to individual users, the latter of which requires you to send your userID, AIModel name and Event olong with the original request, in case you need a return value. In our chat for instance, we need to transmit the username of every user to another client. We know the value is stored in a hashtable. We will provide the information through a handler in the connect AI, which also stores the playerinfo hashtable:

function NETWORK_connect.onQueryPlayerInfo ( sKey )
    local ht = this._htPlayer ( )
    local storedKey = hashtable.get ( ht, sKey )
    return storedKey

If this were single player, we could make use of the return value in user.sendEventImmediate, where rUser is the handle to the remote user:

local name = user.sendEventImmediate ( rUser, "NETWORK_connect", "onQueryPlayerInfo", "name" )

Unfortunately, this does not work since sendEventImmediate cannot be used on remote users. The approach above does not work. Instead, we have to use sendEvent (without Immediate) and modify both our handler and request to include the userID, the target AIModel of that user, and the target event, so we can capture the result. And yes, you need to send the user ID instead of the user handle. You can easily switch between ID and handle using user.getID and application.getUser though.
The request:

user.sendEvent ( hUser, "NETWORK_connect", "onQueryPlayerInfo", "name",  user.getID ( this.getUser ( ) ), "NETWORK_chat", "onReceivePlayername" )

The new handler looks like this:

function NETWORK_connect.onQueryPlayerInfo ( sKey, nAnswerToUserID, sAnswerToAI, sAnswerToEvent )
    local ht = this._htPlayer ( )
    local storedKey = hashtable.get ( ht, sKey )
    if nAnswerToUserID ~= nil then
        local hAnswerToUser = application.getUser ( nAnswerToUserID )
        if hAnswerToUser == nil then log.warning ( "connect.onQueryPlayerInfo: could not resolve user handle!" ) return storedKey end
        user.sendEvent ( hAnswerToUser, sAnswerToAI, sAnswerToEvent, user.getID ( this.getUser ( ) ), storedKey )
    return storedKey

And the recipient handler:

function NETWORK_chat.onReceivePlayername ( nUserID, sName )
    -- add player ID and their name to the table
    this.refreshChatUserlist ( 0, nUserID, sName )

The custom function refreshChatUserlist ( nIDtoRemove, nIDtoAdd, sNameToAdd ) takes care of storing the username and its ID in a table and write these changes to the list component in the HUD. Since ShiVa does not allow for the creation of custom datatypes without plugins, the table is formatted in a way that the even fields are IDs and the odd fields are the name strings:

-- dataformat for player table:
    -- 0: player1_ID
    -- 1: player1_name
    -- 2: player2_ID
    -- 3: player2_name
    -- etc.

You can then work with offsets and stepping in for-loops to retrieve the relevant data:

    -- refresh HUD list
    local t = this._tUsernames ( )
    ts = table.getSize ( t )
    local hUser = this.getUser ( )
    local c = hud.getComponent ( hUser, "chat.list_users" )
    if c == nil then log.warning ( "chat.refreshChatUserlist: could not find user list component!" ) end
    -- clear all previous entries
    hud.removeListAllItems ( c )
	-- look at the "1" offset and "2" stepping in the for-loop
	local name = ""
    for j=1, ts-1, 2 do
        name = table.getAt ( t, j )
        hud.addListItem ( c, name )

You should now have all the components to write a little chat application like this one:


1. Sessions are like chatrooms. You can only talk in one at a time. But servers can run many sessions at once.
2. Use scenes for broadcasting, even if you don’t want to display 3D content.
3. No (user) handles as event parameters!
4. SendEvent additionally requires you to send userID, AIModel Name and Event name if you ever want a response. SendEventImmediate does not work in remote environments.
5. Session events and Scene events behave differently.

  • slackBanner