Privateer

Members
  • Content Count

    1
  • Joined

  • Last visited

About Privateer

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I love it and thanks for showing what you did via GitHub! I'm teaching my kids programming by helping them to build a robot combat style game with Phaser. While they are learning the basics of Javascript I've been digging into Phaser and working on getting the client - server setup going. My kids were all worried about cheats/hacks (and rightly so) and I explained that most hacks are just client hacks (e.g. the user hacks their own client) and that they only work because the server does little or no sanity checking on actions that the clients take. To avoid these problems we are going to start with a client server model where clients make requests and the server validates everything and tells the clients what happened. The game play will be such that if we can get 3-4 ticks per second for 4-5 players we will be solid. The server: Game States: World Initialization, World Running, World Shutting Down Validates all in game client actions that could potentially be abused. Sends game state frame updates via socket io to clients that should know about them Saves the game state when the server goes down (if possible) Won't bother with tweens, particles, etc... just object states and collisions. The clients: Various Game States: Waiting to Connect, Loading, Waiting to Join, Entering Game, Robot War Mode, You Died, etc. Makes request to the server in response to player actions Reads responses from the server to update the players display via tweens No potentially game breaking action will take place on the client side. Doing things this way will let me introduce my kids to a few topics that I don't see talked about a lot: Client Trust Server / Client messaging and optimization Database storage of game states and objects Deciding where to make trade offs between potential hacks and performance We will be starting simple (in good part to show where performance issues are and what is needed to address them) and once we have things running we will then start worrying about how to improve performance. Anywise, thanks for the great thread. Lots of food for thought and some solid information that will likely save me a lot of headaches. Hopefully by the end of this coming weekend we will have a very simple client / server set up and within a couple of weeks have a basic online multi-player game running for them and their friends that includes robot combat, junk scavenging, inventory, energy management, repairs, etc.