Core · interface

KeyValueStore

Where persisted state goes.

Explained in The loop.

interface KeyValueStore
import type { KeyValueStore } from '@driftengine/core';

In depth

The engine must not assume a browser origin. A game may want its saves on a server, in a native shell's own store, in an embedder-provided sandbox, or nowhere at all — so every engine system that persists takes a KeyValueStore and the browser is merely the default implementation.

Synchronous by design. Preferences, one-time flags and a chosen character are all read during boot, before the first frame, and an await there means a frame rendered with the wrong settings and then corrected — a visible flicker on every load. An asynchronous backend (a server, IndexedDB) fits by hydrating a cache first and implementing write as fire-and-forget; that is what MemoryStore.hydrate exists for.

No implementation here throws. Storage failure is a normal condition — Safari private mode and several embedded webviews throw on plain access — and a preference is never worth failing a boot for.

Methods

read

read(key: string): string | null
ParameterTypeDescription
keystring

write

write(key: string, value: string): void
ParameterTypeDescription
keystring
valuestring

remove

remove(key: string): void
ParameterTypeDescription
keystring