Performance & Budgeting
API status — PROPOSED, NOT IMPLEMENTED. SkCine is currently a design specification in this conversation; no built SkCine.jar or syntax registry was supplied. All SkCine-specific examples are intended API contracts, not verified runnable
.sk. Do not advertise these as tested until each example passes a real Skript reload and runtime test.
Philosophy
Perform interpolation in optimized Kotlin, not individual every tick Skript loops for every particle/keyframe. Keep a centralized bounded runtime scheduler.
Budget dimensions
| Dimension | Why limit it? |
|---|---|
| Concurrent scene instances | Active tick work and player state |
| Viewers per scene | Camera/packet output |
| Temporary actors | Entity updates and chunk activation |
| Emitters | Per-tick geometry and packets |
| Particles per viewer/tick | Client and network overload |
| Keyframes per track | Memory and lookup costs |
| Callback invocations | Skript main-thread work |
| Scene duration/loops | Runaway timers |
Quality modes
low, medium, high, cinematic, auto. They tune cosmetic density and update rates, not reward/quest logic.
Profiling proposal
SkCine diagnostics should show active scene count, average/p95/p99 update times, allocated temporary entities, packet estimate, particles per viewer, callback time, cleanup errors and oldest active instances.
Authoring tips
- Use 3–8 major camera keyframes rather than microteleporting every tick.
- Use a single particle emitter with a shape instead of hundreds of scheduled tasks.
- Share reusable scene definitions; generate separate runtime instances.
- Prefer display interpolation over constant entity teleporting where supported.
- Never block the main thread to load assets or parse a giant definition.
- Cache immutable curves; validate world and coordinates at creation.
Benchmark approach
Run controlled tests at 1, 10, 50 and 100 scene instances, with varying viewer counts. Report the machine, server and Skript versions. Numbers are scenarios, not guaranteed capacity.