Skapa ett flerspelart webspel i .io-genren

Utgiven 2015 Agar.io blev föregångaren till en ny genre av spel .io, vars popularitet har ökat kraftigt sedan dess. Jag har själv upplevt tillväxten av populariteten för .io-spel: under de senaste tre åren har jag skapat och sålt två spel inom denna genre..

Om du aldrig har hört talas om sådana spel tidigare: det är gratis multiplayer-webbspel som är lätta att delta i (utan konto krävs). De sätts vanligtvis på en arena med många motstridiga spelare. Andra kända spel inom .io-genren: Slither.io och Diep.io.

I det här inlägget ska vi undersöka hur vi från grunden skapar ett .io-spel. För detta behövs endast kunskaper i Javascript: du behöver förstå saker som syntaxen ES6, nyckelordet this och Promises. Även om du inte är fullärd i Javascript kommer du ändå kunna förstå det mesta av inlägget.

Exempel på ett .io-spel

För att hjälpa till med lärandet kommer vi att referera till exemplet på ett .io-spel. Försök att spela det!

Spelet är ganska enkelt: du styr ett fartyg på arenan där det finns andra spelare. Ditt fartyg skjuter automatiskt projektiler och du försöker träffa andra spelare, samtidigt som du undviker deras projektiler.

1. Översikt/struktur av projektet

Jag rekommenderar att ladda ner källkoden för exemplet på spelet så att du kan följa med mig.

Exemplet använder följande:

• Express — det mest populära webb-ramverket för Node.js som styr spelets webbserver.
• socket.io — ett websocket-bibliotek för att överföra data mellan webbläsaren och servern.
• Webpack — modulhanterare. Om varför man ska använda Webpack kan man läsa här.

Så här ser projektkatalogens struktur ut:

public/
    assets/
        ...
src/
    client/
        css/
            ...
        html/
            index.html
        index.js
        ...
    server/
        server.js
        ...
    shared/
        constants.js

public/

Allt i mappen public/ kommer att överföras statiskt av servern. I public/assets/ finns de bilder som vårt projekt använder.

src/

All källkod finns i mappen src/. Namnen client/ och server/ talas för sig själva, och shared/ innehåller en konstantfil som importeras både av klienten och servern.

2. Byggprocesser/parameter för projektet

Som nämnts ovan använder vi modulhanteraren för att bygga projektet. WebpackLåt oss ta en titt på vår Webpack-konfiguration:

webpack.common.js:

const path = require('path');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');

module.exports = {
  entry: {
    game: './src/client/index.js',
  },
  output: {
    filename: '[name].[contenthash].js',
    path: path.resolve(__dirname, 'dist'),
  },
  module: {
    rules: [
      {
        test: /.js$/,
        exclude: /node_modules/,
        use: {
          loader: "babel-loader",
          options: {
            presets: ['@babel/preset-env'],
          },
        },
      },
      {
        test: /.css$/,
        use: [
          {
            loader: MiniCssExtractPlugin.loader,
          },
          'css-loader',
        ],
      },
    ],
  },
  plugins: [
    new MiniCssExtractPlugin({
      filename: '[name].[contenthash].css',
    }),
    new HtmlWebpackPlugin({
      filename: 'index.html',
      template: 'src/client/html/index.html',
    }),
  ],
};

De viktigaste raderna här är:

• src/client/index.js — detta är klientens Javascript (JS) inträdespunkt. Webpack kommer att börja härifrån och rekursivt leta efter andra importerade filer.
• Utgående JS från vår Webpack-bygge kommer att finnas i katalogen dist/. Jag kommer att kalla denna fil vår JS-packe.
• Vi använder Babel, och specifikt konfigurationen @babel/preset-env för att transpila vår JS-kod för äldre webbläsare.
• Vi använder en plugin för att extrahera all CSS som refereras av JS-filer och för att sammanfoga dem på ett ställe. Jag kommer att kalla det vår CSS-packe.

Du kanske har lagt märke till de konstiga filnamnen för paketen '[name].[contenthash].ext'. De innehåller filnamnsplatshållare Webpack: [name] kommer att ersättas med namnet på inträdespunkten (i vårt fall är det game), och [contenthash] kommer att ersättas med hash av filens innehåll. Vi gör detta för att optimera projektet för caching — det gör att webbläsare kan cache-lagra våra JS-paket oändligt, eftersom om paketet ändras, ändras även filens namn (ändras contenthash). Det färdiga resultatet kommer att vara filnamn av typen game.dbeee76e91a97d0c7207.js.

Fil webpack.common.js — detta är basfilen för konfigurationen som vi importerar i utvecklings- och produktionskonfigurationen. Här är till exempel utvecklingskonfigurationen:

webpack.dev.js

const merge = require('webpack-merge');
const common = require('./webpack.common.js');

module.exports = merge(common, {
  mode: 'development',
});

För effektivitet använder vi i utvecklingsprocessen webpack.dev.js, och växlar till webpack.prod.js, för att optimera paketstorlekar vid utplacering till produktion.

Lokal installation

Jag rekommenderar att du installerar projektet på din lokala maskin, så att du kan följa stegen som anges i detta inlägg. Installation är enkel: först måste Node och NPMvara installerade. Efter det behöver du köra

$ git clone https://github.com/vzhou842/example-.io-game.git
$ cd example-.io-game
$ npm install

och du är redo att börja! För att starta utvecklingsservern räcker det med att köra

