Gem to improve multiplayer game prototypation times reducing boilerplate.

I strongly believe that Lumberyard will rule multiplayer game development and I feel that this feature can contribute to getting it closer and faster to this goal.

All we know that actually there is a lot of boilerplate to get a slice to spawn assigned and controlled by a specific client.Do something similar in other engines can be even more complicated, but Lumberyard to really make a difference should setup simple multiplayer sessions/matches with multiple remotely controlled entities as easy as it is to set up a single player game.

I would be great to have a gem that makes the process of setting up the various aspects of the multiplayer match in a data-driven way.What do you think?

It may work like the camera framework presenting you various a list of classes for any different aspect of the match, joining/leaving logic, match start with or without barricade, team management/balancing, spawn point management with rules about choosing the right spawn contextually, various behaviours to define what to spawn (e.g., the team versioned variation of a random slice picked from a list)

So that the user just needs to choose the proper class for every aspect and set the relative data for immediate results or even implement a new class for extended customization.Also, expect some empty classes that post events to an ebus you can connect to by script to let you implement custom behaviors directly in Lua.

Ideally, it will be based on a system component and a normal one to set things from the editor and change the chosen setup at runtime spawning it from dynamic slices.

The system one will let the state to survive level changes and so to maintain the player or game data across matches(e.s. the character and inventory chosen, previous stats)

Naturally, it needs to be able to work in single player too and even support the specification of ai controller slices to spawned with the controlled entity when in the editor or whenever it will be required.It may also be extended to additional local player controllers(for local multiplayer or just for testing purpose)

This twice as useful now that in Lua due to an ebus requiring a pointer to gridmate, that it’s not clear how to get from Lua, you cannot receive all the session events required to prototype something similar just by Lua (I don’t remember if I wrote a post about this issue when I got it at 1.10 release).


I think this is a fantastic and can really drive the multiplayer development through rapid iterations, especially when exploring design choices. Adding this to our feedback list — Thanks for this perspective @Gamely! :slight_smile:

@Community — what do you think?

Thanks to you for the indispensable support.It is a guarantee that ideas doesn’t get unheard.

Thanks…I’ll try soon

There is an undocumented feature of that EBus that requires IGridMate pointer that will solve your problem.

If you pass a nil in Lua in place for IGridMate pointer, then the default GridMate instance will be used and that will achieve exactly what you want!