All posts by Jason Jarvis

DOL is kinda on hold due to me being super busy… for a year. However, I still like to tinker with some game prototypes and lay a foundation. So that’s when I sat down and started with a Smash Bros like system. Once again, I was struck with having to face developing a complicated input system again.

Previously I have developed a multi input system in C2. The system was meant to be ported to other projects. In the hopes to make multi input schemes easier. The system worked, but porting C2 projects into another is mentally painful.

At this point I have had enough of re-inventing C2 wheel. I stand by the belief that C2 should only have feature/plugins interact with each other. If a new feature is needed then develop the system with the C2 sdk. This has led to the development of XControl.

XControl was developed to handle multi input sources and create a Input to Action binding. This allows for a pool of players, and control inputs to filter down to the same set of Actions.

XControl is near completion and will be going into to beta shortly. This will likely be released on the C2 Asset store in a bundle with license to the plugin. If allowed to release as such.

Working the C2 SDK is not elegant. In fact I would say that the C2 engine was not designed for other developers. There is a lack of documentation and overall a lack of an SDK engine. Instead most of the work with C2 engine is through a small set of callbacks and properties. Often Scirra(Ashley) encourages that Plugins and behaviors have little interaction with others of similar type. Such as no Plugin to Plugin interaction and no Behavior to Plugin interaction. Also no Plugin to Behavior interaction, but Behavior to Plugin interaction is encouraged… whew.

however making anything advanced requires either an SDK or just plain ignoring all this direction. Developers such as RexRainbow and R0j0hound are two in the community that do so regularly. With a lack of documentation I have been repeating a simple code that logs the properties of an Object, but this is becoming tedious so I’m going to post the property names in this post. I’m also going to post a piece of code snippet that I use to grab another Plugin… not behavior.

Here is the snippet of code used to get the properties of an object.
console.log(“this from a [location]”);
for(name in this){ console.log(“property: ” + name ); }

WARNING:
The properties listed are from this and this.inst, however “this” may have a difference reference value.

C2 Get Plugin and the start of a C2 SDK

Put this in the top of the runtime.js, but under
assert2(cr, “cr namespace not created”);
assert2(cr.plugins_, “cr.plugins_ not created”);

// when using a function, we need to pass the memory instance
// in a js call function. so that the function assigns this as the right
// memory object
audioPlugin.acts.PlayByName.call(audioObject, 0, “foo”, 0, 1, “”);

Instance
Memory Runtime from
Plugin – this
Behavior – this.inst

This is from a WORLD only object. There are no positional, sizing or other such flags. So it’s surprising there is so much junk in the this. World seem that this is the level where behaviors would be attached. but there is reference to Tilemaps, even if tilemaps aren’t used. Sorry Ashley, but this seems poor design architect that everything including the kitchen sink get’s thrown in even when it’s not needed.

Examining the properties. This would look like a the prototype and not a run memory values… however it seems overall there is a lot of mixing. What really throws a strange wrench into this is that “this” when access from the initiator on Plugin.Proto.Instance a location where you create variables; this is not the same as the above Plugin memory run time.

DOL Quickies can be read easily out of order. They will often discuss performance or unique ways to handle problems. The first quickie discusses C2 Rotation Behaviour and it’s effect on performance. This is a small post. One of the major designs for DOL is run on mobiles. Including being playable on my A500(Tegra2) for now. I may not hold to this in the future. However one of the simple eye candy was a simple rotating background. For anyone who has tried the demo you will have seen this. Well this was achieved by a large sprite with the Rotation behaviour. And I am kinda surprised, but I shouldn’t have been. Doing trig mathematics is expensive, doing trig every tick hurts performance. We can just ignore this on PC. However weaker devices are another matter. We need to avoid trig or use trig only at required intervals. Rotation uses a lot of trig. So here are the tests on performance. Control where nothing is rotated, Rotation Behaviour(1angle/sec), EveryTick and TimerBehaviour. Control(Nothing): 60FPS, 10%CPU Rotation: 30FPS, 45%CPU EveryTick(0.033): 60FPS, 22%-30%(25) Timer(0.033): 60FPS, 22%-30%(25) Rotation calculates everytick doing trig mathematics. It’s too expensive. Best to avoid Rotation if you plan on hardware from -2012. Lesson. Don’t use Rotation Behaviour for mobile. It’s too expensive.

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.

Time to move on to the Master Hub. In DOL the players need a place to talk and handle their activities in an immersion style of play. Of course we can do this without any kind of world play environment, but this is a good opportunity to get players immersed. So we need a stable environment for players to gather. Having players who connect and disconnect constantly isn’t stable nor can players reliably conduct there character activities in such an unstable environment. So we are going to make a Master Hub.

