Zakres backendu gry: co określić, zanim poprosisz o wycenę

Dlaczego wyceny backendu się rozjeżdżają

„Ile kosztowałby backend do naszej gry?” to rozsądne pytanie, na które nie ma uczciwej odpowiedzi, dopóki kilka rzeczy nie zostanie spisanych. Dwa studia mogą używać tych samych słów – lobby, konta, serwery dedykowane, LiveOps – a mieć na myśli projekty, które różnią się o rząd wielkości zarówno nakładem pracy, jak i miesięcznym kosztem infrastruktury.

Wycena staje się myląca, gdy po cichu wypełnia luki założeniami. Jeśli z briefu nie wynika, kto utrzymuje serwery po premierze, jeden wykonawca wyceni przekazanie, a drugi rok wsparcia. Jeśli nie oddzielisz liczby graczy w meczu od liczby jednoczesnych użytkowników, jedna oferta zwymiaruje pojedynczy proces serwera, a druga całą flotę. Obie liczby wyglądają precyzyjnie, ale żadna nie opisuje Twojego projektu.

Ten artykuł omawia informacje, które najczęściej zmieniają wycenę backendu gry – w kolejności, w jakiej najłatwiej je naszym zdaniem określić. Na końcu znajdziesz tabelę briefu do wypełnienia i krótką checklistę, którą warto przejść, zanim wyślesz cokolwiek partnerowi – także nam.

Jeśli nie masz jeszcze decyzji co do samego modelu sieciowego (authority, serwer dedykowany czy listen server, predykcja), zacznij od tego, jak zaplanować architekturę gry multiplayer. Zakres backendu zależy od tych decyzji.

1. Opisz grę i drogę gracza

Zacznij od gracza, nie od technologii. Zapisz krok po kroku, co robi gracz od uruchomienia gry do końca sesji:

• Loguje się czy gra anonimowo?
• Dołącza do znajomych w party, wybiera serwer z listy czy naciska jeden przycisk „Graj”?
• Ile trwa typowa sesja lub mecz i co dzieje się po jej zakończeniu?
• Co musi zostać zachowane do następnego uruchomienia gry?
• Co się dzieje, gdy gracz rozłączy się w trakcie meczu?

Ten przepływ to najcenniejsza informacja, jaką może dostać inżynier backendu, bo każdy krok albo wymaga usługi, albo świadomie jej nie wymaga. Gra kooperacyjna, w której czterech znajomych dołącza do swoich sesji, prowadzi gracza do meczu zupełnie inną drogą niż kompetytywna strzelanka, w której obcy gracze są dobierani według umiejętności i regionu. Spisany przepływ ujawnia też stany błędów – pełny serwer, niezgodność wersji, zerwane połączenie – które wymagają zdefiniowanego zachowania, a więc pracy.

2. Wyznacz granicę między serwerem czasu rzeczywistego a backendem

Gry online mają zwykle kilka warstw: klienta gry, serwer gry czasu rzeczywistego symulujący mecz, usługi aplikacyjne obsługujące sesje, graczy i trwałe dane, bazę danych oraz monitoring, który pokazuje operatorom, co się dzieje. Wycena mocno zależy od tego, gdzie przebiegają granice między nimi.

Przydatne pytania:

• Który stan jest autorytatywny w meczu i istnieje tylko do jego końca?
• Jakie dane muszą przetrwać mecz i kto je zapisuje – serwer gry, klient czy usługa?
• Czy w ogóle jest serwer dedykowany, czy sesję hostuje gracz lub relay?
• Kto obecnie odpowiada za netcode czasu rzeczywistego i czy wchodzi on w zakres?

Częstym źródłem niespodzianek jest traktowanie „backendu” jako jednej rzeczy. Praca nad netcode wewnątrz meczu (authority, predykcja, replikacja) i usługi wokół meczu (sesje, wdrożenie, trwałość danych, monitoring) wymagają innych kompetencji i najlepiej wyceniać je osobno, nawet jeśli oba obszary realizuje jeden partner.

3. Wypisz usługi, których naprawdę potrzebujesz

Sporządź prostą listę wymaganych usług i oznacz każdą jako potrzebna na premierę, potrzebna później lub niepotrzebna. Typowe pozycje:

• Tworzenie sesji, lobby, party i alokacja serwerów
• Build serwera dedykowanego, konteneryzacja i wdrożenie
• Wersjonowane kontrakty między klientem a backendem
• Konta graczy i uwierzytelnianie
• Progresja, ekwipunek i ekonomia w grze
• Analityka i narzędzia LiveOps
• Monitoring, logi, alerty i runbooki incydentów

Przy każdej pozycji zaznacz, czy spodziewasz się, że pokryje ją istniejąca usługa platformowa, czy uważasz, że potrzebna jest usługa dedykowana. Integracja sprawdzonej usługi platformowej jest zwykle mniejsza i tańsza w utrzymaniu niż budowanie jej od nowa, ale wybór zależy od modelu sesji, danych i ograniczeń kosztowych – etap analizy może to rozstrzygnąć przed wyceną implementacji.

