Haxball Headless API Improvements

[mertushka]

@basro You need to improve the experience for Haxball Room Developers. What we can do and access on the Headless API is very limited, many features are still not available. The best example of this is that most of the developers are unaware of the existence of haxball.js and still use chromuim based models or directly the browser itself to host Haxball Rooms. We need to deprecate the Haxball's Headless Page and switch to an Official Haxball NodeJS API. People shouldn't have to use a heavily loaded browser for a simple Haxball Room. Another big problem is that we can only open 2 Haxball rooms per IP address. I don't know how you're going to solve this, but this is also one of the big problems that needs to be solved. However, we can discuss these things here all the long. If there are developers who think like me, they can write their own ideas here instead of opening a new issue for Headless improvements. This way we can use here as the main title for future Haxball Headless API updates.

Events

Many events can be still added to API.

Example: We should get the each player's keyPress event of each key pressed on the Headless API.

room.onPlayerKeyPress = function((player, keyCode) {
switch (keyCode) {
 case 67:
 // power shot
 break;

 case 68:
 // sprint, tackle etc..
 break;

 default:
 break;
}
})

in that way, different types of game mode can be implemented by developers easily.

Methods

The API methods still based on asynchronous functions. We should convert all of these to Promise-based functions. As you mentioned in https://github.com/haxball/haxball-issues/wiki/Headless-Host#api asynchronous is not a good idea for API functions that updates game state.

(This will close #1952)

Maps (Stadiums)

I don't know much issues about Maps, but what I do know improvements are: remove 200 disc limit & improve drawing techniques (shapes) & real time updatable maps (ex: player drawing something on the map by holding a key)

Custom Room Links (Vanity URL)

Haxball's room links are really worthless. People just copy it and send it to their friend and then they even forget what the link is. This update will be especially great for large Haxball Room communities.

Example:

HBInit({
vanityUrl: "mertushka",
...
})

https://haxball.com/play?id=mertushka

If headless tokens will be something like community specific, nobody can steal anyone's vanity url. I think this will also fix the 2 room limit per IP issue.

Summary

Thats all i can remember. You guys can write your ideas and I will add the missing ones to the issue.

@basro Maybe you should pin this issue.

[Nellty]

People shouldn't have to use a heavily loaded browser for a simple Haxball Room

True, but the current haxball.js is not ideal. My room app was crashing randomly, and some time later I've noticed by accident the "SIGSEGV" error in more deep logs. Then from this article I've found the problem was probably because of this module that is being used by haxball.js, and since I was using nodejs v16 I switched to nodejs v14 because it's listed here, and the problem was probably fixed after that, but you don't want this kind of problems appear after ditching the stable browserish method

[Nellty]

You need to improve the experience for Haxball Room Developers

The biggest problem that is not really a problem of Headless API is always would be its rawness or pureness or whatever you can call the thing where you can't do anything scalable without creating some plugins system before doing anything else. Like this guy did complete project that is complicated and good enough for players to be constantly interested in it, but can you see this? How can you understand what's going on there? How can you edit or improve this? How can you fix by yourself the bugs that this project is randomly spewing? And this is the most popular (and the only available?) template for the players if they're want easy to make their own not lifeless room

There are bunch of issues-questions here like how to do this and that, and what would be great is that if there are was some plugins system used by everyone, then it would be like:

- Hey, how do I make the bot to record the game replays into discord?
- Here is the `allGamesReplaysToDiscord` plugin

and the guy could somewhat easy make some bot from the ready-made plugins combinations

And there are already systems like that, but they are complicated to use: haxball-headless-manager, haxball-extended-room. The second one is decent though

Sadly, where the legacy is everything, I think you can't and maybe shouldn't to improve such core things

[basro]

Another big problem is that we can only open 2 Haxball rooms per IP address

This will be solved with special tokens that will be issued by me (and hopefully "token issuing staff"), these tokens will not expire and will always result in the same room ID being created. They can be revoked if they are used for spamming or other improper behavior.

Since the last update I've been working towards this feature but it will take a while longer to complete.

We need to deprecate the Haxball's Headless Page and switch to an Official Haxball NodeJS API.

This is in the plans but many other things are taking priority over it. I'll get there eventually. @Nellty brings to light some concerns regarding this, but I'll evaluate it once I get there.

We should get the each player's keyPress event of each key pressed on the Headless API.

Sending all of the player keyboard keypresses to the host is not a good idea, plus it'd not be confirgurable in the settings -> input menu. I'm not opposed to adding new configurable key bindings. For example add Action1 Action2 and send those keys to the host. This kind of update is blocked behind the feature of being able to update the game in a backwards compatible way.

[Wazarr94]

I'm not opposed to adding new configurable key bindings. For example add Action1 Action2 and send those keys to the host. This kind of update is blocked behind the feature of being able to update the game in a backwards compatible way.

What do you mean by this? Do you mean you'd have to update the number of arguments of the onPlayerActivity and it would break the hosted rooms?

If so, the easy solution would be to add a new method like onPlayerAction with the correct arguments and indicate that onPlayerActivity is deprecated in favor of this new method. I don't think there would be a backwards compatibility issue in this case.

[NiExTy]

We need to deprecate the Haxball's Headless Page

Please do not kill the Headless Page completley though. If you need Node that's fine, but existing projects might not. And porting is not always feasible for large projects.

[basro]

What do you mean by this? Do you mean you'd have to update the number of arguments of the onPlayerActivity and it would break the hosted rooms?

I mean it would be a change to the network protocol. The room scripts themselves would continue to work fine after they restart the room.

[basro]

Please do not kill the Headless Page completley though. If you need Node that's fine, but existing projects might not. And porting is not always feasible for large projects.

Deprecation wont mean that it's immediately going to get removed. Support will continue until it seems reasonable to remove it.

[mertushka]

My room app was crashing randomly, and some time later I've noticed by accident the "SIGSEGV" error in more deep logs.

@Nellty I think you stumbled upon the rarest possible bug. Because I have hosted Haxball Headless Room's for a long time with haxball.js and I have never encountered this error. Also, SLH Haxball Rooms (@Anooxy) are hosted with haxball.js & Node 16.x (I've been developing it for a while), I don't think they've encountered such a bug before. However, we will not ignore the existence of such an error, we will apply the necessary bug fixes if so. In fact, after a little research, i learnt the reason for the "SIGSEGV" error is might be related to WebRTC RTCPeerConnection's localDescription property and setLocalDescription method (See: https://github.com/node-webrtc/node-webrtc/issues/696).