The Master Hub is a single Scirra Room Host. Our MH will also handle players moving from location to location and open chat messages. This is kind of a pain; where more channels/rooms would have been helpful. However the investment for this structure is worth it. If the MH is overloaded with 200+ players then we can just open another MH and provide interconnection. So yay we get to do our simplified internal signalling service.

When considering our structure for MH let’s think.
Master HUB does not need graphics(no canvas render)
Master HUB should have logs(Text objects, no canvas render)
Master HUB needs to manage all players connected to it.
Master HUB needs to be it’s own CAPX(no assets)
Master HUB instance manager to mange more version of self

So what tools do we need
Multiplayer Plugin
Arrays to each location’s player list
Function because you should always structure around Funtions
Some images for locations… uh oh. I suck at graphics 🙁

Building the foundation of Master Hub
For starters there is only one layout. And when the layout starts we connect to the server. Upon connection to the server we see if a DOL HUB [x] is created. Failing that the Hub will create a room. This is incremental and will automatically have minimal scaling.

As a note spending more time with MP Plugin. I am finding that there are Instances of games. This could be very valuable. However there seems to be no Instance based functions. If it becomes possible to maintain room or player management through the Instance this could save time. However we will proceed with our current design of Master HUB.

Ok so what I have now is the MasterHub creating an instance for 100 players. I’ve stubbed the population instancing for now until more information comes out on instances. The MH now keeps logs of all activities. MH now acts as a stable game world. All pretty easy stuff really. On to the more fun stuff.

Area Enter
We could jump to having other players connect, but that would be the standard stuff. What makes DOL MH matter is the area management. So I’ve set up the the MH to create arrays for each area in the DOL HUB world.

For starters when a player connects nothing happens to the player. The MH has to place the player into an area and then the MH will inform the player the area he is in and a spawn point. At this time we will assume the player always joins the game world at the same location and stuff like that; why because we have no persistent data yet.

So what do we do. The MH will add the PeedID to the array and then tell the player where he is spawning. This is done my custom message. Before we start that we are going to create an Object to act as our tag list. that way we will reduce mistaken custom message tags. We want a layout object so that we can copy/paste the object between projects, but we don’t want anything to effect the Canvas. So we will use a DOM object. A text area called “Msg”. That way when we need to ID the tag we can just refer to Msg.mEnterArea. I am adding the prefix so when I need a quick tag reference for the aut-complete pressing ‘m’ will jump right there. Our message will just be the name of an object spawn sprite. That way we can move the sprite and the player will spawn where. To forward think the situation &refers to name, #xycoords. So we are going to go “lounge,&spawn”.

So here are first messages
Msg.mEnterArea : “[associate_layout_name],#&location”
message to client to enter an area

Msg.mGotoArea: “[area going to], [spot left at]”
message from client that they are leaving

Msg.mEnteredArea: “[peerId], [area], #&location”
message to client that some one entered the room

Msg.mLeftArea” [peerid], [spot left at] ”
message to clients in the area that some one left the room

Msg.mMoveTo: “[peerid], X,Y”
message to where pathfinder should move the player to

Msg.mChat
message of chat information

I also created a Function called Area.RelayMessage. This acts as the Multiplayer.Broadcast. However since we don’t want to send messages such as “EnteredArea” to everyone. We are using the arrays and such for lists to send messages to. Not as nice as would having a Multi Room listening or major game instance listener, but we work with what we have.

To cover how the next step works in DOLClient. The message will be parsed as a LAYOUT and Object/XY position. The full version will be more complex as needed… and probably more encoded.

There is a lot more to do. This is just the start of the MasterHub, but we want to get the ball rolling with interactivity. So we are moving on. This now covers Part 3. In Part 4 we will be working back on the Client. Last we left off was with joining the server, but not yet entered the room.

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.

Hey to all Constructors and others who may be interested in Construct 2. I .jayderyu am starting up a new blog to talk about C2 and my progress, hurdles and interesting tidbits regarding C2.

First let’s answer the question for those new to Construct 2. C2 is a brilliantly designed IDE toolkit that lowers the barrier to create games. When I say lowers the barriers I say it in a way that the barrier has never been lower.

C2 first and foremost goes the extra mile to reduce the traditional text based programming style. The majority of programming with C2 is done by selecting Conditions and Actions, and the selecting objects and options using the mouse. There are still times where the most simple text written code is required, but those are few and presented in an easy to understand way.

All of this provides one of the best introductions to programming. There are trade offs to all of this, but we will get to those as they come up.

I would like to welcome all C2 developers to my online shop. This shop provides access to unit based C2 CAPX goodies. I am currently working to provide non paypal confirmation downloads of free goodies.

Currently the site is still being put together. This process will be a little slow as I learn the software being used.