Szczególnie precyzyjnie opisz konta, progresję, ekonomię i LiveOps. Wiążą się z odpowiedzialnością za bezpieczeństwo, ochronę danych i balans, a ich zakres waha się bardziej niż w jakiejkolwiek innej części backendu. Jednozdaniowe „potrzebujemy ekonomii” może oznaczać licznik waluty albo pełny katalog z zakupami, przyznawaniem przedmiotów, wycofywaniem transakcji i obsługą nadużyć. Traktuj każdy z tych obszarów jako osobną pozycję zakresu, a nie pole do odhaczenia.

4. Trwałość danych i model danych

Wszystko, co ma przetrwać sesję, potrzebuje miejsca, właściciela i cyklu życia. Przed wyceną partner musi wiedzieć:

• Co jest przechowywane: profil, odblokowania, ekwipunek, wyniki meczów, ustawienia, treści tworzone przez graczy.
• Kto zapisuje dane: zaufany serwer gry, usługa backendowa czy klient (tańszy w budowie, ale znacznie trudniej mu ufać).
• Jak często: raz na koniec meczu, przy każdym podniesionym przedmiocie czy w sposób ciągły.
• Czego nigdy nie można utracić ani zduplikować, na przykład kupionych przedmiotów.
• Dane osobowe: co zbierasz, gdzie mogą być przechowywane i jak obsługujesz żądania usunięcia.
• Migracja: czy istnieją dane graczy, które trzeba przenieść lub zachować kompatybilne?

Częstotliwość zapisu i zaufanie to dwie odpowiedzi, które najbardziej zmieniają wycenę. Dane zapisywane przez serwer na koniec meczu to skromne wymaganie; dane, które klient może zmienić w dowolnej chwili, wymagają walidacji, obsługi konfliktów i ścieżki audytu.

5. Integracje zewnętrzne

Każdy zewnętrzny system dodaje pracę, którą łatwo niedoszacować: lekturę dokumentacji, obsługę jego awarii, testy w sandboxie i nadążanie za zmianami. Wypisz każdą integrację wraz z jej celem:

• Usługi platform i sklepów (tożsamość, znajomi, uprawnienia do treści)
• Istniejące platformy backendowe lub usługi dla gier, za które już płacisz
• Dostawcy hostingu i orkiestracja serwerów
• Narzędzia płatności, analityki, raportowania crashy, obsługi klienta lub anti-cheat
• Twoje własne istniejące usługi, jeśli są

Zaznacz, które są już przesądzone, a które otwarte. „Do sesji używamy już usługi X” oszczędza pracę projektową, ale wprowadza ograniczenia integracyjne; „nie wybraliśmy jeszcze hostingu” dodaje etap oceny.

6. Założenia obciążenia: gracze na sesję, CCU i obciążenie zapytaniami

Tu wyceny najczęściej mieszają trzy różne liczby. Każda wpływa na inną część kosztu, więc podaj je osobno – jako zakresy i scenariusze, a nie pojedyncze wartości.

Liczba graczy na sesję to liczba graczy w jednym meczu lub pokoju. Decyduje o koszcie symulacji czasu rzeczywistego: CPU i pamięci na proces serwera, przepustowości na mecz i tym, ile optymalizacji wymaga netcode. To w dużej mierze decyzja projektowa. W Bad Goons, naszej własnej strzelance multiplayer w produkcji, 64 graczy to cel projektowy: kształtuje architekturę, ale nie jest zmierzoną pojemnością.

Liczba jednoczesnych użytkowników (CCU) to liczba graczy online w tej samej chwili w całej grze. Razem z liczbą graczy na sesję określa, ile procesów serwera musi działać równolegle – a więc koszt hostingu, logikę alokacji, reguły skalowania i to, jak szybko flota musi reagować na szczyty. To założenie rynkowe i zwykle najbardziej niepewna liczba w briefie.

Obciążenie backendu zapytaniami to liczba wywołań, które klienci i serwery gry kierują do usług backendowych, oraz to, jak się one kumulują. Zależy od przepływu, nie tylko od CCU: logowania w godzinach szczytu, zapytania matchmakingu, zapisy na koniec meczu, aktualizacje ekwipunku, fala ponownych połączeń po awarii. Decyduje o pojemności usług i bazy danych, limitach zapytań i cache’owaniu.

Przykład poglądowy (nie referencja projektowa): dwie gry o podobnym oczekiwanym CCU mogą mieć bardzo różne backendy. W pierwszej gracze spędzają długie sesje w małych pokojach co-op, a backend jest wywoływany głównie na początku i końcu sesji. W drugiej krótkie mecze kompetytywne kończą się jednocześnie na wielu serwerach i każdy zapisuje wyniki oraz zmiany ekwipunku. Druga gra znacznie mocniej obciąża usługi i bazę danych, choć wartość CCU wygląda tak samo.

