The 3DGS Nerd » snippet

Code Snippet #2

Michael Schwarz — Thu, 05 Jun 2008 11:09:59 +0000

This is actually an old snippet, but hey it was completely commented in German before and with a slight outdated syntax. So here it is: My updated Multiplayer Chat script which I posted in the forums a few times.

It should have commented everything you need to understand the script and give you a little insight into Multiplayer Programming with 3DGS.

If you have any questions about this script. Don’t hesitate to ask!

I always like to start with definitions of the objects we need later in the script, so lets do this now:

font ChatFont = "Arial#12";
  
string STR_Received = "#100";
string STR_Sent = "#100";
string STR_Input = "#100";
  
string STR_ChatLine01 = "#100";
string STR_ChatLine02 = "#100";
string STR_ChatLine03 = "#100";
string STR_ChatLine04 = "#100";
string STR_ChatLine05 = "#100";
  
text TXT_ChatWindow // The "Chatwindow"
{
    strings = 5;
    string = STR_ChatLine01,STR_ChatLine02,STR_ChatLine03,STR_ChatLine04,STR_ChatLine05;
    pos_x = 10;
    pos_y = 10;
    font = ChatFont;
}
  
text TXT_ChatInput // The input line to type new messages
{
    string = STR_Input;
    pos_x = 10;
    pos_y = 100;
    font = ChatFont;
}
  
function chat_init() // Call this function in your MAIN FUNCTION
{
    TXT_ChatWindow.visible = on;
    TXT_ChatInput.visible = on;
}

Now, what do we have got here? Basically all you need for a simple chat. We have defined a font we will use, and as I like Arial quite much, I chose that one. Though it’s not relevant for the script to work properly, so just change it to anything you like.

Next up we have several strings all with a “#100” placeholder, basically, this fills the strings with 100 whitespaces, which is important as there is a bug in 3DGS which sets the max length of a string after the first assignment. So if we’d receive a message like “Hi!”, one of those strings would be further on limited to 3 chars, which is *not* very convenient for a chat.

Also we have the two text objects that will make it able to actually SEE the strings on screen. The first one is for the representation of the chat lines (the received messages) and the second one for the representation of the input line, which will serve us to write.

Also I have included the function that you will need to call to initialize your chat, in the most common case that would be your MAIN function.

Let’s take a look on the very first function with a purpose:

/*
As you can only send strings to the server as client,
we must send any chat message to the serve first
*/
function SendMsgToServer()
{
    // Prepare string
    str_cpy(STR_Sent, player_name); // First, we'll add the player name
    str_cat(STR_Sent, ": "); // then a :
    str_cat(STR_Sent, STR_Input); // and finally the message
    
    // Send string
    send_string(STR_Sent); // Now we send the string to the server
    
    wait(1); // Wait 1 frame for the message to be sent -- VERY IMPORTANT
    
    // Empty the strings to avoid duplication
    str_cpy(STR_Sent, "");
    str_cpy(STR_Input, "");
}

Easy I think, as everything is basically well explained in the comments. This function handles the sending of the chat-line from the client to the server when we send a message. Something as a sidenote as some people don’t understand where the player_name comes from: The string/variable player_name is a predefined value from the Acknex engine, it’s either defined by changing it directly using the “-pl” command line, or with an automatically given name at the start of the engine.

I’d like to add this very important fact at this point: It is VERY important to wait one frame where I indicated it as “VERY IMPORTANT” because if we don’t, the engine cannot send the string before we change it to empty again, or otherwise, if we want to receive it, the string is not filled before we try to read it. This is a very common mistake and produces most of the errors when writing multiplayer games in 3DGS.

Next up, a simple function to handle the input by the client:

function InputText()
{
    if(inkey_active){ return; } // If already active, RETURN!
    
    inkey(STR_Input); // Input focus on STR_Input
    
    if(result == 13) // If input is ended by ENTER
    {
        SendMsgToServer(); // Send message
    }
}
  
on_enter = InputText; // Bind Input function to enter key 

Should be self-explanatory which is why I won’t go any further on this.

Now we have a two-functions part, which might seem a bit ridiculous to you, as both functions seem to be very similar, but there is a small difference BEFORE emptying the received string. Just read the commentaries and you’ll understand it.

