Systems and Servers

This week in Captureball has had some key steps towards creating a server build that will live on the cloud in order to facilitate multiplayer matches! Last we got the Custom version of the Unreal Engine 4.25 built with an integrated GameLiftSDK ready to be used. The way the GameLiftSDK is able to be used is through Unreal Engine’s GameMode class in C++. It is here that the server will have ways for the GameLift service to call different functionality through the server’s GameMode class.

Any easy way to handle the way GameLift will be used is through defining different structs for various different server operations(see below):

These structs are simple containers for the different server operations and will have to be expanded upon as development progresses. The status variable is a very simple way of checking the state of AWS functionality at different points of time. For now the operations in the basic Captureball server build are as follows:

In the CaptureballGameMode.cpp file the implementation has the AWS callbacks connected to their corresponding struct variables like StartGameSessionState is connected to the creation of a match starting:

We can cast the information that holds the current server state to check if the desired GameLift function was successful (in this case its check if the match was started). The GameMode class is now a way for AWS to communicate with our game server which will communicate with our clients with a different abstraction that will be detailed in the future.

Now with the basic server build functionality we can build and test it locally using the command line. The SDK comes with a jar file that can be ran on a port to simulate the GameLift service:

From here we now run the server .exe file and then run an AWS CLI command in order to create a game session on the local host:

Luckily looking back at the command line window from where the Captureball server was running we see that after all the building and compiling the build is working:

We can see from above that our onStart callback was successful when we started a new game session on the Captureball server. There is also a periodic server health check callback that GameLift should be running and that is indeed the case as well:

This is a great step in multiplayer Captureball on AWS with the last part of this step being uploading the build onto AWS to be used on an instance:

With a successful upload the next steps are to get the instance build setup and to start incorporating GameLift FlexMatch!

Stage Modifications

Lastly we made a few updates to the stage. We removed the areas behind the goals, the invisible walls, and made the stage a bit larger. We also added a timer and some visuals to the disappearing stage blocks so that they disappear a little after warning the player as opposed to immediately.

Lastly, we made a few minor modifications to how the player interacts with the stage, particularly with the ghost by updating their movement range to be confined to the correct area so that they cannot simply float off to infinity.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: