Stencyl (HaXe) Extension

@endel said in Stencyl (HaXe) Extension:

https://github.com/colyseus/haxe-ws

Endel you are a true Master!

C:\HaxeToolkit\haxe\lib>haxelib git haxe-ws https://github.com/colyseus/haxe-ws.git
Installing haxe-ws from https://github.com/colyseus/haxe-ws.git
Library haxe-ws current version is now git

C:\HaxeToolkit\haxe\lib>haxelib list
actuate: [1.8.9]
box2d: [1.2.3]
haxe-ws: [git]
haxelib: [3.3.0]
hxcpp: 3.2.94 [4.0.8]
layout: [1.2.1]
lime-samples: [7.0.0]
lime: 7.2.1 [7.5.0]
openfl-samples: [8.7.0]
openfl: 8.8.0 [8.9.1]

Now to build / test it again:

cd \HaxeToolkit\colyseus-hx\example\openfl
lime build windows
lime test windows

Error:

Can't find a secure source of random bytes. Reason: [file_open,\Device\KsecDD]

Debugging leads me to this part

trace("WebSocketGeneric.hx . initialize ... Before this.key 		");
        //this.key = Base64.encode(Crypto.getSecureRandomBytes(16)); // This generates the secure source of random bytes
		this.key = Base64.encode(haxe.io.Bytes.ofString("ABCDEFGHIJKLMNOP"));
trace("initialize key : "+this.key);

After this ofString-"16-bytes" the error was gone and hand-shake was made!!!

Windows and Android publication worked out of the box.

I will test iOS/Mac later this week!

Thanks for testing @mdotedot, that's nice. The problem is on getSecureRandomBytes method on Windows (unfortunately I don't have a Windows machine available for testing)

This method is used to generate the Sec-WebSocket-Key header for handshake. The error comes from this line. I've borrowed the implementation from here.

Would be great if you find a way to generate secure random bytes on Windows environment! Cheers!

The wikipedia linked in the sourcecode of Crypto.hx mentioned :
"but reading the special file \Device\KsecDD does not work as in UNIX"

So I tried another crypto number generator:

haxelib install trandom

Edit the project.xml to include this haxelib

notepad \HaxeToolkit\haxe\lib\haxe-ws\git\src\haxe\net\Crypto.hx
Change this:

	 #if windows

			var randomValue = trandom.TargetRandom.random();
			var bytes = haxe.io.Bytes.alloc(length);
		        bytes.setInt32(0, randomValue);
			return bytes;

                    var input = sys.io.File.read("\\Device\\KsecDD");

                #else

This worked when I did a lime build & test for windows.

When I tried to incorporate the trandom library into Stencyl it gave me problems. There is a define done that is going to add a build.xml file to the publication method and Stencyl does not handle that.

I opted for another approach for the windows build from in Stencyl:

		#if windows
					return  haxe.io.Bytes.ofString(getRandomString(16));
					// This will not work
                    var input = sys.io.File.read("\\Device\\KsecDD");

                #else

getRandomString:

