本文へ移動
cccskills
無料GitHub で公開

other-engines-quickref

Use when the repository is Defold, MonoGame, pygame/pygame-ce, Excalibur or KAPLAY (or melonJS, Stride, Python arcade, macroquad/ggez) - each engine's lifecycle and delta, where logic goes, the test runner, the headless build/run command, and how to capture a frame.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md7.4 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Other Engines Quick Reference

Overview

Smaller engines follow the same rules as the big ones — fixed-step simulation, delta-scaled time, rules in testable plain modules, no allocations per frame, data out of code — with their own lifecycle names and tools. Find the engine's conventions in the repository first; this page is the map when they are thin.

Core principle: Same discipline, local vocabulary. Identify the loop callback and its delta unit, put rules in plain modules the language's test runner can import, and find the command that builds and runs headless.

At a glance

EngineLanguagePer-frame callback, delta unitFixed stepRules tested withHeadless build / runFrame capture
DefoldLuaupdate(self, dt) — secondsfixed_update(self, dt) when enabled in game.projectplain Lua modules + the repo's runner (busted, or an in-engine runner such as deftest/telescope)java -jar bob.jar --platform <platform> resolve build; dmengine_headless for in-engine testsscreenshot extension, or none headless
MonoGameC#Update(GameTime) — gameTime.ElapsedGameTime.TotalSecondsIsFixedTimeStep = true (default), TargetElapsedTimeclass library + xUnit/NUnit, dotnet testdotnet build; content via dotnet mgcb / the .mgcb projectRenderTarget2D → SaveAsPng (needs a graphics device)
pygame / pygame-cePythonyour loop: dt = clock.tick(60) / 1000 — secondsyour accumulatorpytestSDL_VIDEODRIVER=dummy SDL_AUDIODRIVER=dummy python -m game --frames 120pygame.image.save(screen, path) — works headless
ExcaliburTypeScriptonPreUpdate(engine, elapsed) — millisecondsthe engine's fixed-update option (fixedUpdateFps in recent versions)Vitestnpm run build; browser for runningbrowser tools / Playwright
KAPLAYJS/TSonUpdate(() => ...) with dt() — secondsthe engine's fixed update for body() physicsVitest on modules outside the kaplay() contextnpm run build; browser for runningbrowser tools / Playwright

Defold

  • Game objects with components (sprite, collision object, script), composed into collections; communication by messages (msg.post(url, "damage", { amount = 10 })) handled in on_message, input in on_input after msg.post(".", "acquire_input_focus").
  • Script properties (go.property("speed", 200)) for per-instance tuning; shared tuning in Lua data modules or JSON resources.
  • Rules in plain Lua modules (require "game.rules.combat") with no go./msg. calls, so they run under a plain Lua test runner; engine glue in .script files.
  • No per-frame table creation in update; reuse vmath.vector3 values where the hot path allows.
  • Atlases and texture profiles (.texture_profiles) for per-platform compression; HTML5 is a first-class target.

MonoGame

public sealed class ArenaGame : Game {
    readonly GraphicsDeviceManager _graphics;
    SpriteBatch _batch; World _world;                         // World: plain C# rules from Game.Core
    public ArenaGame() { _graphics = new GraphicsDeviceManager(this); IsFixedTimeStep = true; TargetElapsedTime = TimeSpan.FromSeconds(1.0 / 60); }
    protected override void LoadContent() { _batch = new SpriteBatch(GraphicsDevice); _world = new World(Content.Load<WorldData>("arena")); }
    protected override void Update(GameTime t) { _world.Step((float)t.ElapsedGameTime.TotalSeconds, InputMapper.Read()); base.Update(t); }
    protected override void Draw(GameTime t) { GraphicsDevice.Clear(Color.Black); _batch.Begin(samplerState: SamplerState.PointClamp); WorldRenderer.Draw(_batch, _world); _batch.End(); base.Draw(t); }
}
  • Rules in a Game.Core class library with no MonoGame reference; dotnet test runs everywhere.
  • One SpriteBatch.Begin/End per layer, sprites from atlases; DrawString with a cached StringBuilder for changing numbers; no LINQ or new in Update/Draw.
  • Assets go through the content pipeline (Content.mgcb); commit the .mgcb entries with the source assets.

pygame / pygame-ce

