API requests

I plan on creating a boss npc for a new boss quest. Here's the list of things I require and couldn't find in the API or the boss battle quest script:

• Custom projectile patterns:
  The boss will spawn projectiles that follow specific patterns. It would be nice to be able to define a callback function or model that is shared on client and server, invoked per frame and returns or sets the current position of the projectile. If the game actually uses continuous collision detection, it could use the line between the previous and current position as input. It is also important for me to be able to pass values to the position logic such as the source and target keys, but if the model or callback definition is invoked per quest run, closures will suffice.
  
• Custom actor patterns:
  The boss will also use shields to protect himself from attacks and to hurt players on contact with the shields. I imagine them to be actors with the same logic as described above. I assume I would need to create a boss npc and set the position in the loop, but I cannot find any position setters in the boss battle quest.
  
• Optional: Sprite/Bounding Box orientation:
  It would also be nice to define the sprite orientation (rotation) per frame. And if possible, the same for the bounding box so that I can use a flat shield rather than a square shield.
  I've marked this item as optional because it can be worked around by just using round shields and square bounding boxes instead.
  

1- I've been thinking about Custom projectile patterns and I'm just not quite sure how to implement it. The main problem is that if the function is defined in the quest file, the client won't have access to it. This means the function would need to be defined in a shared file (ex: Bullet file) but that makes it not so convenient to use. Another more complex solution would be to still define it in the quest and once all the quest files have been generated, I create another file called BulletPattern by extracting the movement functions from them.

More major issue with complex bullet patterns is the possible desync between the client and the server. The client also doesn't have access to the same data than the server. Ex: A quest variable can't impact bullet movement.

2- Movement is an Actor attribute. You can use s.moveTo(key, map, letter, callback); or s.teleportTo(key, map, letter); or s.setAttr(key,'x',value);

3- Sprite can rotate on themselves. However, their bounding box used for attack and wall collision is fixed.

Note: I'd personally recommend making a simple boss before trying to make a complex boss that requires API changes.

That solves 2 and 3. Thanks.

As for 1, desyncing, I recommend a constantly synced time value (e.g. seconds since server start), which is a must have for any networked game. Anything that bases on that time value alone will then be as well synced as that value itself.
My concept of projectiles involves mostly circling around the player, signalling danger by shaking and then flying in a straight line directed towards the player at the time of releasing. It is implemented using only time and player position as input, which are both values that are synced properly, otherwise nothing of the game itself would be playable anyways.
The API definitely has to have networking functions which allow syncing of nonstandard values and events, which I won't need though because projectile spawning, elimination, phases, etc. are all handled by built-in syncing (if some aren't - I suspect phases might be serverside only at the moment - then I'll need that API, but the lack thereof can be worked around by respawning projectiles as different types).

rc wrote:but that makes it not so convenient to use.

Why? This is exactly how commercial games solve it. My suggestion is to make all quest scripts shared, masking serverside and clientside onlies with an if(isServer) or if(isClient). That's not a problem with projects that are open source anyways. Sensible serverside code can be hidden away in an if(isServer) include(x).

As for the note: Taken. I'll have some normal bosses, too. Then you'll have proof that what I'm planning is well within my ability.

By desync, I mean the difference between what the client sees and what's on the server. It's impossible to be entirely in sync because of latency. By the time the data reaches the client, the server state of the game has changed. Right now, this isn't a big issue because most of the bullet movement are independent of the game state (except collision with enemies but they move slowly and have such big hitbox that it's not a big problem).

Right now, the server doesn't send updates about the bullets. That would be a huge performance issue otherwise. It sends the initial data to the client and the client handles all the movement logic.

What data would you like to share between the client and the server in relation with a quest?

-------

I don't want to share the quest scripts with the client as it contains quest secrets and how to beat it. But like I said, I could make it so certain parts of it is shared (like bullet behaviour). The game isn't open-source anymore btw.

I was planning to have something like:
n.newBulletBehaviour(id:String,variable:Object,loop:Function);

Then it could be used like:
n.newAbility({...},{type:"bullet",...,behaviour:id});

rc wrote:What data would you like to share between the client and the server in relation with a quest?

