Válogatott munkák, amelyeket a Backend Alchemist jelenlegi csapattagjai korábbi stúdiómunkáik, vezetői feladataik és szerződéses megbízásaik során valósítottak meg.
Azzal kezdjük, aminek működnie kell: egyértelművé tesszük a felelősségi köröket és a hibautakat, majd kiválasztjuk a legkisebb, felelősen üzemeltethető architektúrát. Minden javaslatot a játékosokra gyakorolt hatás, a megvalósítási kockázat, a csapat kapacitása és az üzemeltetési költség alapján értékelünk.
A Bad Goons csapatalapú multiplayer lövöldözős játék, amely egy egyszerű alapelvre épül: a pálya soha ne maradjon változatlan. A játékosok a mérkőzés során árkokat áshatnak, védelmi állásokat rombolhatnak le, új útvonalakat nyithatnak és átalakíthatják a frontvonalat.
A Unity-kliens, a voxelszimuláció, a multiplayer-modell, a dedikált szerverek és a felhőbeli telepítés különálló rendszerként készül, amelyeket közös műszaki architektúra kapcsol össze. A jelenlegi terv 64 fős csatákat céloz meg egy folyamatosan változó frontvonalon.
A LEGFŐBB KIHÍVÁS
Egy minden játékos által alakítható világ szinkronizálása.
A mozgásnak és a harcnak gyorsan reagálónak kell maradnia, miközben a tereprombolás, az ásás, az építkezés, a lövedékek és a taktikai állapot számos csatlakozó kliens között szinkronizálódik.
A JÁTÉKOSÉLMÉNY FEJLESZTÉSE
A játékosok által látott, érzett és irányított élmény.
Belső nézetű mozgás, harc és fegyverkezelés
Dinamikus voxelterep, ásás és ároképítés
Rombolható fedezékek és telepíthető erődítmények
Csapatszintű újraéledési, erőforrás- és ellátási rendszerek
Taktikai UI, dinamikusan reagáló hang és csatatéri visszajelzések
Teljesítményprofilozás és fejlesztési eszközök
MULTIPLAYER ÉS BACKEND
A csata autoritatív és összekapcsolt működését fenntartó rendszerek.
Kliens–szerver predikció és állapotegyeztetés
Autoritatív dedikáltszerver-szimuláció
Terepváltozások, játékosok és csapatállapotok replikációja
A játékmenetek életciklusa, újracsatlakozási és helyreállítási folyamatok
Grafikus felület nélküli Linux-buildek és konténerizált telepítés
Diagnosztika, monitorozás és verziókezelt kiadások
MŰSZAKI ARCHITEKTÚRA
Egy éles használatra tervezett rendszer, minden rétegen egyértelmű felelősségi körökkel.
01 · KLIENS
Unity 6
Vezérlés, megjelenítés, renderelés, hang és prediktált játékosműveletek.
02 · VALÓS IDEJŰ
FishNet
Autoritás, predikció, egyeztetés és szinkronizált játékmeneti rendszerek.
03 · VILÁG
Voxelszimuláció
Játékosok által ásott árkok, átalakított fedezékek és folyamatosan változó harci útvonalak.
04 · SZERVER
Grafikus felület nélküli Linux
A játékosok, a harc, a terep és a megosztott világállapot autoritatív kezelése.
05 · TELEPÍTÉS
Docker
Konfigurálható szervercsomagolás, kiadások, régiók és futásidejű beállítások.
06 · ÜZEMELTETÉS
Felhő-infrastruktúra
Állapotfigyelés, diagnosztika, automatizálás és igényalapú kapacitás.
Éles kiadásra szánt játék, nem pusztán műszaki bemutató.
A Bad Goons jelenleg aktív fejlesztés alatt áll. Az alapvető feladatok közé tartozik a multiplayer-harc, a dinamikus terep, a dedikált szerverek telepítése, a taktikai újraéledési rendszerek és a fejlesztési eszközök kialakítása. Egyszerre eredeti kereskedelmi játék és valós körülmények között működő tesztterep Unity-, multiplayer-, szerver- és felhőkompetenciáink számára.
KOMPETENCIATÉRKÉP
A döntéstől az éles termékig.
01
A környezet és a korlátok feltérképezése
A korlátok, a sikerkritériumok és a műszaki határok tisztázása.
02
Műszaki felelősség
Látható lépésekben haladó fejlesztés, a kódhoz közeli felelősséggel.
03
Architekturális és fejlesztési döntések
A teljesítmény, a helyreállítás és a valós üzemeltetési körülmények tesztelése.
04
Üzemeltetési és teljesítményszempontok
Dokumentáció, megfigyelhetőség és egy karbantartható következő lépés átadása.
GYIK
Az erre a területre vonatkozó kérdések.
Hogyan indul bad goons ?
A megvalósítás meghatározása előtt felmérjük a jelenlegi állapotot, a korlátokat, a sikerkritériumokat és a legkockázatosabb feltételezést.
Be tudnak kapcsolódni egy meglévő csapat munkájába?
Igen. Az éles rendszerek módosítása előtt feltérképezzük a felelősségi határokat, a kódbázis állapotát és a megvalósítási kockázatot.
Mi történik az átadás után?
A termék és a belső csapat igényeihez igazodva állapodunk meg a tudásátadásról, a csapatba épülő kapacitásról vagy a felügyelt üzemeltetésről.