Aaaaaand… It’s Gone.

So much for using ElectroServer to power the back-end for Portal Walker, or any game for that matter. Turns out that Electrotank, the company that created ElectroServer, was purchased by some lame casino game company that doesn’t appear to be interested in supporting ElectroServer or supplying new licenses for it. It’s a damn shame because it was by far my favorite server technology to work with.

With that behind me, I’m currently looking into using SmartFoxServer 2X, which has always been ElectroServer’s chief competitor. Pretty much the only reason I’ve never used SFS2X is because I was already familiar with ES5, fortunately it looks like SFS2X has some goodies and advantages that are making it a little less painful to make the switch. For one, the company that sells SFS2X is still in business, that’s a good start. They’ve also added some features specific to MMO-style games that look like they’ll be very helpful in creating the Portal Walker server. However, I’m still stuck where I was with ES5, as there is also no native Haxe client API for SFS2X, but the silver lining is that the AS3 client API for SFS2X is about half the size of the ElectroServer AS3 client API, which would hopefully translate into taking half the amount of work to port it to Haxe.

While I’ve been waiting to hear back from the internet about what I should do regarding the server situation, I started looking into procedural world generation for a 2D tilemap-based world and am getting ready to start working on the world generator for Portal Walker. Randomly generated worlds will be an important part of Portal Walker, but I want to note that the game world will not be entirely procedurally generated, so don’t expect something like Minecraft or Terraria. The only real news is that it looks like I’m going to have to write my own map generator from scratch. It looks like it will be fun, but I literally started to have a migraine while looking over info about Base64 encoding and zlib compression in preparation for how I plan on storing map data. Programming is very much so a headache sometimes.

Schoooooooool’s out… for… THE SUMMER!

I’ve had to put down working on games for the past few days to wrap up finals and the spring semester at school. After grinding through all of that, I think I’m going to spend the day relaxing and digging into a game I haven’t played before. You know, have a little fun.

On the Portal Walker front, the breaking news that no one is yet interested in is the fact that I am starting to have concerns about porting the ElectroServer 5 Client API to Haxe, the main concern being that I have no idea what I am doing. However, I still have made a lot of progress in drudging through the grunt work of porting the meat of the code from AS3 to Haxe syntax. I really could use some help from someone who understands the more complex functions of both languages and can look over the code and figure out solutions to port some of the trickier elements. I’ve begun dabbling with this myself (such as replacing AS3 Dictionaries with Haxe Maps, which I’m not even sure works or is a good idea), but the time I’m investing in it is starting to surpass the threshold of confidence I have in myself, so I’ve started the process of trying to get some help.

If it turns out that there is simply no feasible way for me to get a HaxeFlixel client interfacing with an ES5 server on all desired target platforms, my current backup plan is to use ES5 for the server and create the client in Starling and AS3. The huge downside would be losing access to the Flixel framework and having to code a lot of the client game engine from scratch, as well as a higher potential to run into performance issues down the road due to Starling apps running on top of Adobe AIR instead of compiling natively for each platform as they would if I were able to build the client in Haxe. First world problems, man.

ES5 as3 client API to Haxe porting madness!!!

So the main reason I’ve had to shelf working on the client is because I really don’t want to put a lot of work into it until it is interfacing with the server, primarily because the client is going to be receiving most of the information it needs about the game world from the server. On the projects I’ve worked on in the past, getting a client connected to the game server has been a snap when working with ElectroServer 5 and the ActionScript 3 client API library provided for it. Soon after setting up a fresh install of ES5 to begin creating a server for the Portal Walker client, it dawned on me that a Haxe client API library for ES5 doesn’t exist! Or, at the very least, I can’t find it.

After spending a brief moment looking into alternative server solutions, of which the closest I came to selecting was node.js, I decided the best course of action might be to roll up my sleeves and take a shot at porting the ES5 as3 client API to Haxe. Not only would this (theoretically) allow all of the various platforms I plan on targeting for Portal Walker to share the same netcode, if I am able to do this successfully I think it will have been one heck of a learning experience, not to mention something that can be of value to others.

I’ve been putting a lot of hours into porting all of the parts of the library that are essential for running a simple “Hello World” demo, and am pretty sure I have quite a long way to go until I get there. However, should I get a working demo going, I definitely plan to put my work up on GitHub to open it up to the community and the folks at Electrotank in the case that anyone else out there wants to work on it. I should probably have the first version of the complete library port finished by the time someone else becomes interested in taking a look at it, which would be pretty good timing considering I have very little faith in everything actually working by that point and will probably end up needing a hand. I never, ever, thought I’d be a contributor to an open source project, let alone be the creator and primary contributor, so I got that goin’ for me, which is nice.

Anyway, the People Powered Games coding stream has been EXTREMELY BORING since I started this porting project, which is an extraordinary thing to say about a stream where you already knew you were in for watching a guy sit there and type away at his keyboard. My process has been to run the as3 library though a useful tool called as3hx, which converts as3 scripts to Haxe scripts. Unfortunately, it’s a little rough around the edges and most files require quite a bit of fixing up before they resemble both working and human-readable Haxe code. Needless to say, combing file after file, line by line, to ensure that everything converted correctly has been a long and arduous task, and I’m not even close to having enough finished to test a demo of “Hello World”! I just hope that when I get there this actually works and I didn’t end up wasting a few days on something someone could have probably told me wouldn’t work if I had the gall to make a few forum posts. Sigh.