public static function getRandomString(length:Int, ?charactersToUse = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"):String
	{
		var str = "";
		for (i in 0...length){
			str += charactersToUse.charAt( Math.floor((Math.random() *  (Date.now().getTime() % (charactersToUse.length) ) )));
		}
		return str;
	} //getRandomString

It is not as strong as the crypto generator but at least it works.

Confirmed v0.10 & Serjek Externs with Simple Stencyl Extension (Kind of like the NyanCat demo)

• HTML5
• Windows
• Android
• iOS Simulator
• iOS on device
• Macintosh OSX
• (Oracle) Linux

Awesome, thanks for sharing @mdotedot! I've just added your workaround for Windows into the haxe-ws fork: https://github.com/colyseus/haxe-ws/commit/eea2e57c53d8b2541475d66a9381e729f8f755d0

The past days I've worked on the Colyseus v0.10 framework and the Haxe externs from Serjek. As well as creating a docker that will run the server and will be supplied to the Stencyl Users so they can run the server on their own.

Since Endel has provided a haxe-ws fork ( https://github.com/colyseus/haxe-ws ) the system is really stable.

I've started with the core room-types:

• Lobby
• Raw
• Turn
• Lock

Lobby is where all players are signed in automatically. The playernames are stored and can be used in other rooms.

Raw Room is for games that don't need server logic. Think of games that are split screen and don't interact with eachother.

Turn Room is for turnbased games.

Lock system is where the server has a lock on coordinates/areas/objects and you request a lock to alter the data. Think of RPGs, puzzle games

In the future I want to have a Box2D Server collision interaction, but that will propably take a long time to figure out.

Currently a proof-of-concept has been made for the raw-room type. For the others I need to create more Stencyl blocks like request/release lock and turn (seat/next turn)

Here is the current Stencyl palette layout:

I've used client.getAvailableRooms

for (room in rooms) {
	if(room.metadata.ApplicationID == ""+colyseus.ApplicationID){
		roomIDs.push(""+room.roomId);
		roomNames.set(""+room.roomId,""+room.metadata.RoomName);
	}
}

I wonder if there can be a filter for things like this so that I don't get all the rooms and filter the applicationID out 'manually'
At least it works, but I don't know if it slows down when there are a lot of games running on the server?
Then again, I don't think that many stencyl-developers will run a server with different type of games.

With the core functionality done, the next room was much faster to create.

RoomType: Turn Based System

Proof Of Concept (sorry for the wall of text which is used to debug stuff)

This leads to these new blocks in Stencyl:

When a player leaves the system will pick the next seat as the active seat. If there is no seat after the leaving player the first available seat is selected.

Also, the seat that becomes availabe is added to a stack for next players to join to. (Of course when the Stencyl Developer decides to allow join/rejoining of active game!)

The Lock System is still a good challenge. After two code-refactors I have put it on hold for now.

Last week I've worked on an actual TurnBased system game (TicTacToe)

[running html5 and windows publication next to eachother]

(published for HTML5, Windows and Android; should work on the others)

During development I started to rethink my approach of a single extension versus multiple extensions.
I believe that a Stencyl user wants to create a specific type of game and install / enable the extension that is used for that type of game.
This make the palette a lot cleaner. (Unfortunately Stencyl Extension Developers don't have the means to create sub-palettes or tabs)

TODO for TurnBased System :

• set timeout value; when a player needs to react before certain time (auto-logout)

TODO for general :

• make roomtype specific extensions (raw, turn, physics, lock/logic) that have still the general purpose blocks (init, join, create, leave room, etc..)

TODO for games:

• Make another turnbased game (Poker?)

Also, I need to figure out the Lock/Logic room type eventually...

Working towards a beta release of the Colyseus Stencyl Extension.

I had already Lock, TurnBased and Raw room-types.

Most of the progress has been made with the Client-As-A-Server concept.
I know that the best way to handle multiplayer is on the server-side.
But many of the Stencyl users are not comfortable writing the server-side logic.

Therefore I attempted for a Client-Server-Relay kind of thing.
The collision and logic is handled on the client side with one of the clients acting as the server.
On that client the real physics objects are hidden and only the data that is send to all players is displayed.

These are the things that are currently made with the Client-As-A-Server approach:

Left Window is a Windows executable
Right Window is a web-page

I hope to do some more beta-testing with other Stencyl users to gain more information about this approach.

Since I want to join the Ludum Dare Jam 47 (2nd October) and make an on-line game we need to make resources public available.
Therefore I have made the Stencyl Extension available as a public beta : Stencyl Colyseus Extension Page

Last days I've worked on the documentation

And I worked on implementing a turn based card game.

Sending and receiving data is a breeze with Colyseus.

It all depends on the game-logic and how to show the state of the game.

I hope that the docker container that I provide to the Stencyl users will make running of the server easier for them.

As mentioned before I have made the extension based on the work of serjek (haxe externs) on top of the Colyseus engine.

The server has only three logic parts : Turn based and Locking mechanism and a check on active seat.
All other logic has to run on the client.

Of course most good server implementations need more logic on the server,
but I still am not certain how to provide the stencyl users with a relative easy way to make server-side code.

The best 'feel' you get is when you implement the Lock Room Type for your game. The room-data is kind of like a database server
that allows only one player to modify the data.

But, to be honest, most Stencyl users want to create physics based games. I provide examples how to run a client-as-a-server approach.
That seems to work since all clients see the same 'server'-state. But it is never as fast as it could be with server-side-physics.

I've attempted to create physics logic on the server based on the Box2D library.
The problems arise when doing client side prediction and server lag compensation. I wasn't able to get that to work. The data on the
clients 'jumped' all over the place. It works when you have minimal player interaction on the physics objects, but then the 'client-as-a-server' approach
is way easier to implement.

While preparing for the LD47 I revisted an old (LD38) project and converted it into a Client-As-A-Server game.

The left shows player control using the arrow keys and the right session you control the rock with the mouse.

The Extension Demo Page where you can play yourself is:
StencylColsyeusDemoPage