function ReceiveMessage() // Function when the client receives messages from the server
{
    wait(1); // wait one frame -- IMPORTANT
    
    /*
     To avoid that a server that has been started as "-sv -cl"
     gets the message twice, use ifndef server;
    */
    ifndef server;
        if(str_len(STR_Received) > 0) // If we received a valid chat message
        {
            // Reorder Chat
            str_cpy(STR_ChatLine01, STR_ChatLine02); // 2 > 1
            str_cpy(STR_ChatLine02, STR_ChatLine03); // 3 > 2
            str_cpy(STR_ChatLine03, STR_ChatLine04); // 4 > 3
            str_cpy(STR_ChatLine04, STR_ChatLine05); // 5 > 4
            str_cpy(STR_ChatLine05, STR_Received); // New message > 5
            
            wait(1); // Wait one frame -- IMPORTANT, as always
            
            str_cpy(STR_Received,""); // Empty the received string
        }
    endif; // Close the ifndef
    
    ifdef server;
        wait(1); // To avoid an empty function. 
    endif;
}
  
on_client = ReceiveMessage; // Bind ReceiveMessage function on the Client-Receive-Data event
  
function ReceiveMessage_Server() // The same function as above, but for the server and slightly changed
{
    wait(1); // wait 1 frame -- IMPORTANT
    
    if(str_len(STR_Sent)>0) // If we got a valid chat message
    {
        // Copy
        str_cpy(STR_Received,STR_Sent);
        
        // Order
        str_cpy(STR_ChatLine01, STR_ChatLine02); // 2 > 1
        str_cpy(STR_ChatLine02, STR_ChatLine03); // 3 > 2
        str_cpy(STR_ChatLine03, STR_ChatLine04); // 4 > 3
        str_cpy(STR_ChatLine04, STR_ChatLine05); // 5 > 4
        str_cpy(STR_ChatLine05, STR_Received); // New message > 5
        
        // IMPORTANT -- DON'T empty the message yet
        // Send it to all clients first!
        send_string(STR_Received);
        
        wait(1); // Wait 1 frame for the message to be sent -- IMPORTANT
        
        // Empty
        str_cpy(STR_Received,"");
        str_cpy(STR_Sent,"");
    }
}
  
on_server = ReceiveMessage_Server; // Bind ReceiveMessage_Server to the Server-Receive-Event

And guess what – That’s it. That’s ALL you need for a simple chat.

In case you are too lazy to type all of this off – which would make it way easier for you to learn – and just wanna mess around with it, here’s the complete download of this script:

chatscript.wdl (3.47 kb) Download!

Code Snippet #1

Michael Schwarz — Tue, 15 Apr 2008 13:35:09 +0000

Hereby I introduce the new code snippets section. Today serving you a Half-Life like movement script.

This script works different than most movement scripts, as it uses vec_accelerate instead directly passing the speed to the c_move parameters, thus creating a move natural movement.

More after the click:

First off we want to set a few constants, aswell as a few dynamic variables which we will later use in the script. Using defined constants makes it easier to read the script as it does make it easier to later modify a specific value without having to crawl through the whole script to find a specific value.

define true, 1;
define false, 0; 
  
define relSpeed_x,skill7;
define relSpeed_y,skill8;
define relSpeed_z,skill9;
define absSpeed_x,skill10;
define absSpeed_y,skill11;
define absSpeed_z,skill12;
define P_Speed,skill13;
define P_AngSpeed,skill14;
define P_Weight,skill15;
define P_Friction,skill16; 
  
var GLOB_BkgColor[3];
var PHY_Gravity[3];
var MOV_Playerspeed = 25;
var MOV_Turnspeed = 10;
var MOV_MaxUpAngle = 90;
var MOV_MaxDownAngle = -90;
var MOV_ShiftFactor = 1.35;

So, I use the opportunity to set up my standard defines for true and false, which I prefer to use over 1/0 or on/off respectively.

We store the player input in an imaginary vector called “relSpeed” in the skills of the entity, for the sake of being able to have a better accessibility for external events.

Global acceleration, like gravity, is passed by the absSpeed vector.

Then we have the values P_Speed, P_AngSpeed, P_Weight and P_Friction. P_Speed indicating the current speed the player is moving and P_AngSpeed indicating the speed the player is turning around.

Now we have some dynamic variables that are part of the movement system:

GLOB_BkgColor[3] : Actually just for defining the sky color.
PHY_Gravity[3] : We will define the values for this at game start. It’s as the name says the gravity.
MOV_Playerspeed : You will have to play with this value, as it defines how fast your player will move.
MOV_Turnspeed : You have to play with this value too. Defines the speed you will turn/look around.
MOV_MaxUpAngle : The maximal angle you can look upwards.
MOV_MaxDownAngle : The maximal angle you can look downwards.
MOV_ShiftFactor : The factor the MOV_Playerspeed gets multiplied by when holding the shift key. Use a value over 1.00 to accelerate the movement when pressing this key, or a value below 1.00 if you want the player to slow down when you press the shift key.