$ npm run develop

och gå till webbläsaren på localhost:3000. Utvecklingsservern kommer automatiskt att återskapa JS- och CSS-paketen under koden ändras — uppdatera bara sidan för att se alla ändringar!

3. Klientpunkter

Låt oss börja med själva spelkoden. Först behöver vi sidan index.html, när man besöker webbplatsen kommer den att laddas först. Vår sida kommer att vara ganska enkel:

index.html

<!DOCTYPE html>
<html>
<head>
  <title>Ett exempel på ett .io-spel</title>
  <link type="text/css" rel="stylesheet" href="/game.bundle.css">
</head>
<body>
  <canvas id="game-canvas"></canvas>
  <script async src="/game.bundle.js"></script>
  <div id="play-menu" class="hidden">
    <input type="text" id="username-input" placeholder="Användarnamn" />
    <button id="play-button">SPELA</button>
  </div>
</body>
</html>

Detta kodexempel är lite förenklat för att vara tydligt, och detsamma kommer jag att göra med många andra exempel i inlägget. Den kompletta koden kan alltid ses på Github.

Vi har:

• HTML5 Canvas-elementet (<canvas>), vilket vi kommer att använda för att rendera spelet.
• <link> för att lägga till vårt CSS-paket.
• <script> för att lägga till vårt Javascript-paket.
• Huvudmeny med användarnamn <input> och knappen «SPELA» ().

Efter att startsidan har laddats i webbläsaren kommer Javascript-koden att köras, med början från ingångs-JS-filen: src/client/index.js.

index.js

import { connect, play } from './networking';
import { startRendering, stopRendering } from './render';
import { startCapturingInput, stopCapturingInput } from './input';
import { downloadAssets } from './assets';
import { initState } from './state';
import { setLeaderboardHidden } from './leaderboard';

import './css/main.css';

const playMenu = document.getElementById('play-menu');
const playButton = document.getElementById('play-button');
const usernameInput = document.getElementById('username-input');

Promise.all([
  connect(),
  downloadAssets(),
]).then(() => {
  playMenu.classList.remove('hidden');
  usernameInput.focus();
  playButton.onclick = () => {
    // Spela!
    play(usernameInput.value);
    playMenu.classList.add('hidden');
    initState();
    startCapturingInput();
    startRendering();
    setLeaderboardHidden(false);
  };
});

Det kan verka komplicerat, men egentligen händer det inte så mycket här:

1. Importera flera andra JS-filer.
2. Importera CSS (så att Webpack vet att det ska inkludera dem i vårt CSS-paket).
3. Launch connect() för att etablera en anslutning till servern och starta downloadAssets() för att ladda ner bilder som behövs för att rendera spelet.
4. Efter att steg 3 är slutfört visas huvudmenyn (playMenu).
5. Ställa in en handlare för knappen «SPELA». När knappen trycks på, initierar koden spelet och meddelar servern att vi är redo att spela.

Huvudlogiken för vår klient-server-interaktion finns i de filer som importerades av filen index.js. Nu ska vi gå igenom dem i tur och ordning.

4. Klientdatautbyte

I detta spel använder vi ett välkänt bibliotek för att kommunicera med servern socket.io. Socket.io har inbyggt stöd WebSockets, som är väl lämpade för tvåvägskommunikation: vi kan skicka meddelanden till servern och och servern kan skicka meddelanden till oss via samma anslutning.

Vi kommer att ha en fil src/client/networking.js, som kommer att hantera all kommunikation med servern: import io from 'socket.io-client'; import { processGameUpdate } from '.\/state';const Constants = require('..\/shared\/constants');const socket = io(`ws:\/\/ ${window.location.host}`); const connectedPromise = new Promise(resolve => { socket.on('connect', () => { console.log('Ansluten till servern!'); resolve(); }); });export const connect = onGameOver => ( connectedPromise.then(() => { \/\/ Registrera callbacks socket.on(Constants.MSG_TYPES.GAME_UPDATE, processGameUpdate); socket.on(Constants.MSG_TYPES.GAME_OVER, onGameOver); }) );export const play = username => { socket.emit(Constants.MSG_TYPES.JOIN_GAME, username); };export const updateDirection = dir => { socket.emit(Constants.MSG_TYPES.INPUT, dir); };

networking.js

Den här koden är också något förkortad för tydlighet.

I denna fil sker tre huvudåtgärder:

Vi försöker ansluta till servern.

• connectedPromise upprättas först när vi har upprättat en anslutning. Om anslutningen är framgångsrik registrerar vi callback-funktioner (
• processGameUpdate()onGameOver() och ) för meddelanden som vi kan få från servern.Vi exporterar
• play() updateDirection() och , så att andra filer kan använda dem.5. Klientrendering

Det är dags att visa bilden på skärmen!

…men innan vi kan göra det måste vi ladda ner alla bilder (resurser) som behövs för detta. Låt oss skriva en resursförvaltare:

const ASSET_NAMES = ['ship.svg', 'bullet.svg'];const assets = {}; const downloadPromise = Promise.all(ASSET_NAMES.map(downloadAsset));function downloadAsset(assetName) { return new Promise(resolve => { const asset = new Image(); asset.onload = () => { console.log(`Nedladdad ${assetName}`); assets[assetName] = asset; resolve(); }; asset.src = `\/assets\/${assetName}`; }); }export const downloadAssets = () => downloadPromise; export const getAsset = assetName => assets[assetName];