def run(frames: int | None = None) -> None:
    pygame.init()
    screen = pygame.display.set_mode((1280, 720))
    clock, world = pygame.time.Clock(), World(load_tuning("data/tuning.json"), random.Random(SEED))
    hero = pygame.image.load("art/hero.png").convert_alpha()      # convert once, never per frame
    acc, step, n = 0.0, 1 / 60, 0
    while frames is None or n < frames:
        acc += min(clock.tick(120) / 1000, 0.25)
        for event in pygame.event.get():
            if event.type == pygame.QUIT: return
        while acc >= step:
            world.step(step, read_intents()); acc -= step
        draw(screen, world, hero); pygame.display.flip(); n += 1
  • World and its rules import nothing from pygame; pytest tests them directly.
  • convert()/convert_alpha() every loaded surface (unconverted blits are several times slower); pygame.sprite.Group for batches.
  • Know which package the repo uses (pygame or the community fork pygame-ce); they are API-compatible for most code but are installed separately.
  • Web builds go through pygbag, which needs an async main loop with await asyncio.sleep(0) each frame.
  • Never pickle saves (game-save-and-persistence).

Excalibur

  • new Engine({ width, height, displayMode: DisplayMode.FitScreen, fixedUpdateFps: 60 }), Scenes, Actors with components; Loader with ImageSource/Sound resources.
  • onPreUpdate(engine, elapsedMs) — milliseconds; convert once.
  • Rules in plain TS modules for Vitest; actors only translate rule state into transforms and graphics.

KAPLAY (the maintained successor of Kaboom)

  • const k = kaplay({ width: 1280, height: 720, letterbox: true }); objects are component lists: k.add([k.sprite("hero"), k.pos(80, 40), k.area(), k.body(), "player"]).
  • Scenes with k.scene("game", () => { ... }) and k.go("game"); input with k.onKeyPress("space", jump); movement scaled by k.dt().
  • The kaplay() context is global and needs a canvas — keep rules in modules that never call it so Vitest can import them.

Also detected as games

  • melonJS (TS/JS): me.game, me.Renderable; same web testing approach.
  • Stride (C#): component scripts (SyncScript.Update), Game.UpdateTime.Elapsed; rules in a class library.
  • Python arcade: on_update(delta_time) seconds; pytest on plain modules.
  • macroquad / ggez (Rust): get_frame_time() / ctx.time.delta(); cargo test on plain modules.

Common Mistakes

  • Treating Excalibur's elapsed milliseconds as seconds.
  • pygame surfaces never converted; loading images inside the loop.
  • Defold game logic spread through on_message handlers with no testable module.
  • MonoGame content added to the folder but not to the .mgcb project.

Red Flags

  • An engine import inside a module the tests are supposed to run without the engine.
  • A loop with no delta at all ("one step per frame").
  • A run reported as tested where only the build ran.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases

日本語の概要は準備中です。原文の説明を表示しています。

makifbaysal/tasktrooper1122026年10月11日 更新

Use when the diff adds or changes an endpoint, resolver, RPC, job or query that takes an object id, a role check, a request binding or a tenant filter - BOLA/IDOR, function-level authorization, mass assignment and tenant scoping

日本語の概要は準備中です。原文の説明を表示しています。

makifbaysal/tasktrooper1122026年10月11日 更新

Use on every UI change - semantic HTML, labels for controls, keyboard-navigable dialogs/menus, visible focus, and never color as the only signal

日本語の概要は準備中です。原文の説明を表示しています。

makifbaysal/tasktrooper1122026年10月11日 更新

Use when a task changes any screen, form, dialog, menu or control - Lighthouse/axe scan of the changed screens, a keyboard walk, and the thresholds that fail a task

日本語の概要は準備中です。原文の説明を表示しています。

makifbaysal/tasktrooper1122026年10月11日 更新

How to work a task returned with review, QA or UAT findings. Use when a task is in need_revision or PR review comments are in your context.

日本語の概要は準備中です。原文の説明を表示しています。

makifbaysal/tasktrooper1122026年10月11日 更新

Use when deciding whether a request needs an analiz task before implementation - the conditions that require the architect's analysis versus going straight to implementation

日本語の概要は準備中です。原文の説明を表示しています。

makifbaysal/tasktrooper1122026年10月11日 更新

makifbaysal のスキルをすべて見る

このスキルの問題を報告する