How does MineCloud work?

• When deploying the MineCloud stack:
  • Command registration lambda will register all the Discord commands
  • CloudFormation will setup all the resources needed, including a MineCloud system service, on the EC2 instance
• When entering commands in the Discord Channel:
  • The Discord server will invoke the Discord interaction endpoint lambda's function URL, the interaction endpoint lambda will validate the request with the Discord APP public key first, then invoke the Discord commands processing lambda asynchronously to process the Discord commands
  • The reason for having 2 separate lambdas is because Discord required a < 3 sec response time. And when there's a cold start, adding up with all the APIs invocation time, it's very easy to exceed the 3-sec limit.
  • The interaction endpoint lambda is very lightweight - we also increased its memory to 1024GB to further reduce the cold start time.
• The Discord commands processing lambda is the main lambda to interact with the EC2 instance:
  • After talking with the EC2 instance, the commands processing lambda will then update the Discord response using the response token.
  • The game server is packed and managed by the MineCloud system service
  • When receiving commands (ex: server backup commands), the EC2 instance will run the corresponding script and send back the result to the Discord channel using the Webhook provided.
• When there's no one online, the EC2 instance will shut down the MineCloud system service, check for backup and stop the EC2 instance.
  • By default, checking online player count is done by checking TCP connections on port 25565 (the "Minecraft way"). This logic can be easily modified by replacing the get_connection_count.sh script.
  • There's also a template script, get_connection_count_udp_template.sh, for UDP connections.