assets.js

Att hantera resurser är inte så svårt! Huvudpoängen är att lagra ett objekt

assets , som kopplar nyckeln av filnamnet till värdet av objektet. När resursen har laddats ner sparar vi den i objektet Imageför snabb åtkomst i framtiden. När nedladdningen av varje enskild resurs är tillåten (det vill säga resurserna har laddats), tillåter vi , som kopplar nyckeln av filnamnet till värdet av objektet downloadPromise alla När resurserna har laddats ner kan vi börja rendera. Som nämnts tidigare använder vi HTML5 Canvas.

). Vårt spel är ganska enkelt, så vi behöver bara rita det följande: ... (<canvas>...

1. Bakgrund
2. Spelarens skepp
3. Andra spelare som är i spelet
4. Projicerade skott

Här är viktiga fragment src/client/render.js, som renderar just de fyra punkterna ovan:

render.js

import { getAsset } from './assets';
import { getCurrentState } from './state';

const Constants = require('../shared/constants');
const { PLAYER_RADIUS, PLAYER_MAX_HP, BULLET_RADIUS, MAP_SIZE } = Constants;

// Hämta grafikkontexten för canvasen
const canvas = document.getElementById('game-canvas');
const context = canvas.getContext('2d');

// Gör canvasen helskärms
canvas.width = window.innerWidth;
canvas.height = window.innerHeight;

function render() {
  const { me, others, bullets } = getCurrentState();
  if (!me) {
    return;
  }

  // Rita bakgrunden
  renderBackground(me.x, me.y);

  // Rita alla skott
  bullets.forEach(renderBullet.bind(null, me));

  // Rita alla spelare
  renderPlayer(me, me);
  others.forEach(renderPlayer.bind(null, me));
}

// ... Hjälpfunktioner här uteslutna

let renderInterval = null;
export function startRendering() {
  renderInterval = setInterval(render, 1000 / 60);
}
export function stopRendering() {
  clearInterval(renderInterval);
}

Denna kod har också förkortats för tydlighet.

render() är huvudfunktionen i denna fil. startRendering() och stopRendering() hanterar aktiveringen av renderingsloopen med en frekvens av 60 FPS.

Specifika implementationer av individuella hjälpfunktioner för rendering (t.ex. renderBullet()) är kanske inte så viktiga, men här är ett enkelt exempel:

render.js

function renderBullet(me, bullet) {
  const { x, y } = bullet;
  context.drawImage(
    getAsset('bullet.svg'),
    canvas.width / 2 + x - me.x - BULLET_RADIUS,
    canvas.height / 2 + y - me.y - BULLET_RADIUS,
    BULLET_RADIUS * 2,
    BULLET_RADIUS * 2,
  );
}

Observera att vi använder metoden getAsset(), som vi tidigare sett i asset.js!

Om du är intresserad av att utforska andra hjälpfunktioner för rendering, läs resten av src/client/render.js.

6. Klientinmatning

Det är dags att göra spelet spelbart! Kontrollschemat kommer att vara mycket enkelt: du kan använda musen (på datorn) eller beröra skärmen (på mobilen) för att ändra rörelseriktningen. För att genomföra detta kommer vi att registrera Event Listeners för mus- och touchhändelser.
Allt detta kommer att hanteras av src/client/input.js:

input.js

import { updateDirection } from './networking';

function onMouseInput(e) {
  handleInput(e.clientX, e.clientY);
}

function onTouchInput(e) {
  const touch = e.touches[0];
  handleInput(touch.clientX, touch.clientY);
}

function handleInput(x, y) {
  const dir = Math.atan2(x - window.innerWidth / 2, window.innerHeight / 2 - y);
  updateDirection(dir);
}

export function startCapturingInput() {
  window.addEventListener('mousemove', onMouseInput);
  window.addEventListener('touchmove', onTouchInput);
}

export function stopCapturingInput() {
  window.removeEventListener('mousemove', onMouseInput);
  window.removeEventListener('touchmove', onTouchInput);
}

onMouseInput() och onTouchInput() är Event Listeners som anropas , så att andra filer kan använda dem. (från networking.js) vid inmatningsevent (t.ex. vid musrörelse). , så att andra filer kan använda dem. hanter kommunicerar med servern som behandlar inmatningshändelsen och uppdaterar spelets tillstånd därefter.

7. Klientens tillstånd

Detta avsnitt är det mest utmanande i den första delen av inlägget. Bli inte nedslagen om du inte förstår det vid första genomläsningen! Du kan till och med hoppa över det och återkomma senare.

Den sista pusselbiten som behövs för att färdigställa klient-server-koden är state. Kommer du ihåg kodfragmentet från avsnittet "Rendering av klienten"?

render.js

import { getCurrentState } from './state';

function render() {
  const { me, others, bullets } = getCurrentState();

  // Gör rendering
  // ...
}

getCurrentState() måste kunna ge oss det aktuella spelets tillstånd på klienten vid varje given tidpunkt baserat på uppdateringar som tas emot från servern. Här är ett exempel på en speluppdatering som servern kan skicka:

{
  "t": 1555960373725,
  "me": {
    "x": 2213.8050880413657,
    "y": 1469.370893425012,
    "direction": 1.3082443894581433,
    "id": "AhzgAtklgo2FJvwWAADO",
    "hp": 100
  },
  "others": [],
  "bullets": [
    {
      "id": "RUJfJ8Y18n",
      "x": 2354.029197099604,
      "y": 1431.6848318262666
    },
    {
      "id": "ctg5rht5s",
      "x": 2260.546457727445,
      "y": 1456.8088728920968
    }
  ],
  "leaderboard": [
    {
      "username": "Player",
      "score": 3
    }
  ]
}

Varje speluppdatering innehåller fem identiska fält:

• t: serverns tidsstämpel som anger när denna uppdatering skapades.
• me: information om spelaren som tar emot denna uppdatering.
• others: en array med information om andra spelare som deltar i samma spel.
• bullets: en array med information om projektiler i spelet.
• leaderboard: aktuell information om poängtavlan. Vi kommer inte att beakta dem i detta inlägg.

7.1 Naivt klienttillstånd

Naiv implementering getCurrentState() kan bara direkt returnera data för den senaste mottagna speluppdateringen.

naive-state.js

let lastGameUpdate = null;

// Hantera en ny mottagen speluppdatering.
export function processGameUpdate(update) {
  lastGameUpdate = update;
}

export function getCurrentState() {
  return lastGameUpdate;
}

Snyggt och klart! Men om det bara vore så enkelt. En av anledningarna till att en sådan implementering är problematisk är: den begränsar renderingens bildfrekvens till serverns klockfrekvens.

Bildfrekvens (Frame Rate): antalet bilder (dvs. anrop render()) per sekund, eller FPS. I spel strävar man vanligtvis efter att nå minst 60 FPS.

Klockfrekvens (Tick Rate): frekvensen med vilken servern skickar speluppdateringar till klienterna. Den är ofta lägre än bildfrekvensen. I vårt spel fungerar servern med en takt på 30 ticks per sekund.

Om vi bara renderar den senaste uppdateringen av spelet kommer FPS i princip aldrig att kunna överträffa 30, eftersom vi aldrig får mer än 30 uppdateringar per sekund från servern.. Även om vi anropar render() 60 gånger per sekund, så kommer hälften av dessa anrop helt enkelt rendera samma innehåll och i princip inte göra något. Ett annat problem med den naive implementeringen är att den är utsatt för fördröjningar.Vid idealisk internethastighet kommer klienten att få speluppdateringen exakt var 33 ms (30 gånger per sekund):

Tyvärr är ingenting perfekt. En mer realistisk bild skulle vara:

Den naive implementeringen är praktiskt taget det sämsta fallet när det kommer till fördröjningar. Om speluppdateringen tas emot med en fördröjning på 50 ms, så försöker klienten 20 gånger längre, eftersom den fortfarande renderar spelstatus från den tidigare uppdateringen. Ni kan föreställa er hur obehagligt det är för spelaren: på grund av slumpmässiga fördröjningar kommer spelet att verka hackigt och instabilt.

7.2 Förbättrad klientsituation

Vi kommer att göra vissa förbättringar i den naive implementeringen. För det första använder vi renderingsfördröjning på 100 ms. Detta innebär att klientens 'aktuella' tillstånd alltid kommer att vara 100 ms efter serverns speltillstånd. Till exempel, om serverns tid är 150, så kommer klienten att rendera ett tillstånd där servern var vid 50:

Detta ger oss en buffert på 100 ms, vilket tillåter oss att hantera oförutsägbara väntetider för speluppdateringar:

Priset för detta kommer att vara en konstant inmatningsfördröjning på 100 ms. Detta är en obetydlig uppoffring för en smidig spelupplevelse — de flesta spelare (särskilt casuals) kommer knappt att märka denna fördröjning. Det är mycket lättare för människor att anpassa sig till en konstant fördröjning på 100 ms än att spela med oförutsägbara fördröjningar.

Vi kan också använda en annan teknik som kallas "klient-side prognostisering", som hanterar att minska upplevda fördröjningar bra, men detta kommer inte att behandlas i detta inlägg.

En annan förbättring som vi använder är linjär interpolering.På grund av renderingsfördröjningen ligger vi vanligtvis minst en uppdatering före den aktuella tiden på klienten. När vi anropar getCurrentState(), kan vi utföra linjär interpolering. mellan speluppdateringar direkt före och efter den aktuella tiden i klienten:

Detta löser problemet med bildfrekvens: nu kan vi rendera unika bilder med vilken frekvens vi behöver!

7.3 Implementation av förbättrat klienttillstånd

Exempel på implementation i src/client/state.js använder både renderingsfördröjning och linjär interpolation, men det är övergående. Låt oss dela upp koden i två delar. Här är den första:

state.js, del 1

const RENDER_DELAY = 100;

const gameUpdates = [];
let gameStart = 0;
let firstServerTimestamp = 0;

export function initState() {
  gameStart = 0;
  firstServerTimestamp = 0;
}

export function processGameUpdate(update) {
  if (!firstServerTimestamp) {
    firstServerTimestamp = update.t;
    gameStart = Date.now();
  }
  gameUpdates.push(update);

  // Behåll endast en speluppdatering före den aktuella server tiden
  const base = getBaseUpdate();
  if (base > 0) {
    gameUpdates.splice(0, base);
  }
}

function currentServerTime() {
  return firstServerTimestamp + (Date.now() - gameStart) - RENDER_DELAY;
}

// Returnerar indexet för basuppdateringen, den första speluppdateringen före
// aktuell server tid, eller -1 om N/A.
function getBaseUpdate() {
  const serverTime = currentServerTime();
  for (let i = gameUpdates.length - 1; i >= 0; i--) {
    if (gameUpdates[i].t <= serverTime) {
      return i;
    }
  }
  return -1;
}

Först måste vi förstå vad currentServerTime()gör. Som vi såg tidigare inkluderar varje speluppdatering serverns tidsstämpel. Vi vill använda renderingsfördröjning för att rendera bilden, med 100 ms fördröjning från servern, men vi kommer aldrig få veta vad den aktuella tiden på servern är, eftersom vi inte kan veta hur länge det har tagit för oss att ta emot någon av uppdateringarna. Internet är oförutsägbart och dess hastighet kan variera kraftigt!

För att komma runt detta problem kan vi använda en rimlig approximation: vi låtsas att den första uppdateringen kom omedelbart. Om det var sant skulle vi veta serverns tid vid det specifika tillfället! Vi sparar serverns tidsstämpel i firstServerTimestamp och sparar vår lokala (klient) tidsstämpel vid samma ögonblick i gameStart.

Oj, vänta nu. Borde inte serverns tid = klientens tid? Varför skiljer vi på "serverns tidsstämpel" och "klientens tidsstämpel"? Det är en bra fråga! Det visar sig att det inte är samma sak. Date.now() kommer att återvända olika tidsstämplar i klienten och servern och detta beror på lokala faktorer för dessa maskiner. Anta aldrig att tidsstämplarna kommer att vara lika på alla maskiner.

Nu förstår vi vad currentServerTime()gör: den returnerar serverns tidsstämpel för aktuell renderingstid. Med andra ord är detta serverns aktuella tid (firstServerTimestamp < + (Date.now() - gameStart)) minus renderingsförseningen (RENDER_DELAY).

Låt oss nu titta på hur vi hanterar speluppdateringar. När en uppdatering tas emot från servern anropas onGameOver(), och vi sparar den nya uppdateringen i arrayen gameUpdates. För att kontrollera minnesanvändningen tar vi bort alla gamla uppdateringar till basuppdateringen, eftersom vi inte längre behöver dem.

Vad är då en "basuppdatering"? Det är den första uppdateringen som vi hittar när vi rör oss bakåt från serverns aktuella tid. Kommer ni ihåg detta schema?

Speluppdateringen direkt till vänster om "Client Render Time" är basuppdateringen.

Vad används basuppdateringen till? Varför kan vi överge uppdateringar fram till basuppdateringen? För att förstå detta, låt oss äntligen titta på implementationen getCurrentState():

state.js, del 2

export function getCurrentState() {
  if (!firstServerTimestamp) {
    return {};
  }

  const base = getBaseUpdate();
  const serverTime = currentServerTime();

  // If base is the most recent update we have, use its state.
  // Else, interpolate between its state and the state of (base + 1).
  if (base < 0) {
    return gameUpdates[gameUpdates.length - 1];
  } else if (base === gameUpdates.length - 1) {
    return gameUpdates[base];
  } else {
    const baseUpdate = gameUpdates[base];
    const next = gameUpdates[base + 1];
    const r = (serverTime - baseUpdate.t) / (next.t - baseUpdate.t);
    return {
      me: interpolateObject(baseUpdate.me, next.me, r),
      others: interpolateObjectArray(baseUpdate.others, next.others, r),
      bullets: interpolateObjectArray(baseUpdate.bullets, next.bullets, r),
    };
  }
}

Vi hanterar tre fall:

1. base < 0 betyder att det inte finns några uppdateringar före den aktuella renderingtiden (se ovanstående implementation av getBaseUpdate()). Detta kan hända i början av spelet på grund av renderingsfördröjning. I så fall använder vi den senaste mottagna uppdateringen.
2. base är den senaste uppdateringen vi har. Detta kan inträffa på grund av nätverksfördröjning eller dålig internetuppkoppling. I det fallet använder vi också den senaste uppdateringen vi har.
3. Vi har uppdateringar både före och efter den aktuella renderingtiden, så vi kan interpolera!

Allt som återstår i state.js är implementationen av linjär interpolation, som består av enkel (men tråkig) matematik. Om du vill studera den själv kan du öppna state.js till Github.

Del 2. Backend-server

I den här delen kommer vi att titta på backend Node.js som hanterar vårt exempel på spel .io.

1. Ingångspunkt för servern

För att hantera webbservern kommer vi att använda det populära webbramverket för Node.js som heter Express. Dess inställning kommer att hanteras av vår ingångspunkt för servern src/server/server.js:

server.js, del 1

const express = require('express');
const webpack = require('webpack');
const webpackDevMiddleware = require('webpack-dev-middleware');
const webpackConfig = require('../..//webpack.dev.js');

// Ställ in en Express-server
const app = express();
app.use(express.static('public'));

if (process.env.NODE_ENV === 'development') {
  // Ställ in Webpack för utveckling
  const compiler = webpack(webpackConfig);
  app.use(webpackDevMiddleware(compiler));
} else {
  // Statisk servera mappen dist/ i produktion
  app.use(express.static('dist'));
}

// Lyssna på port
const port = process.env.PORT || 3000;
const server = app.listen(port);
console.log(`Server lyssnar på port ${port}`);

Kom ihåg att i den första delen diskuterade vi Webpack? Här kommer vi att använda våra Webpack-konfigurationer. Vi kommer att tillämpa dem på två sätt:

• Använd webpack-dev-middleware för att automatiskt ombygga våra utvecklingspaket, eller
• Statiskt överföra mappen dist/, där Webpack kommer att skriva våra filer efter produktionens byggnad.

En annan viktig uppgift server.js är att ställa in servern socket.io, som enkelt ansluter till Express-servern:

server.js, del 2

const socketio = require('socket.io');
const Constants = require('../shared/constants');

// Ställ in Express
// ...
const server = app.listen(port);
console.log(`Server lyssnar på port ${port}`);

// Ställ in socket.io
const io = socketio(server);

// Lyssna efter socket.io-anslutningar
io.on('connection', socket => {
  console.log('Spelare ansluten!', socket.id);

  socket.on(Constants.MSG_TYPES.JOIN_GAME, joinGame);
  socket.on(Constants.MSG_TYPES.INPUT, handleInput);
  socket.on('disconnect', onDisconnect);
});

Efter en framgångsrik anslutning av socket.io till servern ställer vi in några händelsehanterare för den nya socketen. Händelsehanterarna hanterar meddelanden som tas emot från klienterna genom att delegera dem till singeltonobjektet game:

server.js, del 3

const Game = require('./game');

// ...

// Ställ in spelet
const game = new Game();

function joinGame(username) {
  game.addPlayer(this, username);
}

function handleInput(dir) {
  game.handleInput(this, dir);
}

function onDisconnect() {
  game.removePlayer(this);
}

Vi skapar ett .io-spel, så vi behöver bara en instans av Game ('Game') – alla spelare spelar på en och samma arena! I nästa avsnitt kommer vi att titta på hur denna klass fungerar. Game.

2. Game-servern

Klassen Game innehåller den mest kritiska logiken på serversidan. Den har två huvuduppgifter: hantera spelare och simulera spelet.

Låt oss börja med den första uppgiften – att hantera spelare.

game.js, del 1

const Constants = require('..\/shared\/constants');
const Player = require('.\/player');

class Game {
  constructor() {
    this.sockets = {};
    this.players = {};
    this.bullets = [];
    this.lastUpdateTime = Date.now();
    this.shouldSendUpdate = false;
    setInterval(this.update.bind(this), 1000 \/ 60);
  }

  addPlayer(socket, username) {
    this.sockets[socket.id] = socket;

    \/\/ Generera en position för att starta denna spelare på.
    const x = Constants.MAP_SIZE * (0.25 + Math.random() * 0.5);
    const y = Constants.MAP_SIZE * (0.25 + Math.random() * 0.5);
    this.players[socket.id] = new Player(socket.id, username, x, y);
  }

  removePlayer(socket) {
    delete this.sockets[socket.id];
    delete this.players[socket.id];
  }

  handleInput(socket, dir) {
    if (this.players[socket.id]) {
      this.players[socket.id].setDirection(dir);
    }
  }

  \/\/ ...
}

I det här spelet kommer vi att identifiera spelarna genom fältet id deras socket.io (om du är förvirrad, gå tillbaka till server.js). Socket.io tilldelar automatiskt varje socket en unik id, så vi behöver inte oroa oss för det. Jag kommer att kalla det spelare-ID.

Kom ihåg detta, låt oss utforska instansvariablerna i klassen Game:

• sockets — detta är ett objekt som knyter spelarens ID till den socket som är kopplad till spelaren. Det gör att vi kan få åtkomst till sockets efter deras spelar-ID i konstant tid.
• players — detta är ett objekt som binder spelarens ID till objektet code>Player

bullets — detta är en array av objekt Bullet, utan någon specifik ordning.
lastUpdateTime — detta är en tidsstämpel för det senaste uppdateringstillfället av spelet. Snart kommer vi att se hur den används.
shouldSendUpdate — detta är en hjälpfunktion. Vi kommer också att se användningen av den snart.
Metoder addPlayer(), removePlayer() och handleInput() behöver ingen förklaring, de används i server.js. Om du behöver fräscha upp minnet, gå tillbaka lite.

Den sista raden constructor() startar spelets uppdateringscykel (i en frekvens av 60 uppdateringar/s):

game.js, del 2

const Constants = require('..\/shared\/constants');
const applyCollisions = require('.\/collisions');

class Game {
  \/\/ ...

  update() {
    \/\/ Beräkna förfluten tid
    const now = Date.now();
    const dt = (now - this.lastUpdateTime) \/ 1000;
    this.lastUpdateTime = now;

    \/\/ Uppdatera varje projektil
    const bulletsToRemove = [];
    this.bullets.forEach(bullet => {
      if (bullet.update(dt)) {
        \/\/ Förstöra denna projektil
        bulletsToRemove.push(bullet);
      }
    });
    this.bullets = this.bullets.filter(
      bullet => !bulletsToRemove.includes(bullet),
    );

    \/\/ Uppdatera varje spelare
    Object.keys(this.sockets).forEach(playerID => {
      const player = this.players[playerID];
      const newBullet = player.update(dt);
      if (newBullet) {
        this.bullets.push(newBullet);
      }
    });

    \/\/ Tillämpa kollisioner, ge spelarna poäng för att träffa projektiler
    const destroyedBullets = applyCollisions(
      Object.values(this.players),
      this.bullets,
    );
    destroyedBullets.forEach(b => {
      if (this.players[b.parentID]) {
        this.players[b.parentID].onDealtDamage();
      }
    });
    this.bullets = this.bullets.filter(
      bullet => !destroyedBullets.includes(bullet),
    );

    \/\/ Kontrollera om någon spelare är död
    Object.keys(this.sockets).forEach(playerID => {
      const socket = this.sockets[playerID];
      const player = this.players[playerID];
      if (player.hp  {
        const socket = this.sockets[playerID];
        const player = this.players[playerID];
        socket.emit(
          Constants.MSG_TYPES.GAME_UPDATE,
          this.createUpdate(player, leaderboard),
        );
      });
      this.shouldSendUpdate = false;
    } else {
      this.shouldSendUpdate = true;
    }
  }

  \/\/ ...
}

Metod update() innehåller förmodligen den viktigaste delen av logiken på serversidan. Låt oss gå igenom allt det gör i ordning:

1. Beräknar hur mycket tid dt som har gått sedan den senaste update().
2. Uppdaterar varje projektil och förstör dem om det behövs. Vi kommer att se implementeringen av denna funktionalitet senare. För nu räcker det att veta att bullet.update() återvänder true, om projektilen ska förstöras (den har lämnat arenan).
3. Uppdaterar varje spelare och skapar en projektil om det behövs. Vi kommer också att se denna implementering senare — player.update() kan returnera ett objekt Bullet.
4. Kontrollerar kollisioner mellan projektiler och spelare med hjälp av applyCollisions(), som returnerar en array av projektiler som träffade spelare. För varje returnerad projektil ökar vi poängen för spelaren som avfyrade den (med hjälp av player.onDealtDamage()), och tar sedan bort projektilen från arrayen bullets.
5. Notifierar och förstör alla dödade spelare.
6. Skickar en speluppdatering till alla spelare varannan gång när den anropas update(). Detta hjälper oss att spåra den ovan nämnda hjälpvärden shouldSendUpdate. Eftersom update() det kallas 60 gånger/s, vi skickar speluppdateringar 30 gånger/s. På så sätt, klockfrekvens servern är 30 takter/s (vi talade om klockfrekvenser i del ett).

Varför skicka speluppdateringar endast varannan gång ? För att spara bandbredd. 30 speluppdateringar per sekund är väldigt mycket!

Varför inte bara anropa update() 30 gånger i sekunden? För att förbättra spelens simulering. Ju oftare det anropas update(), desto mer exakt blir spelens simulering. Men man ska inte gå överstyr med antalet anrop, update()eftersom det är en beräkningsintensiv uppgift - 60 per sekund är fullt tillräckligt.

Den resterande delen av klassen Game består av hjälpfunktioner som används i update():

game.js, del 3

class Game {
  // ...

  getLeaderboard() {
    return Object.values(this.players)
      .sort((p1, p2) => p2.score - p1.score)
      .slice(0, 5)
      .map(p => ({ username: p.username, score: Math.round(p.score) }));
  }

  createUpdate(player, leaderboard) {
    const nearbyPlayers = Object.values(this.players).filter(
      p => p !== player && p.distanceTo(player)  b.distanceTo(player)  p.serializeForUpdate()),
      bullets: nearbyBullets.map(b => b.serializeForUpdate()),
      leaderboard,
    };
  }
}

getLeaderboard() är ganska enkel – den sorterar spelare efter poäng, tar de fem bästa och returnerar användarnamn och resultat för var och en.

createUpdate() används i update() för att skapa speluppdateringar som skickas till spelarna. Dess huvudsakliga uppgift är att anropa metoderna serializeForUpdate(), implementerade för klasserna Player och Bullet. Observera att den endast skickar data om nära spelare och kulor – det finns ingen anledning att skicka information om spelobjekt som ligger långt borta från spelaren!

3. Spelobjekt på servern

I vårt spel liknar kulor och spelare varandra mycket: de är abstrakta, runda, rörliga spelobjekt. För att dra nytta av denna likhet mellan spelare och kulor, låt oss börja med att implementera en grundklass Object:

object.js

class Object {
  constructor(id, x, y, dir, speed) {
    this.id = id;
    this.x = x;
    this.y = y;
    this.direction = dir;
    this.speed = speed;
  }

  update(dt) {
    this.x += dt * this.speed * Math.sin(this.direction);
    this.y -= dt * this.speed * Math.cos(this.direction);
  }

  distanceTo(object) {
    const dx = this.x - object.x;
    const dy = this.y - object.y;
    return Math.sqrt(dx * dx + dy * dy);
  }

  setDirection(dir) {
    this.direction = dir;
  }

  serializeForUpdate() {
    return {
      id: this.id,
      x: this.x,
      y: this.y,
    };
  }
}

Här händer inget komplicerat. Denna klass blir en bra grund för vidareutveckling. Låt oss se hur klassen Bullet använder Object:

bullet.js

const shortid = require('shortid');
const ObjectClass = require('./object');
const Constants = require('../shared/constants');

class Bullet extends ObjectClass {
  constructor(parentID, x, y, dir) {
    super(shortid(), x, y, dir, Constants.BULLET_SPEED);
    this.parentID = parentID;
  }

  // Returns true if the bullet should be destroyed
  update(dt) {
    super.update(dt);
    return this.x  Constants.MAP_SIZE || this.y  Constants.MAP_SIZE;
  }
}

Implementering Bullet är mycket kort! Vi har lagt till Object endast följande tillägg:

• Användningen av paketet shortid för att generera slumpmässigt id projektiler.
• Tillägg av fältet parentID, för att kunna spåra spelaren som skapade denna projektil.
• Tillägg av ett returvärde i update(), som är true, om projektilen är uteanför arenan (kom ihåg att vi pratade om detta i föregående avsnitt?).

Låt oss gå vidare till Player:

player.js

const ObjectClass = require('./object');
const Bullet = require('./bullet');
const Constants = require('../shared/constants');

class Player extends ObjectClass {
  constructor(id, username, x, y) {
    super(id, x, y, Math.random() * 2 * Math.PI, Constants.PLAYER_SPEED);
    this.username = username;
    this.hp = Constants.PLAYER_MAX_HP;
    this.fireCooldown = 0;
    this.score = 0;
  }

  // Returns a newly created bullet, or null.
  update(dt) {
    super.update(dt);

    // Update score
    this.score += dt * Constants.SCORE_PER_SECOND;

    // Make sure the player stays in bounds
    this.x = Math.max(0, Math.min(Constants.MAP_SIZE, this.x));
    this.y = Math.max(0, Math.min(Constants.MAP_SIZE, this.y));

    // Fire a bullet, if needed
    this.fireCooldown -= dt;
    if (this.fireCooldown <= 0) {
      this.fireCooldown += Constants.PLAYER_FIRE_COOLDOWN;
      return new Bullet(this.id, this.x, this.y, this.direction);
    }
    return null;
  }

  takeBulletDamage() {
    this.hp -= Constants.BULLET_DAMAGE;
  }

  onDealtDamage() {
    this.score += Constants.SCORE_BULLET_HIT;
  }

  serializeForUpdate() {
    return {
      ...(super.serializeForUpdate()),
      direction: this.direction,
      hp: this.hp,
    };
  }
}

Spelare är mer komplexa än projektiler, så den här klassen måste ha några fler fält. Dess metod update() gör mer jobb, särskilt när den returnerar den nyss skapade projektilen, om det inte finns någon kvar av fireCooldown (kom ihåg att vi pratade om detta i föregående avsnitt?). Den utökar också metoden serializeForUpdate(), eftersom vi behöver inkludera ytterligare fält för spelaren i speluppdateringen.

Att ha en basklass Object är ett viktigt steg för att undvika kodupprepning. Till exempel, utan klassen Object måste varje spelobjekt ha samma implementation av distanceTo(), och synkroniseringen av att kopiera och klistra in alla dessa implementationer i flera filer skulle vara en mardröm. Detta blir särskilt viktigt för stora projekt, när antalet utvidgande Object klasser ökar.

4. Kollisiondetektering

Det enda vi har kvar är att känna igen när projektiler träffar spelarna! Kom ihåg detta kodavsnitt från metoden update() i klassen Game:

game.js

const applyCollisions = require('./collisions');

class Game {
  // ...

  update() {
    // ...

    // Tillämpa kollisioner, ge spelare poäng för att träffa projektile
    const destroyedBullets = applyCollisions(
      Object.values(this.players),
      this.bullets,
    );
    destroyedBullets.forEach(b => {
      if (this.players[b.parentID]) {
        this.players[b.parentID].onDealtDamage();
      }
    });
    this.bullets = this.bullets.filter(
      bullet => !destroyedBullets.includes(bullet),
    );

    // ...
  }
}

Vi behöver implementera metoden applyCollisions(), som returnerar alla projektiler som träffar spelarna. Lyckligtvis är det inte så svårt att göra, eftersom

• Alla kolliderande objekt är cirklar, vilket är den enklaste formen för att implementera kollisioner.
• Vi har redan en metod distanceTo(), som vi implementerade i föregående avsnitt i klassen Object.

Så här ser vår implementation av kollisionerna ut:

collisions.js

const Constants = require('../shared/constants');

// Returns an array of bullets to be destroyed.
function applyCollisions(players, bullets) {
  const destroyedBullets = [];
  for (let i = 0; i < bullets.length; i++) {
    // Look for a player (who didn't create the bullet) to collide each bullet with.
    // As soon as we find one, break out of the loop to prevent double counting a bullet.
    for (let j = 0; j < players.length; j++) {
      const bullet = bullets[i];
      const player = players[j];
      if (
        bullet.parentID !== player.id &&
        player.distanceTo(bullet) <= Constants.PLAYER_RADIUS + Constants.BULLET_RADIUS
      ) {
        destroyedBullets.push(bullet);
        player.takeBulletDamage();
        break;
      }
    }
  }
  return destroyedBullets;
}

Denna enkla kollisiondetektering är baserad på att två cirklar kolliderar om avståndet mellan deras centra är mindre än summan av deras radier.Här är ett fall där avståndet mellan centren av de två cirklarna exakt är summan av deras radier:

Här behöver vi vara uppmärksamma på ett par aspekter till:

• En projektil får inte träffa den spelare som skapade den. Detta kan uppnås genom att jämföra bullet.parentID med player.id.
• En projektil ska träffa endast en gång i ett gränsfall av samtidig kollision med flera spelare. Vi kommer att lösa denna uppgift med hjälp av operatorn break: så snart en spelare som kolliderar med projektilen hittas, avbryter vi sökningen och går vidare till nästa projektil.

Slut

Det var allt! Vi har gått igenom allt som behövs för att skapa ett webspel av typen .io. Vad blir nästa steg? Bygg ditt eget .io-spel!

All kod för exemplet har öppen källkod och finns på Github.

Källa: habr.com