Agones: Integration with Unreal Engine

[digitalfiz]

Unreal Engine has an Online Subsytem that provides an abstraction layer for game developers to build sessions and match making in a standardized way.

It would be awesome if there was a plugin for Agones that added subsystem integration so it can easily be used in Unreal.

https://docs.unrealengine.com/en-us/Programming/Online

[markmandel]

Good note from chat - we should have blueprint support as well.

[justinliew]

What sort of Blueprint support would you envision? In my experience implementing an Online Subsystem specifically for an Agones server should be sufficient (ie. the OSS would talk to the sidecar and then provide all the required functionality/hooks required for the server).

[markmandel]

I'll defer to @digitalfiz on this one. My Unreal experience is very minimal - but something I want to change. So would be great to have some direction from all of you.

[digitalfiz]

You may be correct @justinliew. Technically by integrating with the online subsystem you get quite a bit of built in blueprint support. Maybe all the blueprint support that is needed? At this point I don't know enough about all of Agones functionality to know if anything more is needed.

[justinliew]

Blueprints are meant for scripting, and typically used by designers or programmers who are implementing gameplay mechanics, level mechanics and the like. I can't think of any obvious reasons those users would need any Agones support. Possibly I'm missing something, but I'd say the less networking you need to expose to Blueprints, the better.

[fire]

A usecase for blueprint support integrating with Unreal Engine and back-ends is defining the statistic generated when attached to blueprint code. For instance an artist prototypes when you want to count the specific choice made in a conversation tree. See the conversation popularity ranking in the game Dreamfall Chapters.

Another usecase is the typical steps of joining a matchmaking lobby, being matchmade and joining a server. Although this is can be done in C++, the widespread blueprint usage of Unreal Engine allows lesser skilled developer to do it. This gives a wider audience to the framework.

[justinliew]

I'd argue that the first case shouldn't touch anything Agones deals with, though. That sounds like something that would be sent via a REST call to a service.

The second point I agree might have some Blueprint hooks, although I would strongly urge the actual matchmaking state machine/stages be done in native (C++) code, as there are a ton of edge cases that Blueprints are error prone at handling.

[digitalfiz]

On the first note I think that is covered under the online subsystem as maybe user cloud, shared cloud or leaderboards?

On the second point matchmaking is built into the online subsystem so again not much more to do unless you wanted to extend what is possible over the built in matchmaking functionality.

https://docs.unrealengine.com/en-US/Programming/Online/Interfaces/Session

The more I think about it the key is going to be making sure that anything in the online subsystem Agones can handle is added to a plugin for Unreal Engine. I think that maybe even existing systems like AdvanceSessions can be layered on top of it to give extended functionality.

[justinliew]

Sounds good. I haven't worked with the sessions stuff as it appears it was done to plug holes in the lack of Steam support, which I never needed.

[iniside]

I don't think integrating with online Subsystem is good idea. At least for getting something working.

From what I understand Agones is more of server hosting and management in Kubernetes cluster.
And on that front having UE plugin would be awesome (I'd like to start working on it when I get my current projects in better state).

OnlineSubsystem interface is meant to provide abstraction over services like GameSparks, Playfab, Steam, or any other multiplayer backend where you have ie friends lists, sessions (matches) etc.

Agones integration in UE should first focus on communicating between Kubernetes cluster and UE server instance (ie, getting port and ip of server, health check etc).

Match making service (ie, sending needed IP and Port) would be out of scope, and unnecessary complicated at that point.
Ie if I use GameSparks I will use Agones only for launching/monitoring servers. Agones will never be directly exposed to players it will only communicate with GameSparks service, which will in turn send needed information to client to connect.

Creating OnlineSubsystem plugin would mean exposing Kubernetes cluster to world and I don't think it is needed and/or good idea for now.

[digitalfiz]

@iniside The more I understand about Agones the more I agree with you. When I first heard about it and started looking into it I thought it was going to be more than a Kubernetes wrapper but it looks like that is the goal. Keep things simple. Maybe there should be focus on integration with services like GameSparks, Playfab or Steam? Might even spawn off a project for doing what those services do but self managed like and works with Agones.

[iniside]

I have started working on basic plugin for Unreal Engine. No plans for any deep integration as of now, as it would require creating some backing services.

In current state plugin will only wrap around provided API. I'm currently wrapping code and will test the server over next few days on GKE. If it works I will upload full plugin to Github.

[iniside]

Ok. This proved to be far more difficult than I anticipated. The biggest problem lies in building grpc/protobuf and integrating it into Unreal.

I'm not that good myself with setting up build systems. Some basic issues that I fixed:

• 
  
  1. Conflicting time.h headers in protobud/grpc -> renamed.
  
  
• 
  
  1. Conflicting macro check -> renamed
  
  
• 
  
  1. MSVC Macros not resolving properly when building for linux target in Unreal -> Add additional macro in headers that caused issues.
  
  

That was the easy part.

The part is the fact that grpc brings along loads of other dependencies. Like libssl (which is incompatibilie the version already in Unreal).
Cooked builds miss some dynamic libraries like libgrpc++_unsecure.so.1, which is nowhere to be found nor does it build with agones.

Possible solutions to those issues is to build grpc (modified) along with Unreal from sources, instead of relying on precompiled libraries.

Other solution is to not use gRPC for communication, but I guess it is not an option.

[markmandel]

I'm starting to wonder if we prioritise the work to expose the sdk grpc endpoints as rest endpoints just to make engine integration easier - especially for anything C++ based.

@dzlier-gcp what do you think - that would make your life easier as well, no?

@Kuqd wdyt?

[iniside]

I will keep trying to integrate grpc into Unreal. But that's going to be custom fork, with some unreal specific fixes. I found interesting blog post:

https://adamrehn.com/articles/cross-platform-library-integration-in-unreal-engine-4/

Which might help with it.

Is there any reason that agones might not work with the latest version of GRPC ?

[markmandel]

In the past I've found grpc incredibly backward compatible, so it should work with the latest version.

At some point we should also upgrade just to keep up with updates.

[Clubbable]

Hi, I've reading about the Agones integration with Unreal, and I am a little confused as to the use cases for this. As I understand, Agones should talk exclusively to the custom matchmaker, and not to the game client or the game server. Since Unreal simply provides and game client/server, and does not act as a custom matchmaker (even though Online Subsystem provides matchmaking wrapper, it doesn't actually do the matchmaking), why would Unreal game client/server need to talk to Agones?