Firstly, I need the bullet (and its loop) to know what the target and time of firing* is. So when the bullet spawning event is sent, the player key and time of firing needs to be sent as well. It can be achieved in the form of a custom initial parameter that is sent to the client with the only restriction that the value must be networkable. Alternatively these two parameters could be built-in.
Secondly, I would like to send events to the client. The only example is the boss changing phase with the consequence of a change in bullet behaviour for existing ones. In that case I send an event to the client with the time* the boss changed the phase and the phase the boss changed into. So what I need is pretty much a way to send a package of numbers or a built-in clientside boss change event. This can be worked around by simply despawning existing bullets and respawning them. But it would require keeping track of what bullets to respawn and would probably also be noticeable by the player.

* Serverside time. The reason I want synced time is because time can be continuously corrected, eliminating earlier bad latencies during good latencies. For example a one-time event could occur in bad latency, keeping that desync forever. But if the one-time event sends the time of the event, the current and any future time syncing will also sync the event consequences, requiring only that the consequences are programmed properly.

I'm assuming that I can obtain the player position attributes clientside using a player key.

Edit: As for the shield actors: I need the same data as the bullets. I will also need an event to change the target (lack thereof can be worked around by respawning, too).

rc wrote:n.newBulletBehaviour(id:String,variable:Object,loop:Function); [...] n.newAbility({...},{type:"bullet",...,behaviour:id});

They're looking good. What's the variable parameter for?

I'm not sure how sending the serverside time will sync the bullet if everything else isn't in sync.
If the bullet movement depends on the player position and the player position is not in sync, then there's no way the bullet can possibly be in sync. The desync impact highly depends on how complex the bullet behaviour is.

The problem with sending data to the client isn't actually sending it, it's handling the event related with the data. Even if I were to allow client side functions inside the quest file, there is currently no client side API. I'm not quite sure I want to get into that. I'd try to keep everything server side.

Here's an short example about a bullet behaviour.

Code:

n.newBulletBehaviour('wave',{amplitude:10,frequency:3},function(b){
   var axeX = b.timer;
   var axeY = b.amplitude * Tk.sin(b.timer * b.frequency);
   var numX = b.spd * (axeX * Tk.cos(b.creationAngle) - axeY * Tk.sin(b.creationAngle));
   var numY = b.spd * (axeX * Tk.sin(b.creationAngle) + axeY * Tk.cos(b.creationAngle));

   b.x = b.creationX + numX;
   b.y = b.creationY + numY;
});

Code:

n.newAbility('myAbility',{},{
   behaviour:n.newAbiltiy_behaviour('wave',{frequence:10,amplitude:1})
});

rc wrote:I'm not sure how sending the serverside time will sync the bullet if everything else isn't in sync.
If the bullet movement depends on the player position and the player position is not in sync, then there's no way the bullet can possibly be in sync. The desync impact highly depends on how complex the bullet behaviour is.

What matters is to minimize desync. If bullets lag and players lag, you'll have at worst double the lag. If you minimize even only one of them, the end result is better. You'll always want to minimize desync anywhere as individual desyncs do not sync with other desyncs, they may go opposite ways and only make it worse than singular desync.
Everything that is not based on external input, even RNG (share seed), can be made extremely resistant to latency. I know that you understand what I'm talking about but I think I've put it well when I answered Rin's question:

A more realistic example would be:
Actual latency: 95ms
Measured latency: 100ms
Actual latency during receiving {serverside time + 100ms}: 80ms
Time desync: 20ms
If you have decent time syncing, bullet complexity within non-external input aspects won't matter at all. The funny thing is that even putting in player position which is a consequence of external input won't make a difference because impact itself already bases on that value! Please note that this system (plypos desync + time desync) still has better worst case latency than the current one (plypos desync + bullet spawn desync).
With a trick, even player position latency can be made to appear as good as time syncing. It is basically logging of the player's path and then looking back where the player was one measured latency ago, effectively dramatically minimizing latency. It is called lag compensation and allows games like Team Fortress 2 to hit accurately even in the worst lag (it is even so effective that the unpredictability of lagging player movement is more distracting than not hitting pixel perfectly).

rc wrote:The problem with sending data to the client isn't actually sending it, it's handling the event related with the data. Even if I were to allow client side functions inside the quest file, there is currently no client side API. I'm not quite sure I want to get into that. I'd try to keep everything server side.

I hope you'll add at least a way to obtain positions based on actor keys including players though. They'll add another level of potential (chasing bullets, circling bullets, practically anything you can still expect from projectiles).

With the new attack engine, this request is no longer as useful as it used to. I'm locking this.