Vi skriver matchmaking för Dota 2014

Hej alla.

I våras snubblade jag över ett projekt där grabbarna hade lärt sig att starta en Dota 2-server av version 2014 och därmed spela på den. Jag är ett stort fan av detta spel och kunde inte motstå den unika möjligheten att återuppleva min barndom.

Jag dök djupt ner i det och det visade sig att jag skrev en Discord-bot som hanterar nästan all funktionalitet som inte stöds i den gamla versionen av spelet, nämligen matchmaking.
Innan alla nyheter med boten skapades lobbyn manuellt. Vi samlade in 10 reaktioner på meddelandet och skapade servern manuellt, eller hostade en lokal lobby.

Min programmerartemperament klarade inte av så mycket manuellt arbete, så jag skissade ihop den enklaste versionen av boten på en natt som automatiskt startade servern när 10 personer hade samlats.

Jag bestämde mig för att skriva i Node.js eftersom jag inte riktigt gillar Python, och jag känner mig mer bekväm i den miljön.

Detta är min första erfarenhet av att skriva en bot för Discord, men det visade sig vara väldigt enkelt. Den officiella npm-modulen discord.js erbjuder ett bekvämt gränssnitt för att arbeta med meddelanden, samla reaktioner osv.

Disklaimer: alla kodexempel är 'aktuella', dvs. de har genomgått flera iterationer av omskrivningar på nätterna.

Grunden för matchmaking är en 'kö' där spelare som vill spela placeras och tas bort när de tappar intresset eller hittar ett spel.

Så här ser entiteten 'spelare' ut. Från början var detta bara id:t av användaren i Discord, men planen är att ha en launcher/spel sökt från webbplatsen, men allt i tur och ordning.

export enum Realm {
  DISCORD,
  EXTERNAL,
}

export default class QueuePlayer {
  constructor(public readonly realm: Realm, public readonly id: string) {}

  public is(qp: QueuePlayer): boolean {
    return this.realm === qp.realm && this.id === qp.id;
  }

  static Discord(id: string) {
    return new QueuePlayer(Realm.DISCORD, id);
  }

  static External(id: string) {
    return new QueuePlayer(Realm.EXTERNAL, id);
  }
}

Här är gränssnittet för kön. Istället för 'spelare' används en abstraktion i form av en 'grupp'. För en enskild spelare består gruppen av honom eller henne, och för spelarna i en grupp, förstås, av alla spelare i gruppen.

export default interface IQueue extends EventEmitter {
  inQueue: QueuePlayer[]
  put(uid: Party): boolean;
  remove(uid: Party): boolean;
  removeAll(ids: Party[]): void;

  mode: MatchmakingMode
  roomSize: number;
  clear(): void
}

Jag bestämde mig för att använda händelser för att dela kontext. Det passade in i fallen — vid händelsen "spel för 10 personer hittat" kan man både skicka meddelandet till spelarna i privata meddelanden och genomföra den huvudsakliga affärslogiken — starta en uppgift för att kontrollera beredskap, förbereda lobbyn för start och så vidare.

För IOC använder jag InversifyJS. Jag har en trevlig erfarenhet av att arbeta med detta bibliotek. Snabbt och enkelt!

Vi har flera köer på servern — det har tillkommit lägen 1x1, vanlig/rankad, samt ett par custom-lägen. Därför finns det en singleton RoomService, som ligger mellan användaren och spellet.

constructor(
    @inject(GameServers) private gameServers: GameServers,
    @inject(MatchStatsService) private stats: MatchStatsService,
    @inject(PartyService) private partyService: PartyService
  ) {
    super();
    this.initQueue(MatchmakingMode.RANKED);
    this.initQueue(MatchmakingMode.UNRANKED);
    this.initQueue(MatchmakingMode.SOLOMID);
    this.initQueue(MatchmakingMode.DIRETIDE);
    this.initQueue(MatchmakingMode.GREEVILING);
    this.partyService.addListener(
      "party-update",
      (event: PartyUpdatedEvent) => {
        this.queues.forEach((q) => {
          if (has(q.queue, (t) => t.is(event.party))) {
            // om kön har denna grupp, lägg till gruppen igen
            this.leaveQueue(event.qp, q.mode)
            this.enterQueue(event.qp, q.mode)
          }
        });
      }
    );

    this.partyService.addListener(
      "party-removed",
      (event: PartyUpdatedEvent) => {
        this.queues.forEach((q) => {
          if (has(q.queue, (t) => t.is(event.party))) {
            // om kön har denna grupp, ta bort gruppen
            q.remove(event.party)
          }
        });
      }
    );
  }

