Postmortem

Although it’s quite an ambitious project to create a multiplayer game in a game jam, it didn’t go as horrible as one would think. Lets go through some bullet points on good and bad things.

During the gamejam, we used the open source game engine Godot Which lets you write scripts in their own scripting language, which you will realize, is similar to python.

For creating assets we used MagicaVoxel as it allows us to create simple OK looking 2D assets fairly quickly.

Multiplayer

From the previous gamejam we had some wishes on what we would like to try out in this game jam to learn more about, and multiplayer was high on the list.

I thought as along as we don’t need to synchronize information too often it will be fairly simple (and it actually was)

Sending private information to a player (+)

In godot, you are allowed to call on remote functions of connected clients as long as you know their (auto-generated) id. To collect the id of the players we simple opted for them needing to actively join the game after connecting via a simple rpc call to the server.

Client

func _join():
	rpc_id(1, "join")

Server

remote func join() -> void:
	var id = get_tree().get_rpc_sender_id()
	game.join(id)

As you can see the server code holds no logic about the actual game, only sending and receiving information. This somewhat follows a design pattern called MVC

After a player has sent their id we can now talk to them via the saved id. For example, updating them with their own private information when the state of the game has changed.

func broadcast_info():
	for player in game.get_players():
		rpc_id(player, "recieve_information", get_player_info(player))

func get_player_info(id) -> Dictionary:
	var player : Player = game.get_player(id)
	var planet_info = player.role.get_planet_information(game.current_planet)
	var ship_info = player.role.get_ship_information(game.ship)
	var resources = planet_info + ship_info
	var info : Dictionary = serializer.serialize_player(player)
	info["resources"] = resources
	return info

Sending non-private information to all players (+)

Although it’s not too complex to keep track of private information for players. Broadcasting public information is dead simple.

For example after a vote

    rpc("show_vote_result", result)

Missing automatic server discovery (-)

One thing we really wanted to do that did not get done was automatic server discovery. We found this forum post which seems to be promising if one would like to implement such a feature.

For now, even though it is a burden, manually entering the servers ip address is what we had.

Pipeline

The first few hours of the jam was used to set up an automatic pipeline to avoid spending time to manually re/submit any changes we did.

We managed this using drone and one of my servers.

Screenshot of deploying the project to itch.io with a simple click.

The version that was used in the end was a bit of a mess (as it combined the build and publish step into one massive step), so I won’t share it here. But if anyone is interested I will post a cleaner version on my GitHub in the upcoming week.

Shared project (+)

The real upside of using a game engine is the ability to cross-compile the project to different platforms. This made it super easy to share more complicated assets (think prefabs / scenes) between the client and server version. Re-implementing the map for the client version was a breeze as we could almost just copy the Map scene (prefab) from the server version and add some logic to what happens if you click the different plantes.

No tests (-)

Here is the real crux. We didn’t feel like this was the time or place to have integration tests verifying the build as one would if it was a serious project. This resulted in some extra scramble, especially for the android version, as it broke down on some syntax warnings as if they were errors and we had no ability to automatically catch this.