Now comes the main function for the whole thing, it is actually this function that does most of the difference to other movement codes:

function FNC_ApplyPhysics(ent, enablePoly)
{
    me = ent;
    vec_set(me.absSpeed_x, PHY_Gravity.x);
  
    while(me)
    {
        c_move(me, nullvector, me.absSpeed_x, IGNORE_SPRITES);
        c_move(me, me.relSpeed_x, nullvector, IGNORE_SPRITES|GLIDE);
        wait(1);
    }
}

As the commentary says, we use c_move twice here. One time for the absolute speed and one time for the relative speed. This is necessary as for the normal “movement” we need the GLIDE flag, or else we would become stuck in edges; and honestly you would actually not even move without it. Then we need the second c_move without the GLIDE flag because else you wouldn’t be able to walk up stairs or ledges.

And finally, the main movement code:

function FNC_MoveWASD(ent)
{
    // :: Assign ME pointer to entity.
    me = ent;
  
    // :: Main loop
    while(me)
    {
        // :: Rotate camera
        camera.pan += -((mouse_force.x * MOV_Turnspeed) * time_step);
  
        // :: Assign camera pan to entity pan
        me.pan = camera.pan;
        
        // :: Camera Tilting
        // : If Camera tilt is over or under maximal tilt angles
        if(camera.tilt > MOV_MaxUpAngle || camera.tilt < MOV_MaxDownAngle)
        {
            if(camera.tilt > MOV_MaxUpAngle)
            {
                // :: If it is over the maximal upper limit
                camera.tilt = int(camera.tilt - 2*time_step);
                // : Limit mouse movement
                if(mouse_force.y < 0){camera.tilt += ((mouse_force.y * MOV_Turnspeed) * time_step);}
            }
            else
            {
                // :: If it is over the maximal lower limit
                camera.tilt = int(camera.tilt + 2*time_step);
                // : Limit mouse movement
                if(mouse_force.y > 0){camera.tilt += ((mouse_force.y * MOV_Turnspeed) * time_step);}
            }
        }
        else
        {
            // :: Else
            // : Free tilting
            camera.tilt += ((mouse_force.y * MOV_Turnspeed) * time_step);
        }
        
        // :: If camera roll is not equal to 0°
        if(camera.roll != 0)
        {
            // :: And if camera roll is higher or equal to 180°
            if(camera.roll >= 180)
            {
                // : Roll clockwise
                camera.roll = int(camera.roll + 2*time_step);
            }
            else
            {
                // :: else
                // : roll counter-clockwise
                camera.roll = int(camera.roll - 2*time_step);
            }
        }
        
        vec_accelerate(my.relSpeed_x, my.P_Speed, vector(((key_w-key_s)*MOV_Playerspeed*(1+key_shift*MOV_ShiftFactor))*time_step, ((key_a-key_d)*MOV_Playerspeed*(1+key_shift*MOV_ShiftFactor))*time_step, me.relSpeed_z), 0.5);
        wait(1);
    }
}
  
function FNC_AttachCam(ent, z_offset)
{
    me = ent;
    vec_set(camera.x, vector(me.x, me.y, me.z));
    if(!key_ctrl){ camera.z += z_offset; }    
}
  
action ACT_Player
{
    player = me;
    FNC_ApplyPhysics(player, false);
    FNC_MoveWASD(player);
    
    camera.genius = player;
    
    while(1)
    {
        FNC_AttachCam(player, 35);
        wait(1);
    }
}

In the action ACT_Player you might want to change the second parameter of the FNC_AttachCam inside the while-loop, it defines the height of the camera from the origin of the player, so depending of the size of your player model this value can vary.

Inside your main function, you will also need to include the following BEFORE loading any level:

PHY_Gravity[0] = 0;
PHY_Gravity[1] = 0;
PHY_Gravity[2] = (-9.8); 
  
camera.arc = 75;
fps_max = 60;
fps_min = 35;
fps_lock = on;

This defines the Gravity. The value of (-9.8) should be adequate to the real earth gravity when using the Warlock/Cbabe/Guard model as reference. The FOV is set to 75, as it gives the whole thing a more natural feeling overall and we set an FPS lock so the movement doesn’t get jumpy or jerky whenever your FPS should rise or fall unexpectedly.

Now just attach the ACT_Player action to your player model in WED and have some Half-Life-Movement-Fun !

Stay tuned for the upcoming issue #2 of Code Snippets!