Derelict On-Line WIP Test

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.

Hey all Constructors. It is time for p2 of the DOL project. In this post I’m going to go over some of the preliminary elements to DOL and some theoretical target structure.

To start with I am using a personal CAPX “template” that I call GameFrameWork. For me this includes features such as

• GYFM Font loader
• DataTables with active data saving to WebStorage
• GUI Panels, Buttons with inspector based functions calls and settings
• Timer Object
• Camera Object
• Loader Screen
• Splash Screen
• Touch & Mouse Input

DOL project isn’t about covering the basics so we are not going to do that. We are going to the next step and moving into building the game and the networking.

Before starting let’s consider some structural elements to DOL. DOL structure and play will be similar to Phantasy Star On-Line. Players join groups to go adventuring, but player computers also rely on a dedicated server to maintain data authority over experience, equipment and such. Right now C2 Multiplayer Plugin only supports a single connection and one channel/room. So at the moment we have limited capability to start. Since there is no authority server right now we are going to start with open access to Scirra signalling server and in the future use Cla.io as our authentication server; unless Scirra changes to multiple connections.

For now we want to start by digging into the tasty new multi-player plugin and get the basics of communications started.

Starting Tools

• Array named as global(don’t pollute the namespace)
• Multi-player plugin…. yum yum
• EventSheet called “networking”
• TextBox for player alias
• Listbox for a ConnectionLog
• buttonGFX(GFW)
• SpriteFont for a label and a word over the login button
• + GameFrameWork(GFW)

First we are going to create a new Event Sheet called “networking” with the root Group Name called “Networking”. I add the TextBox (playerName), SpriteFont (calibri20), button and a 9Patch panel to break the white monotony all added to the MENU_PAGE layout. Visual polishing is a long way off and with that I make no claims at being a good artist (I’m not) or very good at aesthetics.
[I work heavily in OOP design for the purpose of cleaner code and general practice. I don’t like global scope variables and prefer to save those for the objects in the auto-complete. I also tend to name all my LAYOUTS IN UPPER-CASE and my event-sheets in lower-case. Just so it is easier for me to determine the difference of a LAYOUT and sheet on the tab list. ]

Client, Peer, Host, Master Host, Authority

In DOL we need to distinguish five different types of roles in the networking structure.

Client for our definition is any computer connected to centralized server for data. Most computers will be a Client in one form or another.

Peer for our definition is any one player’s computer that is connected to a server and interacts with the game world or other players.  Derelict Online Client will act as a Peer program.

Host is a Peer that handles the game logic of board play. Very much like a Peer. Derelict Online Client will also act as a Host program.
Master Host is yet another Client and connects like a Peer. The Master Host however does not have an active presence like the other players with an Avatar. The Master Host handles the special Room logic for interacting with the any one section of the HUB GameWorld. This will be different CAPX programs to cover the different types of activities.

Authority is the server that handles important information such as character storage and generation of items and randomiser for the board play.

As the game develops this definition will be used to keep track of communication and understanding of the current events. Including as to what caproj (DOL player client) and capx (Master Host, Authority) are being covered in the post or section of the post.

Connecting to the Server(DOL-PC)

Before we start you should know that Scirra has great tutorials(concept, chat, realtime) on the Multiplayer Plugin. I suggest reading them and examining both the sample templates.

For now we are going to assume that authentication login/password has passed and players can connect to the game world. So no need for passwords or such items at this time.

In ES-networking we are going to start with Signalling elements. With a standard “On LayoutStart”

Supports multiplayer
Let’s make sure we can support multi-player. If we can or can’t we will log our state in the ConnectionLog.addItem(“”).  If the platform cannot support WebRTC we will also disable the Networking group.

 On Error
It’s always best to be ready to handle errors. Last time I used the plugin I received a JS error; which is useless in C2. However it is still a thrown error exception and we should log what there is. Also we should log any unique or required activity that we use of the MP plugin so we know what the error relates to.

Start Connection
In my GFW I use OnTouch reference in my button sprite. I have a variable that stores a a string used for function calls. So when a Touch occurs on the object the Function is called. So I have a Function in my es-mainmenu called “menu.login”.  This is the default scirra server.  We are going to log this to keep what is happing updated.

 On Connected
This is the Multi-player plugin call back. This is called when the signalling server returns a successful connection. Either way if this succeeds or fails we will log the result. So we are adding a successful log.

For now we are going to hold our progress here. It’s a good spot because we need to choose which route in development we want to go. This is because everything above is the most basic design that is easily found in the tutorials.

• A. Prototyping. Connecting to other player hosts.  This will follow the same steps as the current templates and tutorials follow.
• B. Progressive. Connecting to a room with a Master Host. This will deviate from the already establish tutorials and start diving into more interesting areas.

Regardless the next update is going to take some time. I am going to be super busy for the next few days. Good development Constructors.

Hey all Constructors. Today I am introducing the Derelict On-line project. DOL is an on-line multi-player board game persistent role playing game. That’s going to need some explaining. Players play a character that grows over time in an on-line game. The on-line game’s main game play style is more in the style of a board game. Players flip cards, move around a board and change strategy based on the random events that occur.

This game is going to make use of the C2 Multiplayer Plugin and veryimportant is going to be mobile platform development. So from day one testing will be done actively on an Android device (iOS does not have WebRTC at this time). My Android device is an Acer A500 with a Tegra2 chip.

DOL will present players with a HUB set of gathering rooms to handle character orientated activities (shop, bank, customization). Players will also be able to enter chat areas and gathering locations to meet up with others to play on the game board world.

DOL game board play is at the heart of the game experience. However the presentation and other game interaction experience will be more like a Point and Click adventure.

The purpose of writing a Blog on DOL is important in two ways. On one side I want the community to see the development progress of a Construct2 on-line game. And the other is that active feedback is primary importance to the development of iterative game play design.

Now that the introduction is out of the way the caveat is that at this time I’m very busy. I have limited time and won’t be able to work on the project every day.

TL;DR

• Derelict On-Line(DOL) project
• Public exposure to feedback
• Multi-player on-line with C2 Multi-player plugin
• Mobile focus, but with desktop
• Updates when able