haxball / haxball-issues

114 stars 43 forks source link

[FR] Some server-client side feature requests #1890

Open swizzhax opened 1 year ago

swizzhax commented 1 year ago

Here is my list of features that would make coding/playing easier for both developers and players:

  1. Additional optional parameter to every event in headless host, which prints some info in the chat

    i.e.

    onGameStop(byPlayer : PlayerObject, log?: boolean) : void
    
    Event called when a game stops.

    As optional parameter, default behaviour would be to log info to the chat (true).

    We would have option to decide whether we want to log info or not - this might actually improve overall gameplay on some maps, that perform multiple actions during the gameplay. Chatlog example.

  2. Allow players to have custom disc color (set via serverside setPlayerDiscProperties - color) - if set, override team colors. Custom player disc colors

  3. Increase limit of map properties, it's set to 255 now, but some maps are highly customized and it would be much easier to set simple segments, instead of mixing segments with joints, etc.

  4. Add another property to maps, that would let people add background to the field, many maps achieve this by loads of segments placed next to eachother - but this causes higher cpu/fps drops due to tens of items rendered unnecessarily.

  5. Might be a little bit too fancy, but - would be really cool, if there was a possibility to have more teams than RED, SPEC and BLUE, some irregular maps would benefit from it.

    We could set custom teams by custom event i.e.

        setTeams(teams: TeamsObject) : void
    
        Event called when custom teams set.
        TeamsObject is an array of team objects i.e.:
       [
          {
             id: number - optional parameter
             name: string
             color: number or hex string
          }
       ]

I had more ideas, but since haxball was not developed anymore I gave up and I forgot most of it.

ghost commented 1 year ago
  1. Additional optional parameter to every event in headless host, which prints some info in the chat i.e.

    onGameStop(byPlayer : PlayerObject, log?: boolean) : void
    
    Event called when a game stops.

    As optional parameter, default behaviour would be to log info to the chat (true).

The example you gave makes no sense whatsoever. It would only work if the API inspected the default parameters' values of the callback function. Instead, it would be better if it worked just like the PlayerChat event, where if the returned value is false, it doesn't propagate the message. Returning a specific object would also be a decent alternative so the returned booleans could be reserved for a future use like canceling a PlayerJoin.

  1. Might be a little bit too fancy, but - would be really cool, if there was a possibility to have more teams than RED, SPEC and BLUE, some irregular maps would benefit from it.

Besides showing more teams on the main menu of the room, I don't see how virtual teams can't solve this issue.

swizzhax commented 1 year ago
  1. Additional optional parameter to every event in headless host, which prints some info in the chat i.e.

    onGameStop(byPlayer : PlayerObject, log?: boolean) : void
    
    Event called when a game stops.

    As optional parameter, default behaviour would be to log info to the chat (true).

The example you gave makes no sense whatsoever. It would only work if the API inspected the default parameters' values of the callback function. Instead, it would be better if it worked just like the PlayerChat event, where if the returned value is false, it doesn't propagate the message. Returning a specific object would also be a decent alternative so the returned booleans could be reserved for a future use like canceling a PlayerJoin.

It still does, as you mentioned - some functions already return a boolean value, that's why in my solution is isolated to avoid causing future problems if some updates will occur.

  1. Might be a little bit too fancy, but - would be really cool, if there was a possibility to have more teams than RED, SPEC and BLUE, some irregular maps would benefit from it.

Besides showing more teams on the main menu of the room, I don't see how virtual teams can't solve this issue.

I see your point, you can do everything virtually, but native functions are always better way do to something instead of creating own logic and double the job.

In this case scenario you could create maps with multiple teams with separated goals, as of now, you are forced to implement own logic to detect which virtual team actually scored a goal/point. Allowing more teams natively would make many things easier.

You can basically create any logic virtually, but that is not the point of this feature request.

Haxball was primarly created to be a football game, but nowadays there are tens of game modes that are somehow playable and highly demanded by community.