dare m i g h t y things

Terminal Velocity builds the platform behind a game. The backend and publishing stack that carries a global rollout, the systems that scale your servers, and the matchmaker. The team has built matchmakers for some of the biggest games of the last 15 years, and scaling systems that have run up to millions of players online at once across multiple clouds and bare metal. They also get called in to fix and integrate systems somebody else built.

We work out what your backend and publishing stack has to do before anybody writes it. Which platforms you are launching on and what each one demands, how player accounts and purchases carry across them, and what the matchmaker needs to know about a player to put them in a good game. We size the server architecture against the player numbers you are planning for and tell you where it will get expensive.

We build the platform: the backend services, the publishing tools, the live configuration and the features your game needs to roll out globally. We build the matchmaker to your rules, and the systems that scale your servers up and down. Where something already exists, we take it over, fix it or integrate it with the rest. All of it is written to your design, documented, and yours to fork and modify.

We load test the platform against traffic shaped like a real launch and fix what breaks. The matchmaker gets tested against realistic player populations, because one that works with a hundred testers can still fall over with a hundred thousand players. We prove the scaling systems bring servers up fast enough and take them back down without leaving capacity running. We set the latency targets and check the game holds them.

We run the platform through a full rehearsal. Playtests big enough to stress the real services, servers left under load for days to find the slow leaks, and the matchmaker running against launch-sized queues. We write and test the rollback plan for getting the backend back to a known state. We agree the numbers that trigger action on launch day, so nobody is deciding in the moment.

Letting people into the game is the part that fails most visibly, so the matchmaker and the queues get watched live from the first minute. We keep headroom in the services for a launch bigger than forecast and adjust the scaling as the real curve appears. Where the backend needs a change during launch week, we make it and roll it out without taking the game down.

We tune the matchmaker against how your players actually behave, which is never what the design assumed. Queue times get cut where they are losing people. The scaling rules get adjusted to the real player curve, so you stop paying for servers nobody is using. We work through the platform problems the live player base surfaces, and add the publishing features the roadmap needs next.

We keep the platform current as the console holders change what they require. New toolkit versions, expiring certificates and retired third-party services get handled before they become outages. We tune the server scaling as the player base settles into its long-term shape. Where the backend has to move to new infrastructure, we do the migration without taking the game offline.

Multiplay runs game servers in more than 40 locations across six regions, on five public clouds and our own bare metal, with one autoscaler covering all of it behind a single API. Your matchmaker asks for capacity and we place the session on the best host available. Steady-state load sits on owned hardware and the bursts go to cloud, so you are not renting peak capacity all year.

We start with technical discovery and a product-fit review. We make the architecture decisions with you and plan capacity across bare metal and cloud together, so the shape of the fleet is agreed. We recommend how to integrate, through our SDK or straight on the allocation API.

We take your compiled game server binary, evaluate it and integrate it with the orchestration platform. That happens through our SDK, the CLI or the allocation API directly, and it works the same way whether the game is built in Unity, Unreal or your own engine. On an assisted integration your team keeps ownership of the build while we co-design the integration and sit in your design reviews.

We validate the fleet and run end-to-end tests, including the matchmaker workflows that allocate and release servers. We load test on the numbers you are planning for and check the autoscaler behaves when demand moves fast. Observability comes with it, so logs, crash reports and traces are tagged per allocation and you can follow a single session through the system.

We pre-warm capacity and ramp it ahead of go-live, so the servers are already standing when the game opens. The engineer who has been on the project since the first call is there through the launch window. We agree what burst looks like, which regions come up in what order, and what happens if demand arrives somewhere nobody expected.

Capacity is warm before players arrive, with steady-state load on bare metal and burst going to cloud as demand climbs. We watch fleet health in real time and our engineers are on it around the clock through the launch window. The autoscaler places every session on the best available host, so a region filling faster than forecast gets covered as it happens.

We keep optimizing capacity across bare metal and cloud as the real player curve appears, which is where most of the hosting cost gets decided. We handle OS and game patching and promote new builds through your environments. We plan capacity around seasons and DLC, so a content drop does not arrive with the fleet sized for a quiet week.

