Jump to content

Monster Attacks Server-side


Recommended Posts

I am creating a top-down rpg character movement w/ combat. You click on a part of the map (in this case, it's a image, and your character .png image transitions to that spot). It's with Javascript and PHP. I'm using a PHP socket server. I have it where players can only move up to 200 pixels per each click. Each click is essentially a packet being sent to my gameserver. Then the gameserver validates if it's a valid input (1235x1235) format, and spits it out to other players in that specific game. (So it's a consistent world/map). This works perfect.


 If I want to incorporate a monster that has AI and starts to attack the character... I can do that with javascript easily with setInterval or setTimeout functions (to make the mob move and then attack the character). But how do I do that serverside with PHP simultaneously? Because a user could just press F12 and edit the javascript to stop the mob from attacking. But, I need the mob to attack the player every xxx milliseconds serverside as well. How can this done with PHP? I feel like I need some type of heartbeat going on where it's a constant check between client and server every xxx seconds? I might be going off on the deep end and I'll stop talking I hope you get the jist of it. Any ideas are greatly appreciated.


Another thought: Think of the popular aRPG games out there. Diablo 2, Diablo 3, Path of Exile, etc. Imagine using a hack that just stops mobs from moving towards your character and attacking it. Is that just an illusion? And the "auto attacking" is done serverside regardless if you've stopped that mob on the client, right? If so, how to accomplish this with a PHP socket server with some Javascript?  I'm not looking for code, just an application theory or design process would be awesome.


P.S. It's either I go this route, or the game becomes a simple real time strategy Pokemon style combat. Which I really, really don't want...


TLDR: How to have monsters auto attack your character (or in this case, update values in a temp variable, or a field name) server-side with some client-side JavaScript, and a php socket server. Securely on the server.

Edited by Dillybob
Link to comment
Share on other sites

You don't have to do anything yet server-side. Write your game in JavaScript and use events to have monsters spawn and auto-attack. Spawn monsters outside of the visible area, when the player moves close enough have the monster attack the player.


Yeah but someone can just simply disable that monster from attacking via F12 (Dev tools on Chrome)? (Or by clientside JS) I need some type of server ticker on PHP's websocket, is it possible? Similiar to setTimeout or setInterval functions. I can achieve this effect by doing this:

$echo_time = $users[$clientID]['last_session_request'];
$interval = 3;
while($echo_time + $interval >= time() ){
echo 'Looping...';
  if ($echo_time + $interval <= time()){
    echo "$interval seconds have passed... \n ";
    $echo_time = time(); // set up timestamp for next interval
  // other uninterrupted code goes here.


But, the 'echo Looping...' runs like mad and I think that sucks in a lot of CPU usage on my socket server, that isn't supposed to be used..  Hmm...
Edited by Dillybob
Link to comment
Share on other sites

No they can't stop it from attacking, only if you expose the function/variable that is responsible for this.


function Monster() {
  var attacking = true;
  this.printAttackingState = function() {
    alert('attacking = ' + (attacking ? 'true' : 'false'));

var monster = new Monster();
monster.attacking = false;
monster.printAttackingState(); // attacking = true
You can't change the attacking variable simply because it's not exposed. Edited by ignace
Link to comment
Share on other sites

  • 1 month later...

Game security...
Yes IMO it should virtually all be handled on the server. The concept is known as an Authoritative Game Server. In short, the client makes an input, this is sent to the server, the server processes the input, updates the scene data. Then the client app checks back for the result. In many cases the input is sent to the server, however the client app also processes the input and a result happens (e.g. character moves). Then the client will request the scene and test it against what it has, if what it has is wrong then it resets to the new server issued data. In reality the server doesn't care what the client see's, it just processes the input with the server side data (it also controls the enemy units too).


As for the server controlling the AI, in general it'll calculate that on the next update / input request, using elapsed time as a factor.



@ignace, a while back I tried to make a secure JS game, but no matter what I tried I could always access and insert into the JS of the page (dynamically loaded or not)

Edited by IThinkMyBrainHurts
Link to comment
Share on other sites

@ignace, a while back I tried to make a secure JS game, but no matter what I tried I could always access and insert into the JS of the page (dynamically loaded or not)

Then it was exposed and not encapsulated. But whatever, it does not matter, if I as a client can stop a monster from attacking as long as calls to the server (for example to award XP and such) are protected against malicious use, none of that matters.


I don't care if you can make your character a lvl 49 on your screen as long as it does not persist on the server, I don't care.

Link to comment
Share on other sites

This thread is more than a year old. Are you sure you have something important to add to it?

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.