Events are a powerful way to send data to the game server and create data to be processed in the background on the server. You can create and receive data which can be forwarded to 3rd-party services like Analytics, Ads, In-app Purchases, and more.
This has a number of advantages for game studios and developers:
It reduces the number of client-side SDKs which shrinks the game client; valuable to improve the FTUE and number of players who will download the game,
Less network traffic is used by game clients to various 3rd party services, and
It significantly reduces the integration time, and active maintenance cost spent by the development team.
A good use case is to implement game analytics or LiveOps by using events emitted in the client or by server-side functions. These events will be processed in the background inside Nakama server. Players have minimal interruption to their gameplay experience and developers can optimize and improve games based on the feedback from the analytics.
Internally this feature is implemented with a high performance circular buffer to store events received and a worker pool of consumers (event handlers) to ensure that large numbers of events received cannot overload the server if the event handlers cannot keep up.
Events can be sent to the server by game clients or created on the server. An event has a name and a map of properties which decorate the event with more information.
You can also take advantage of after hooks in the server runtime when you want to send events from other features in the server. For example when a user account is updated and you might want to send an event to be processed.
Server
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
funcafterUpdateAccount(ctxcontext.Context,loggerruntime.Logger,db*sql.DB,nkruntime.NakamaModule,in*api.UpdateAccountRequest)error{evt:=&api.Event{Name:"account_updated",Properties:map[string]string{},External:false,// used to denote if the event was generated from the client
}returnnk.Event(context.Background(),evt)}funcInitModule(ctxcontext.Context,loggerruntime.Logger,db*sql.DB,nkruntime.NakamaModule,initializerruntime.Initializer)error{iferr:=initializer.RegisterAfterUpdateAccount(afterUpdateAccount);err!=nil{returnerr}returnnil}
Server
1
2
3
4
5
6
7
8
9
10
11
12
localnk=require("nakama")localfunctionafter_update_account(ctx,payload)localproperties={my_key="my_value"}localtimestamp=nk.timelocalexternal=false-- used to denote if the event was generated from the clientreturnnk.event("event_name",properties,timestamp,external)endnk.register_req_after(after_update_account,"UpdateAccount")
The server will generate built-in events which can be processed specifically for the SessionStart and SessionEnd actions. These special events occur when the server has a new socket session start and when it ends. See below for how to process these events.
Events can be processed with a function registered to the runtime initializer at server startup. Events will have its external field marked as true if its been generated by clients.
Processing events through Lua/TypeScript runtime functions is not yet supported.
Server
1
2
3
4
5
6
7
8
9
10
11
12
13
14
funcprocessEvent(ctxcontext.Context,loggerruntime.Logger,evt*api.Event){switchevt.GetName(){case"account_updated":logger.Debug("process evt: %+v",evt)// Send event to an analytics service.
default:logger.Error("unrecognised evt: %+v",evt)}}// initializer runtime.Initializer
iferr:=initializer.RegisterEvent(processEvent);err!=nil{returnerr}
Code snippet for this language TypeScript has not been found. Please choose another language to show equivalent examples.
Code snippet for this language Lua has not been found. Please choose another language to show equivalent examples.
Events which are internally generated have their own registration functions. The SessionStart is created when a new socket connection is opened on the server.
Code snippet for this language TypeScript has not been found. Please choose another language to show equivalent examples.
Code snippet for this language Lua has not been found. Please choose another language to show equivalent examples.
The SessionEnd event is created when the socket connection for a session is closed. The socket could have closed for a number of reasons but can be observed to react on.
To protect the performance of the server the event processing subsystem is designed to limit the resources allocated to process events. You can adjust the resources allocated to this subsystem with these configuration settings.
Configuration Key
Value
Description
runtime.event_queue_size
int
Size of the event queue buffer. Defaults to 65536.
runtime.event_queue_workers
int
Number of workers to use for concurrent processing of events. Defaults to 8.
To review other configuration settings have a look at these docs.