Welcome to P4 of the project. Well last part we did the first parts of the Master Hub. The program was a moderate amount of complex work. Nothing to hard for anyone to handle, but well beyond just the easy clicking that C2 provides. This time however we have to take all the interaction load that the MH set up and now put that into the client for execution. By time we finish Part 4 DOL will be up for public testing. This is exciting. Although I’m starting this on March 27 I suspect this part will be done a few days later…. so much to do other than this.
Connecting to the Master Host
Last we left off with the client we got as far as logging into the server; and only with the basic login and not an account login; which will be coming.
First thing to do is we are going to connect to the Master Host. I left some structure for future instances, but for now we are going to cheat and just connect. I have the game name, instance name and the server room name. Drop that in begin the connect. Now every knows we are connected, but that doesn’t really matter much. Only the MH needs to know and now manage. Of course upon connecting to the room
On Enter Area( Msg.mEnterArea )
The Host will shoot off a message of where the player needs to spawn and will let everyone know. This happens by custom messages. Upon the local client getting the message the player will be sent to the area/layout. Though we want to store some data before hand so we know where to spawn in the layout.
Game play Interlude
We covered a lot of networking progress already. At this point much of what we are doing isn’t worth much if we don’t have a good foundation layer.
To start we are going to create 2 Objects and 1 Family.
- EnterPoint : This is a small sprite with a var Id that players can spawn at in the area.
- ExitBox : This is a sprite meant to be resized that will be part of a Family.
- InteractObject : This is a Family group that will be composed of many invisible(never rendered) sprites and a few visual ones as needed. This family will have many variables that will identify standard point and click elements. Here is a list of there names( Id, TouchAction, ArriveAction, RightClick, walkToPoint = -1, OnMouseOver, OnMouseExit, CursorFrame ). These are mostly self explanatory. These basic ones were a result of creating The Blue Code game. These came about from much pain, suffering and hacking. So we are just going to define them now.
As a sample of how this works. When there is a Touch(simulated mouse L.Click) immidiatly a Function will be called based on TouchAction. If we set a ExitBox to have the action “WalkTo”. The Event Code will call the function WalkTo and pass the UID of object to the function. If there are any “,” in the action the Touch even will also parse and pass those to up to 5 parameters deep. Of course if there is an ArriveAction then once the path finder arrived we will trigger an ArriveAction.
And I think that will cover that. You can fill out the rest of the theory yourself. Time to implement
Creating the Players
ah ha ah ha. Oh this is painful. Alright let’s start by moving into the layout. We take the message, tokenate 0, uppercase the string for the layout.
Upon entering the layout we create the player core object. This will be an invisible sprite attach to a family. The family has pathfinder on it for now. We then create our Spriter character and it to the playerEntity. The playerEntity has the pathfinder behaviour for now. The game uses point and click to move. So no need to sync the object.
Note: I went back to create a new structure for the MasterHost. Instead of running a singular host and having to re-doe a lot of work. I decided to do a system of managed host rooms. This is done by creating new game tabs running the host logic per room. I haven’t given up on the single host room, but I may restructure that down the road. The reason I am doing this current multi hosted room is to take advantage of the Join/Leave along with scalability of each room.
Joining
Now back to the game. During the game play the game has a Dictionary called player. This is a one instance object that the player uses. The object stores position, moveto location and will eventually include name, game stats and Spriter character maps. When another player joins the room(single or multi room host) the local player will send a message directly to the joining player. The message will be the dictionary. It is some what a heavy overhead of data, but the data is infrequent for this kind of game play. The other player receives the data and then builds and places the play correctly(cough most of the time). The benefit of using the plugins join/leave is that as a joining player that player will also get a trigger for every other player already in the room. So they will shoot of the same pack(best to have name, appearance, stats all loaded before the first room).
Moving Around
With all that out of the way. When the player clicks a valid spot they send a message to the host. The host get’s the message and will relay the Msg.mMoveTo(x,y) to the other players. Upon receiving the message they will SOL the playerEntity and do Pathfinding. Overall this was the easiest to get done. Along with moving though I build in a scaler to resize the player as they move about.
Traversing Rooms
When the player interacts with an object two primary actions occur. A Function is called based on a variable called TouchAction and the game will store an ArrivedAction. For our purpose the only object is our Exitboxes for travelling. When the player clicks the object a WalkTo function is called. The same function when clicking a standard moveable area. The patherfinder is called, the player moves and upon arrival the same function that solves the click will use the ArrivedAction string stored earlier. This will save the room to travel to, where to spawn and then leave the room. Upon leaving we have net work code earlier that checks to see if the player is to go to a room. Game will load the layout, join the room, create the player, rebuild the pathfinding obstacle map. And then good to go.