Dragon Basher: dragon basher server re-write readme.txt

Posted: 01‑30‑2018 21:54


Joe


Fire Flipper
1437 posts
This is the current readme.txt file for the 'dragon' server re-write that outlines my thoughts on how this can work and some simple flow charting and final thoughts.

I think these concepts are real break-through towards what I wanted my initial map-walker script to be, a way for anyone that wanted to write a multiplayer online game to be able to do so.

It is rather lengthy and a big part of it's existence is to help me organize my thoughts. A lot of this is theory stuff that I will update as I begin writing code. Here goes, spelling errors and all:

------------------------------------------------------------------------

#
# Land of the Dragon Basher
# Quintrix and Crew Software
#
# Released as Creative Commons BY-NC, where
# 'non-commercial' means games created cannot
# have money, coins, bank notes, credits, or
# any other economic system.
#
# See license.txtfor full credits.
# http://creativecommons.org/licenses/by-nc/2.0/
#


The Dragon Basher game engine ('dragon') will
consist of a JavaScript combination server-client,
where every player gets their own AJAX server
that they can build and other players can visit.

To achomplish this, there will be a Perl "middle-man"
script that will collect data from the servers
and transmit it to the clients. For this to work,
it will take exteremly optimized data packets.

The "world" should no longer scroll left-right, only
up and down. Then we don't need "map screens", we only
need the y-index. I'm thinking a world three maps
wide and seven maps long, thus each player has
twenty-one map screens to program as their server.

When you load the webpage and login, your "server"
becomes online. JavsScript on the page will start
sending data to Perl, which will send it to the other
players as they login. The Perl script is mostly just
a proxy, it will do nothing but transmit data, the
game is run on the JavaScript.

When a player logs in to your server, their client
will download an index of computer characters and
buildings, and a list of players on that server.
These indexes will be used by the "RenderObj" routine
to display those objects.

So say we use the item row of "X" to be the player
list, so now Xa is the display code for player "a",
and Xb is the display code for player "b". Now a
string "Xa####Xb####" will transmit the z-location
of both players. Or, using mono-spaced hex just
"########" would work as the client can know that
the first four character are player "a" and the
second four are player "b" (etc etc etc).

NPCs and buildings can be the same way, so now the
items Ya Yb Yc etc are programmed by the sysop to
be whatever NPC or computer character. So Ya=Player
House, Yb=King Que, Yc=Celeste, etc.

Each server can have twenty-six NPCs, twenty-six
buildings, and twenty-six players online at once.



So now instead of sending a long string for each
player's avatar, it is sent once and now the RenderObj
routine knows what avatar to display for player Xa. If
the player changes his avatar, the index gets updated.

At this stage, everything in-game can be displayed with
two variables: [z][code] ... using hex for the [z] requires
six characters per object and the server can transmit the
entire world in one string to the "Perl proxy" every, which
can then send it to the other players on demand (ie: player
is on [z] so we can easily send it only the data on his
viewer without any complex math or sorting).

This is exactly how Queville already sends the list
of dynamic items to the clients, it is highly effective.
Making NPCs and buildings work the same way would be a
huge optimization. And with an up-down world, everything
from start-z to end-z can easily be sent to the clients
without any sorting.

In this manner, the Perl script is never aware of any
"time stamps", all of that becomes work for the javascript
"server". The only time the Perl knows timestamps is when
the server state is "saved".





Flow Chart for JavaScript server-client:

Initial Login:
Load client, get name password
Create default server with island, pier, teleport, sign
Set 'server' to player's name
Start server-client
Start map-viewer

Start server-client:
Setup arrays for items
Download existing item, npc, building, tileset
Assigns player item to player's object
Start server-loop

Start server-loop:
Upload tileset every one-minute
Delete expired items
Send items to Perl
Recieve commands from Perl
Execute commands

Start map-viewer:
Render all objs from start-z to end-z
Wait for next tick, repeat

Capture input:
Move player?
Execute command?
Send chat?





v{xx}=[z][name] buildings (static, only downloaded at login)
w{xx}=[z][object] characters (static, only downloaded at login)
x{xx}=[z][object] players (dynamic, constantly updated)

note: client won't know name of "characters" until they
"talk to" them, menu option will be "Talk to Character"

note: client won't know name of "players", will need to
"Profile Player" to get name.

note: no need to transmit player codes (a-z), can just send
z-location reducing player data packet to four characters,
thus it only takes a 104 byte string to transmit the
location of all players to Perl every two seconds

note: need easy way to add and remove items from list so
there is no need to re-send same list of items every
two-seconds





Conclusions:

Using a Perl middle-man script allows the script to
use the memory of the player's computers to minimize
hosting costs. The server and client being written in
JavaScript will attract more programmers and game
developers to accelerate programming.

There may be some lag associated with this, lag
reducing stragegies such as smart clients with
predicitive moving will be required. Focus should
be on "simulation" type games where players have
something to watch change, not instant-result
type games.

The concept of running multiple JQurry calls at
once should be explored, it may be possible to
have AJAX "threads" created to handle each player
individually instead of having to process them
all at once.





DevTeam Member

 


Posted: 01‑31‑2018 08:14


Joe


Fire Flipper
1437 posts
My brain is coming up with ideas like crazy, trying to go through all of them - this one stands out a lot:
a combination server-client.

Using the Queville client, a "hidden iframe" can control the client operations like displaying maps and moving players.

And the JQuery technique could then be used to control the server operations (mostly keeping track of player and item locations). So each "client" becomes a "RAM drive" for the player to create their own server with (maps, characters, buildings, quests).



The other option would be to create a server.htm page to control the server operations, and a client.htm to control the client operations. This would have the advantage of servers being able to use web forms, but I think I prefer the server to be controlled in-game.



-Joe

DevTeam Member

 


Posted: 02‑06‑2018 19:18


Joe


Fire Flipper
1437 posts
I came up with this line of code:

var obj=objs.match(/.{1,5}/g);

It takes a string (objs) and turns it into an array (obj[]) with each object in the array being a five character chunk of data from the string. I refer to these five characters as the "z-item", meaning the z and the item code.

The first three are the z-location of the item in-game, and the last two are the two-character item code. Thus, everything in-game can be transmitted from the client-server to Perl in a single string of text, and from there to the other clients.

At the login (server creation) an index is setup where Idx["Xa"] is set to the object code for the RenderObj routine, this being "M#3" where # is the selected player head. Thus, the object code no longer needs to be transmitted with each two-second tick, only the five character z-item.

Idx["Xa"]="M23";

The main loop will now be able to cycle through this hash table with:

for (code in Idx) {
alert(code+" "+Idx[code]);
}

So when another player logs into the server, it will get item code Xb, then Xc, then Xd, etc etc etc. Twenty-six players per server.

Soon I should be able to login and walk around. :)

-Joe

DevTeam Member

 


Hunt food, smith weapons, and prepare for battle! Can you stop
the Evil Que from taking over the entire game? Browser based multi-player
fantasy role-playing game that requires no downloads or plug-ins! Free to play forever!

By being at queville.com, you agree to our Terms of Service.