Opisz też, czego oczekujesz od testów obciążeniowych. Partner powinien zdefiniować scenariusze obciążenia dla Twojej gry, zmierzyć je i przedstawić wyniki oraz ograniczenia – a nie obiecywać liczbę jednoczesnych graczy, której nikt nigdy nie przetestował.

7. Dostępność i oczekiwania wobec awarii

„Musi działać zawsze” to wymaganie, którego nie da się wycenić. Bądź bardziej konkretny:

• Które regiony trzeba obsłużyć i czy opóźnienie ma tam znaczenie dla rozgrywki?
• Czy okno serwisowe jest akceptowalne i jak wdrażane są nowe wersje, gdy trwają mecze?
• Co gracz powinien zobaczyć, gdy usługa nie działa – komunikat błędu, kolejkę, grę offline?
• Jak szybko i w jakich godzinach ktoś musi zareagować na incydent?
• Czy jest premiera, playtest lub wydarzenie o stałej dacie?

Każdy wyższy poziom dostępności dodaje redundancję, testy i procesy operacyjne. Odpowiedzi mówią też partnerowi, czy graceful shutdown, rollout wersji i rollback są miłym dodatkiem, czy warunkiem premiery.

8. Przekazanie i utrzymanie

Backend nie kończy się w chwili, gdy kod działa. Ktoś musi go wdrażać, obserwować i reagować na problemy. Określ:

• Kto jest właścicielem kont hostingowych i chmurowych, rozliczeń i danych graczy (zwykle Ty jako klient).
• Kto utrzymuje usługi po dostarczeniu – Twój zespół, partner w ramach osobnej umowy wsparcia, czy model mieszany.
• Jakiej dokumentacji oczekuje Twój zespół: architektura i kontrakty, kroki wdrożenia, runbooki typowych incydentów, znane ograniczenia, czynniki kosztów infrastruktury.
• Jakie kompetencje Twój zespół już ma, np. Linux, kontenery czy wybrany dostawca chmury.

Jeśli oczekujesz stałego wsparcia, jego zakres i czasy reakcji należą do briefu. W przeciwnym razie jedna wycena po cichu je uwzględni, a inna nie. Co zawiera kompletne przekazanie serwera, opisujemy w checkliście przekazania serwerów dedykowanych.

Jak podchodzimy do tych pytań

Nasza udokumentowana praca produkcyjna jest najmocniejsza w częściach backendu najbliższych meczowi: integracji sesji i lobby, wdrażaniu serwerów dedykowanych, kontraktach klient–backend, monitoringu i przekazaniu. Bad Goons uruchamia headless buildy Unity na autorytatywnych serwerach Linux z konteneryzowanym wdrożeniem i ta dyscyplina – powtarzalne buildy, health checki, logi, bezpieczny rollout wersji – ukształtowała powyższe pytania. Nasz CTO, w swojej wcześniejszej roli w VR Storm Studio, rozwijał też backend multiplayer oparty na Photon dla trybu co-op dodanego do Bean stalker po premierze.

Konta, progresję, ekonomię i LiveOps określamy i analizujemy indywidualnie dla każdego projektu, zaczynając od sprawdzenia, czy pasuje istniejąca usługa platformowa. Gdy kluczowe założenia są wciąż otwarte, uczciwym pierwszym krokiem jest zwykle ograniczona analiza, a nie pełna wycena implementacji. Co ona obejmuje, znajdziesz na naszej stronie o tworzeniu backendu do gier.

Szablon briefu backendu

Skopiuj tę tabelę do własnego dokumentu i odpowiedz na tyle pytań, na ile możesz. „Nie wiemy” to też dobra odpowiedź – pokazuje partnerowi, gdzie potrzebna jest analiza.

Checklista przed wyceną

Zanim wyślesz brief backendu jakiemukolwiek partnerowi, sprawdź, czy zawiera:

• Drogę gracza od uruchomienia gry do końca sesji, łącznie z rozłączeniami i awariami.
• Granicę między serwerem gry czasu rzeczywistego a usługami backendu oraz informację, kto odpowiada za netcode.
• Listę usług oznaczonych jako premiera / później / niepotrzebne – z kontami, progresją, ekonomią i LiveOps opisanymi osobno.
• Co jest zapisywane trwale, kto to zapisuje, jak często i jakie dane osobowe są w to zaangażowane.
• Każdą integrację zewnętrzną z oznaczeniem: przesądzona lub otwarta.
• Liczbę graczy na sesję, CCU i obciążenie backendu zapytaniami – osobno, jako zakresy lub scenariusze.
• Oczekiwania dotyczące dostępności: regiony, okna serwisowe, rollout i zachowanie przy awariach.
• Własność kont i danych, utrzymanie po dostarczeniu i oczekiwany zakres przekazania.
• Stałe terminy, obecny stack i przedział budżetu.

Jeśli kilka odpowiedzi to wciąż „nie wiemy”, napisz to wprost. Partner, który proponuje krótką analizę, by zamknąć te luki, daje Ci bardziej użyteczną liczbę niż ten, kto mimo wszystko wycenia cały projekt. Gdy brief będzie gotowy, możesz wysłać go do nas.