Dynamic Environments

There hasn't been any update in almost 2 weeks, I know, and there won't be much to talk about at the moment. I am trying to find out how to create Dynamic Environments, sort of "SimCity"-like dynamic scenarios, where you create buildings and everything. Simple as it sounds, this is quite a challenge for the noob-Apocalyx'er like me, so you can imagine the fun I am having here. What I have in mind is something like this:

1) Changeable height maps (at some point), at first the world is going to be flat as a flounder.
2) The Wild West: People build houses, villages, mountains, valleys, farming, dynamic trees, etc.
3) Mega Cities: Think of living in a Mega City like in the movie "The Judge" or "Star Wars" cities like Nar Shaddaa (cf. Wikipedia links).

Once we have the ability to just drop building blocks onto each other we can then build in runtime really large scenarios, with very high buildings, several levels, etc. This sounds very appealing to me and will allow for a more dynamic game play. What it implies is to create a collision detection per object, bounding boxes and a physique simulator, all of which are included in Apocalyx, it's just a question of finding out "how". =O

And well, I have yet to finish the routine to add multiple object to the scene, that will enable the above functionality in the first place, much work ahead and so little time, but then it's better to do it right from the beginning, instead of fixing it later on.

Cheers,

Sunweaver

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

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

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

48 hours of endurance

Alright, not much to report for now, except for some minor changes on the Observer side, which did not catch all required objects. And the channel management requires a major overhaul, whisper commands currently trigger being subscribed to that channel, which isn't exactly desirable, meaning that we will require authorization management, ouch. That's a major CG (chat group controller) rewrite, but anyway.

And now to the 48 hours test: yes the server holds up. The caching Key Value Server (KVS) makes the whole thing fly and no messages pile up, things have never been so fast, it does not matter where a client connects to, the SMASH framework relays the messages blazingly fast to other nodes, so we know by now. This concludes stability and speed tests for the time being.

Leo, if you are reading this, I sure hope that Apocalyx permits me to create each 3D object as a table entry and not just as a variable, like your examples showing variables like avatar0 - avatar6 and so on. I will be needing to create a LUA table and put each avatar as one entry and then update that table. I guess once your new Gun Tactyx is out I might try to "socket" it and permit people to connect to a fighting event, we'll see, so now back to learning Apocalyx. And yes you should be able to see some kind of graph here soon, to reflect what we got so far.

Stay tuned,

Sunweaver
EDIT: I shortened the post.

SMASH to Planet Earth ... ??

While not finished by a long shot, we can now communicate between TCP/IP clients and the SMASH framework. The integration is not yet 100% complete, but one can now authenticate from any TCP client against the accounts table and create a chat client (CC: the player proxy). Any chat as of yet joins prefixed chat channels, this needs still a lot of work, like a channels DB, with authorizations to join, chat, listen, member list, password and so on, but at the very least you can now chat in 'general' and broadcast to any connected "player". This also works across nodes, so you can connect to different SOX servers that run on SMASH and even if the CC was created on a different node and still persists, as expected, the SOX thread correctly communicates with that CC, phew !!!

So, what's next ?? Now comes first of all a light test, after creating a scripted Delphi client, we will now do some tests over Apocalyx and create a VERY simple game world. After that there will be some very heavy work where we need to create a character selection / creation something and a channel table with all kinds of authorizations, cheers !!! This will be fun. And also upcoming then is a command parser, to enable the server to start validating stuff, because up to this point each client will decide positioning and capabilities, which is obviously not acceptable. During this step we will also have to implement a physique server, current thoughts are to put an Apocalyx client to do that, but to omit texture rendering and represent clients only as cubes (for line of sight), so we could verify very precisely physical conditions in the game without reinventing the wheel, but much lighter than a client side reproduction, let's see how that works out.


Stay tuned, a graphical test client is just around the corner.

Sunweaver

Welcome to the SMASH project

Hello reader.
This blog marks the beginning of a project that has the objective of producing a massive multiplayer online project written in Erlang. Actually the project started in 2005 with a lot of research, but not much code was produced until 2007.

Is it Vaporware ?
For all those in knowing whether this is real or not, be calm don't argue, it is vaporware ... until the day we publish code, so in the meanwhile, don't get anxious or annoyed.

When you say MMO, do you mean MO or MMO?
MO stands for multiplayer online game and the second M puts the massive into it. We classify hereby that any engine that only supports some 15-20 users as an MO and engines that can handle 1000+ users as MMO. Nowadays you see many announcements of people claiming to have built MMO engines, when truly they start to choke on 20+ connections. This is mostly due to a bad initial design because of a platform that cannot handle massive requests and also due to limits of a single server being used. The goal of the project is to produce an engine that can handle multiple servers and at least 1000+ users in real-time, being the limit basically only the throughput of a LAN and CPU power or the speed requirement of the application, so if a given application can live with less updates per second, thousands of users must be supported simultaneously. We don't want another toy, we want a serious MMO engine instead.

Why limit the project to 1000 users ?
This is not really meant as a limit, rather a minimum requirement and something achievable, but one thing for sure, if the Smash framework can handle 1000 its uses are unlimited, because in order to produce a 2000 user framework, you only would have to communicate 2 networks, so assuming that 1000 works, a million is easily within our grasp, too. The current tests have shown that the framework does not even choke on 50'000 test users, although sending out 50'000 messages takes some time, so 1000 really isn't a problem to accomplish and overshoot, but we need to set a target, so 1000 is the initial target, that's all.

Time frame
There is no specific time frame, which is why we classify ourselves as vaporware. The complexity of this endeavor is quite high, so trying to extrapolate a date is too difficult at this time.

Project components
Defining the development platform is vital, so Erlang is defined as the server platform and Apoxalyx for the GUI.

Why Erlang ?
* It runs on several OS like windows, Linux, BSD, MacOS and others.
* It is concurrent on the very heart, creating threads is easy and independent from the OS
* It's soft real-time, which is what we need
* One can share easily information across threads
* The Mnesia database replicates across the connected nodes
* You can update the application during normal operation
* It can be operate fault-tolerant
To mention a few advantages of Erlang, more on http://erlang.org.

Why Apocalyx ?
Because it is easy to use through LUA scripts, it's fast and it's pretty, more on http://apocalyx.sourceforge.net.

Why this blog ?
It sometimes helps to write stuff down as you go and often a loving comment of a reader/listener can help to improve things, so for now I will write here on progress and ideas and if there is something you want to contribute, please message me, note that flame posts or any unrelated posts will be deleted without question.

Bye bye,

Sunweaver