Monday, May 19, 2008

And the changes go on

There hasn't been much to show for the moment and for some reason. In order to progress on the GUI side it is much required to be able to know, who is present on the channel, so any object present in a zone needs to report it's there, so the CG was modified and now responds with the names of everyone present, this will now require an object database, where you can then look up what's what and who's who, so the client knows what to draw, most likely it will inquire each CC object to avoid DB lookup penalties. Once that is done, we can now proceed to create the SIM Object table on Apocalyx.

Also, another change was made to the CI routine, the one that compiles and installs new code on all connected servers, it now recognizes all Smash processes on all nodes and updates those processes that run old code, it does that by swiping the processes on all nodes and sending upgrade signals to the "old ones", just as a fail safe to make sure that all processes are ready for upgrade anytime. Updating the whole system in runtime has never been safer, remember that one of the goals is to update the system without ever shutting it down. And to all Erlang veterans: this is about a 1000x easier than using the OTP way, which requires a doctor degree to make upgrades happen. In this system just open a node for compiles, debug your code changes until no errors occur in the shell (or else running processes bomb out as per Erlang VM specs) and then type "ci()", which will distribute and upgrade all code on all nodes, now THAT is easy.

Cheers,

Sunweaver

Monday, May 12, 2008

Testing a BSP level

As stated before, the next updates will be somewhat slower because of the obvious learning curve to understand LUA & Apocalyx. Some work has been going on to create a login screen, which is still incomplete, but it's underway at least a first glance: the background comes from the gui.lua demo and is using the GLGooey for the dialog (so far). The background will change, the important things is to try that GUI out.

As I tried to adapt a city level BSP, I ran into some noob problems, but fortunately Leo (creator of Apocalyx) helped promptly to solve them [ Thanks again Leo ], so here is what the same soldier looks like in a city:


What you see here is Leo's city from Urban Tactics. The toon's position now gets transmitted automatically every 200 ms whenever the position is marked "dirty", meaning, that there was a change and the 200 ms is the minimum interval permitted by Smash, send more often and your client will be in trouble, because the sockets are blocked for 200 ms (to avoid flooding) on the server side.

Currently underway is making the login work and creating the table structure for all network created objects like other players, NPCs, cars, trees, grass, boxes and whatever comes to mind. I am thinking of make certain objects client persistent, so the server sends those persistent objects once specifying model, position, orientation, size, expiration and an object name and all the following times the client only checks those objects by expiration date and object name only, instead of downloading the full set of data again, once I get the object table in place that is.

Live long and prosper,

Sunweaver

Wednesday, May 7, 2008

A first peek at SMASH

A picture says more than a thousand words, so here it goes, this is the very first screenshot taken from the Smash Apocalyx Duo (should I call this SAD ??):

What you are seeing is a modified version of one of the basic model demos from Apocalyx with the console overlay displayed, where one can see the network information, in this case a successful logon, some positional data that the client sent and some other test clients who logged onto the server. Now we need to display other items, users and chat in this empty game world and a change on the framework (probably a whisper from each CG) to know who is on each zone channel, but we are getting there =) .

Laters,

Sunweaver

Monday, May 5, 2008

Still working on a first Apocalyx front-end

Well, Apocalyx LUA is tougher than envisoned, we are still trying to produce a first GUI, but just not ... yet. A couple more days I suppose. So far we merged the MD3 demo with the network demo and the mini applet connects to the server, authenticates and the soldier runs around in circles, you can send position data at the push of a button and that's it so far. We are still fighting with the camera, which just won't stick to the avatar, but well. What's clear is that we need somehow a channel manager that logs who is on each server channel, so newcomers can query for other objects in the gaming world or we need to expand the CG threads to report that info back per node, it would be less error prone if something fails. And also required now is a vocabulary check at the socket server level, to filter out what commands a user can utilize, remember that users should be able to do different things according to their profile and/or authorizations. Also maybe a filter should be implemented that allows only one command of a certain category, like movement, chat, whisper, change equipment and such, or users might wanna cheat sending several movement commands at once and move faster than allowed, so that needs to be taken care of.

So the next steps for the week to come are:
* Sending Apocalyx movement, orientation, char and chat data around a chat channel
* Chose a BSP scenario, not just a blank endless terrain, maybe Genoa or city.bsp
* Modify CG behavior to include a report on who is on that channel
* Command permissions per user level and/or specific user
* Filter multiple commands to avoid cheating (+fix a CC send bug)

And that's plenty for now.

Sunweaver

Saturday, May 3, 2008

The Load Balancer is ready for prime time

The Apocalyx frontend is not yet ready, I am still messing around with that and well it's not showing yet anything, but soon, very soon. BUT, the Load Balancer (LB) is ready to be integrated into SMASH. The LB will check for speed on each connected node and how many processes are running, then it calculates what that means in terms of availability for the cloud. This game is a zero sum game, but for the final evaluation, every single node will count, negative values are not permitted, then the total percentage is done. For the end user there are 2 procedures to be called, remote rpc (rrpc) and remote spawn (rspawn). rrpc will spawn a procedure remotely and wait max. for one sec for the result or rspawn will spawn a procedure remotely and return the PID, in case that the procedure takes longer or you need to spawn a server. Those 2 procedures should do for the generic cloud service. This might even mean a strong impact on the Simulation itself that will run on the framework, the initial idea was to run a zone one a single node, but with the LB there is really no need for any kind of restriction, you could run the Sim threads all over the place. Let's see what that does for the framework :) .

Cheers,

Sunweaver