AWS Hackathon - from Lore to cloud playtest

TL;DR:

• We built a proof of concept that takes a change from a commit to a playable cloud build: commit in Anchorpoint for Lore, build with Horde, playtest in the browser with Amazon GameLift Streams.
• Lore runs on EC2 with S3 and DynamoDB. Horde and our dashboard, which also acts as Lore's auth server via Amazon Cognito, run on ECS Fargate. A laptop with UE 5.6 serves as the only build agent.
• Horde's Lore support only exists on Epic's unreleased ue6-main branch. It works, but needs workarounds: builds have to be started by hand and the agent needs the Lore port set explicitly.
• Lore's core works well, and the edges are still raw. Anchorpoint will become the place to manage Lore repositories, members and sign-in.

AWS for Games Hackathon

This week we made a trip to London. The AWS for Games Hackathon was a full day of hands-on building for game developers, run by AWS together with Code Wizards, MPG (The Multiplayer Group) and Databricks. In small teams we could pick one of three pillars and build a prototype or a proof of concept:

• Backend (with MPG): server-side infrastructure such as matchmaking, inventory or LiveOps.
• Pipeline (with Code Wizards): development workflows and build pipelines, like cloud builds or automated playtesting.
• Data (with Databricks): analytics and AI on game data.

We got access to Amazon Bedrock, Kiro, Databricks, GameLift and all the other AWS services in an AWS Workshop account. In two building blocks around lunch, roughly four hours in total, we could prepare our demo.

Our idea: push to playtest via Lore and Horde

Our idea for the pipeline pillar was to build a proof of concept for a CI/CD pipeline around Lore, Epic's new open-source version control system. The loop we wanted: an artist pushes a change in Anchorpoint, a tester can start a build for the change, and a few minutes later they can play exactly that revision as a build in the browser for testing. No local build, no download, no installer needed.

Around Lore we needed three more things:

• Builds: Epic's Horde, which has a work-in-progress Lore integration on an unreleased engine branch.
• Auth: a sign-in based on Amazon Cognito that works for the desktop client, the build system and the web.
• Playtesting: Amazon GameLift Streams, which runs a Windows build on a cloud GPU and streams it to the browser.

Since four hours on the day wasn't much time for all of that, and the sandbox accounts were only available for the day, we prepared some of the deployment steps beforehand and ran a small local Horde + Lore test to see whether the Horde Lore plugin already works in its current state. On the day we applied everything from our prepared Terraform setup in the sandbox account and made fixes where necessary.

Architecture

Everything on AWS runs in one region (us-west-2 in the sandbox):

• Lore server. A single Graviton EC2 instance runs a loreserver 0.10.0 image. Chunks go to S3, metadata and locks to four DynamoDB tables. Lore terminates its own TLS with a Let's Encrypt certificate, because its QUIC transport needs UDP and can't sit behind an Application Load Balancer (ALB).
• Dashboard and Lore auth. A small web app on ECS Fargate behind an ALB, with RDS PostgreSQL, built on Anchorpoint's own development server code. People sign in with Amazon Cognito. The dashboard manages projects and members, acts as Lore's auth server, and acts as the hub for building and playtesting.
• Horde. The Horde server runs on ECS Fargate with DocumentDB and ElastiCache, deployed from a fork of the Horde module in the AWS Cloud Game Development Toolkit, minus its agent autoscaling group. The only build agent registered is our laptop at the hackathon. It has UE 5.6 installed, so the 30–40 GB engine never had to cross the uplink. Only the game project lives in Lore: the small Unreal Engine Stack O Bot demo project with around 1 GB of data.
• Builds in S3. Every build is uploaded as a plain folder, one per revision.
• GameLift Streams. One stream group on a Windows GPU stream class, and one application per built revision. Capacity sits at zero until someone presses Play. We added a second location to the stream group (eu-west-2) for better latency.

Deep dive: Horde + Lore today

Where the integration lives

Out of the box, Horde's CI currently only supports Perforce. Epic's Lore support exists only on the unreleased ue6-main branch of the Unreal Engine GitHub repository, in two parts:

• Engine/Source/Programs/Horde/Plugins/Lore/HordeServer.Lore, a server plugin that reads a stream's history from Lore.
• Engine/Source/Programs/Horde/Drivers/LoreDriver, an agent-side job driver that materializes a Lore workspace using the lore CLI.

The first commit (August 2026) says it is work in progress and will change significantly. There are no docs, the plugin is off by default, and it isn't in the published Horde images. Everything below reflects the branch as we pinned it in late September 2026.

The mapping is simple. A Horde commit ID is the 64-character Lore revision signature, and the change number is the per-branch revision number, so BuildGraph's $(Change) becomes the Lore revision. A Lore-backed stream looks like this (trimmed):

{
 "name": "StackOBot/main",
 "vcs": "Lore",
 "repositoryName": "<lore repository name>",
 "defaultBranchName": "main",
 "enginePath": "../../../Epic/UE_5.6/Engine",
 "workspaceTypes": {
   "Lore": {
     "identifier": "SOB",
     "method": "name=Lore&branch=main&useSharedStore=true",
     "incremental": true
   }
 },
 "templates": [{
   "id": "package-win64",
   "jobOptions": { "driver": "LoreDriver" },
   "arguments": [
     "-Script=D:/H/SOB/Sync/StackOBot/Build/Hackathon.xml",
     "-Target=Publish Win64"
   ],
   "schedule": { "enabled": false }
 }]
}