Our engineer stays on the account, so the person who knows your fleet is still there in year three. We keep patching, promoting builds and tuning capacity as the game changes. Incident support runs around the clock, and we review the account with you regularly to take out what the game no longer needs.

Live Operations runs on runbooks. For every way your game can fail we write the procedure for handling it, agreed with your team and tested before launch, so an incident at three in the morning gets a known answer. Multiplay engineers in three regions work those runbooks around the clock. The engineers on your title stay on it, so the runbooks and the people who use them build up together. They also handle patching, build promotion and capacity planning.

We look at what you already have for observability. If there is a tool in place we work with it, and if there is not, we plan out how it gets built and who builds it. We go through what the game and the servers will need to record once it is live, so that work sits in the build plan from the start. We also start the runbook conversation here.

We review what the game and the servers write down while they run, and whether the two can be lined up when something goes wrong. We set up observability so logs, crash reports and traces are tagged per allocation, which lets us follow a single session through the system. We check that any setting we are expected to change live actually works before anything depends on it. This is also where the first runbooks get drafted.

We write the runbook library with your engineers. One procedure per failure mode, each naming the symptom, the checks to run, the fix, who to wake and when to escalate. We build the dashboards those procedures point at, and set the alert thresholds that decide what wakes somebody up and what waits until morning. We test every alert by triggering it.

We run the runbooks in drills on the real systems, break things deliberately, and time the response. Anything that reads well and works badly gets rewritten. We set the on-call rota and the escalation path, agree with you how a rollback decision gets made and who can make it, and repeat the drills until the response times are where they need to be. The engineers running the drills are the ones who will be on call.

We staff the room around the clock for launch week and work the runbooks as things come in. An incident reaches an engineer who already knows your game within minutes, and they start from a written procedure that has already been tested. We handle the response, promote hotfix builds through your environments as they come, and give you updates you can pass straight to your publisher and community team.

Every incident goes back into the runbooks. We write up what went wrong, what fixed it and what changed as a result, and the procedure gets updated the same week. We handle OS and game patching and promote new builds as you ship them. We plan capacity around the seasons, events and DLC you have announced, so a content drop does not arrive with the fleet sized for a quiet week.

We keep the runbooks current as the game changes, retire the procedures for systems that no longer exist, and train every new on-call engineer on your title specifically, so the knowledge survives people leaving on both sides. Seasonal peaks get absorbed as part of normal running.

Space Rangers is our games recruitment studio. The team works across four countries and three time zones, with offices in New York State, Texas and the UK, and they hire for Rocket Science Group's own studios as well as for clients. They place permanent hires, fixed-term contracts and freelancers. Every recruiter came out of games.

We run the searches for the roles a project gets built around. At this stage that usually means the technical and creative leads, the principal engineers, and the producer who will hold the schedule together. We go out to them individually, handle the approach, and manage the conversation through to an offer.

We hire the engineers, designers, artists and producers who take a project from prototype through full production, on permanent contracts or fixed terms depending on how long the work runs. Every candidate is screened by a recruiter who understands what the role involves, so your leads spend their time on people worth interviewing. We also keep a contractor database for the specialists you need at shorter notice.

We fill the roles a schedule exposes once the build is close to done. That means the certification, tools and performance specialists who are needed for a defined stretch and then move on, usually on fixed-term contracts.

We bring in cover for the final stretch, when the date is fixed and the team is running hot. The people we place at this point have shipped games before and know what the last weeks of a project involve, so they are useful in their first week. Contracts are written to the launch date. Where we have already placed people on your project, they are still there and already know the codebase.

We run the searches for your live team while the game is going out. The roles that keep a game running for years are different from the roles that built it, and they take time to fill, so the work starts before launch. We brief candidates on what a live role actually involves, including the on-call expectations, so nobody accepts a job they have misunderstood.

We hire the live team. That covers the live operations engineers, the backend and network engineers, the content and community roles, and the producer who runs the update schedule. We screen for people who want a live role and intend to stay in one. Placements are permanent, fixed term or contract, depending on how long the work runs and how the team is set up.

We keep hiring for a game years after it launched, as people move on and the team changes shape. We replace key roles, backfill internal moves, and find the specialists a long-running game needs when it takes on something new. We stay in contact with the people we have placed, so a search often starts from somebody already known to us. The same recruiters handle the account throughout.