(Kodsnutt för att visa hur processerna ser ut ungefär)

Här initierar jag kön för varje av de implementerade spelsätten, och lyssnar också på förändringar i "grupper" för att justera köerna och undvika vissa konflikter.

Så, jag är duktig, jag har klistrat in kodsnuttar som inte har något att göra med ämnet, och nu går vi vidare till matchmaking.

Låt oss betrakta fallet:

1) Användaren vill spela.

2) För att börja sökningen använder han Gateway=Discord, det vill säga han sätter en reaktion på meddelandet:

3) Denna gateway går till RoomService och säger "Användaren från Discord vill gå med i kön, läge: icke-rankad spel".

4) RoomService tar emot gatewayens begäran och lägger användaren i den rätta kön (eller snarare, användarens grupp).

5) Kön kontrollerar vid varje förändring om det finns tillräckligt med spelare för att spela. Om det är möjligt — emitterar vi en händelse:

private onRoomFound(players: Party[]) {
    this.emit("room-found", {
      players,
    });
  }

6) RoomService lyssnar uppenbarligen på varje kö med förväntan inför detta tillfälle. Vi får en lista över spelare, skapar ett virtuellt "rum" av dem, och självklart emitterar vi en händelse:

queue.addListener("room-found", (event: RoomFoundEvent) => {
      console.log(
        `Rum funnet läge: [${mode}]. Dags att få gratis rum för dessa killar`
      );
      const room = this.getFreeRoom(mode);
      room.fill(event.players);

      this.onRoomFormed(room);
    });

7) Här är vi vid den "högsta" instansen — klassen Bot. Generellt hanterar den kommunikationen mellan gateways (hur lustigt det ser ut på ryska kan jag inte förstå) och affärslogiken för matchmaking. Botten lyssnar på händelsen och beordrar DiscordGateway att skicka en kontroll till alla användare för att se om de är redo.

8) Om någon avböjer eller inte accepterar spelet inom 3 minuter, så återför vi INTE dem till kön. Alla andra återförs till kön, och vi väntar tills vi återigen har 10 personer. Om alla spelare accepterar spelet börjar den intressanta delen.

Konfiguration av dedikerad server

Vi hostar spel på VDS med Windows Server 2012. Av detta kan vi dra flera slutsatser:

1. Det finns ingen docker, vilket slog mig rakt i hjärtat.
2. Vi sparar på hyran.

Uppgiften är att köra en process på VDS från VPS med Linux. Jag skrev en enkel server på Flask. Ja, jag gillar inte Python, men vad ska man göra — att skriva denna server var snabbare och enklare på det språket.

Den utför 3 funktioner:

1. Starta servern med konfigurationen — val av karta, antal spelare för att starta spelet, och uppsättning av plugins. Jag kommer inte gå in på plugins just nu — det är en egen historia med liter av kaffe på nätterna, blandat med tårar och utdragna hår.
2. Stoppa/omstarta servern vid misslyckade anslutningar, som vi endast kan hantera manuellt.

Här är allt enkelt, kodexempel är knappt relevanta. Skriptet är på 100 rader.

Så snart 10 personer har samlats och accepterat spelet, är servern igång och alla är sugna på att spela, får de en länk till att ansluta till spelet i sina privata meddelanden.

När spelaren klickar på länken kopplas de till spelservern, och sedan är allting klart. Efter ungefär 25 minuter rensas det virtuella "rummet" med spelarna.

Jag ber om ursäkt på förhand för artikels oordning, jag har inte skrivit här på länge, och det finns för mycket kod för att lyfta fram viktiga delar. Koka ner det till nudlar.

Om jag ser intresse för ämnet kommer jag att göra en andra del – där kommer mina plågor med plugins för srcds (Source Dedicated Server) att finnas, och kanske även ett ranking-system och en mini-dotabuff, en webbplats för spelstatistik.

Några länkar:

1. Vår webbplats (statistik, leaderboard, en liten landningssida och klientnedladdning)
2. Discord-server

Källa: habr.com