On the server, the plugin needs Horde__Plugins__Lore__Enabled=true, Horde__Plugins__Lore__ApiKey (the horde-ci key) and plugins.lore.address pointing at the Lore gRPC endpoint in globals.json.

What we had to build

• A Horde server image from ue6-main. Run Setup.bat for the Git dependencies (the Lore .proto files come from there), then the Build HordeServer with Dashboard target of BuildHorde.xml.
• An agent package. A self-contained HordeAgent with JobDriver and LoreDriver, and lore.exe 0.10.0 in LoreDriver/Tools/win-x64/. BuildHorde.xml doesn't package LoreDriver, so we assembled the package ourselves.
• A one-node BuildGraph script in the Lore repository: BuildCookRun for Win64, aws s3 sync into the revision's folder, then a callback to our web dashboard with the S3 prefix.

Problems and workarounds

• Horde never sees a Lore push. In our local test we found that the stream's schedule logged "no candidate changes after CL 0" and never started a job. We turned the schedule off and added the Build button to each revision in the dashboard, which calls Horde's POST /api/v1/jobs with the Lore revision. With a single laptop as the only agent, deliberate builds suited us anyway, since we didn't need to build every revision.
• LoreDriver drops the port. It normalizes the Lore address and strips the port, so the agent's lore CLI dialed gRPC on 443 and the sync failed. Setting LORE_GRPC_PORT=41337 in the agent's service environment fixes it.
• A UE 5.6 engine with a ue6-main Horde works. 5.6's BuildGraph accepts every argument the newer executor passes (-HordeExport, -ListOnly, -SingleNode).
• conformDiskFreeSpace: 0 loops forever. The zero turns into null on the agent's round trip, the server's comparison never matches, and every conform starts again ("Pending workspaces have changed - running conform again"). Leave the field unset. We only hit this one on the day itself.
• Horde cleans up the agent's user profile. Before each batch it deletes %LOCALAPPDATA%\UnrealEngine and related folders for the account the agent runs as. We run the agent as a SYSTEM service, point UE-LocalDataCachePath at a separate DDC folder, and give the SYSTEM lore CLI a file-based token store (LORE_AUTH_STORE=fallback).
• Temporary credentials expire. The sandbox allowed no IAM users, so the agent uploaded to S3 with the session's temporary credentials. A small script writes fresh ones into the service environment and restarts the agent, as long as no build is running.

Outside Horde

• Ray tracing crashed the stream. The packaged game crashed a few seconds into every session on the GameLift Streams GPU (NVIDIA L4) with an assertion in D3D12RayTracing.cpp. Session logs in S3 pointed straight at it. We could fix it by setting r.RayTracing.Enable=0 with r.RayTracing.EnableOnDemand=0.
• Latency. We added a London location to the stream group and streamed from there, because it is closer to the venue than us-west-2.
• Lore on AWS. The Lore server config reference says the stock image has no AWS store plugin, but 0.10.0 ships one. The Toolkit's Lore storage module lacks the fragment-state table that 0.10.0 requires, so we built the Terraform storage setup from Lore's own contrib/aws Terraform example.

Demo: from commit to playtest

1. Commit in Anchorpoint for Lore

Anchorpoint for Lore signs in through the browser with Cognito, once. We change the color of a material on the start level, commit and push. The new revision shows up in the dashboard's revision list with its number, message and author.

The initial import of the sample (1,961 files, about 1 GB) went in once via the Lore CLI. Content uploads during lore commit; the lore push afterwards took 6 seconds.

2. Build in Horde, started from the dashboard

Clicking Build starts Horde's package-win64 job for that revision. The laptop agent leases it, syncs the revision from Lore, packages Win64 with the local UE 5.6, uploads the 1.3 GB build to its S3 folder and calls the dashboard back. The revision turns succeeded and shows its S3 prefix and a link to the Horde job.

On the laptop (i7-12700H, 32 GB) a cold cook and package took 12.6 minutes. With a warm DDC, an incremental package took 79 seconds.

3. Playtest in GameLift Streams, started from the dashboard

As soon as the build callback arrives, the dashboard creates a GameLift Streams application from the revision's folder. When someone clicks Play, it creates a stream URL and opens the AWS-hosted player in a new tab. Stop revokes the URL, ends the session and scales capacity back to zero. The dashboard's Pre-warm button keeps one idle instance ready before a demo, which hides the Windows cold start.

Summary and outlook

The hackathon was a great day. Four hours is short for a pipeline this size, and the local rehearsal the week before is what made it fit. A huge thank you to Carl Prescott and Lawrie Williams for their technical support during the event, and thanks to Code Wizards, MPG and Databricks for supporting it.

Many conversations on the day turned to Lore. There is general interest in it, and studios want to know how ready it is for production. Our answer after this build: the core works well, and the edges are still raw. Lore is pre-1.0. It relies on an external service for auth, and the clients don't speak OIDC yet. The Horde integration lives on an unreleased branch, and Horde can't yet start a build from a Lore push.

Here's what we'd like to see next:

• Lore 1.0 with a stable protocol, so studios can adopt it without pinning every component to one release.
• Horde's Lore plugin in a released engine, with push triggers and OIDC sign-in for the clients.

For Anchorpoint, this is the direction we are going. Anchorpoint becomes the place where you manage Lore repositories: projects, members, permissions and sign-in, as the dashboard did in this proof of concept. On top of that come the asset management features Anchorpoint can offer, like previews, tags and reviews. The goal is a complete setup with auth for your Lore usage, so a studio doesn't have to build what we built for this hackathon. If you want to try Lore with a desktop client today, have a look at Anchorpoint for Lore.

‍