As mentioned before, I thought it would be more beneficial if the matchmakers like PlayFab or GameSparks would integrate with Agones to know when to spawn new servers.

As another sidenote, I am aware that PlayFab uses AWS and offers custom game server scaling already, I would imagine that is a similar services to Agones. I believe PlayFab's server scaling services uses AWS EC2 instances and charges a +10% fee on top of normal AWS server fees

[iniside]

Agones needs to be integrated with Unreal, so Kubernetes cluster know what is going on with server. Ie, if server do not ave players and game ended Kubernetes will automatically deallocate resources need for this server.

At basic level you don't need anything beyond game server, telling kubernetes what is it state.

You can theoretically extend it to provide other functionality (like saving/loading server state, but that's really case specific).

[g-ericso]

@iniside Have you success running unreal server with Agones? Sounds like it works for you.

[markmandel]

I changed the title, as people were thinking this ticket wasn't about getting Unreal working. Let me know if you have objections.

[iniside]

@g-ericso

Not yet. I'm still at the stage of integrating gRPC into unreal.

The upside is, I'm slowly getting it done. I decided the best course will be forking gRPC, protobuf and writing custom build-chain with Python.
Building it with Unreal Toolchain requries some unreal specific fixes. IF possible I will try to push patches upstream, once it is working.

Unreal is very picky about what can be linked to it, and default make files from gRPC were just not creating for that specific scenario.

[iniside]

Here is basic build of gRPC plugin for unreal
https://github.com/iniside/ue-grpc

Unreal<>Agones integration will be depending on this. I figured out you might want to use gRPC without Agones, and that's why it is in seprate plugin.

[g-ericso]

@iniside Thanks for the update. I will take a look this week and provide you some feedback.

[markmandel]

As a heads up, I'm working on the exposure of the SDK Server via HTTP+JSON right now, and should be ready by end of this week (next at the latest) - which should provide a _much_ easier option for building a native SDK for Unreal, since it looks like Unreal already can do HTTP+JSON natively, rather than trying to shoehorn gRPC into the mix.

See #240 for some more details.

[Clubbable]

One more question in regards to this issue, I've just tried to put up an UE4 server and orchestrate it via Agones, it is giving back status of "unhealthy" immediately. Is this because there's no communication between UE4 and kubernetes so that the game server can tell when it is spun up and healthy?

[markmandel]

Now that #240 is complete and in the development branch. This should be relatively easy to implement now. @g-ericso I know you are playing with this - let us know how your efforts are going :smile:

[g-ericso]

We will be testing the new feature this coming week. The idea is to make a c++ unreal simple .cpp and .h classes which will be shared in this repo. Stay tuned!

[g-ericso]

We made a c++ lib and connected successfully with localhost server. However, I don't have bandwidth to make a blueprint or UE library.

[YannickLange]

I just submitted a pull request for a UE4 plugin: https://github.com/GoogleCloudPlatform/agones/pull/647

The plugin doesn't require any programming. Just drop it in the Plugins directory of your project. I added some settings to the project settings (just search for agones). Currently, the plugin calls ready when the dedicated server world is ready, calls health pings and shutdown when the server shuts down.

Would love to hear your feedback.

[markmandel]

Closing, as now we have #647 !