Independent game technology studio building modular runtime infrastructure for creators.

Take Some() Entertainment builds game technology for developers who need control, extensibility, and a clean runtime architecture.

Our core principle is simple:

Engine as host. Feature as plugin.

The engine should not trap creators inside rigid assumptions. It should host systems, expose stable contracts, and let specialized modules evolve independently.

We focus on:

• modular runtime architecture;
• gateway-driven service boundaries;
• plugin-first feature delivery;
• deterministic CI and reproducible builds;
• asset, UI, rendering, input, physics, logging and tooling infrastructure;
• creator freedom without sacrificing engineering discipline.

NewEngine is the core runtime platform.

It is designed around:

• explicit service contracts;
• runtime gateways;
• modular crate and plugin boundaries;
• asset-driven pipelines;
• deterministic loading and diagnostics;
• replaceable platform, renderer, UI, physics, input, logging and tooling layers.

Core architecture rule:

engine-core hosts
plugins implement
gateways route
assets describe
CI verifies

Features belong behind contracts, not inside the engine core.

Bad:  engine knows every concrete system.
Good: engine routes to declared services and plugins.

Runtime systems should not bypass asset routing.

All production asset reads must go through the AssetManager API.

A repository is not healthy unless it builds in automation.

Required baseline:

cargo check --workspace --all-targets --locked
cargo test --workspace --all-targets --locked
cargo clippy --workspace --all-targets --locked --no-deps -- -D warnings

Native plugins may add platform-specific checks, release builds, artifact upload and packaging validation.

Warnings are future bugs. CI uses strict warning gates where practical.

-D warnings

Lint exceptions must be explicit and justified at crate or module level.

Generated binaries, cache files, target directories and temporary build products must not be committed unless the repository explicitly defines them as release artifacts.

Use short, scoped branch names:

fix/ci-upload-artifact-v7
fix/jolt-native-build
feat/loading-kernel
refactor/asset-registry
docs/plugin-policy

Prefer clear, imperative commit messages:

Fix release artifact output path
Update upload artifact action
Add loading manifest registry
Stabilize AureliaUI clippy policy

For larger work, use structured commits:

feat(asset): add NEF8 manifest route
fix(ci): pin native build generator
docs(policy): document plugin boundaries
refactor(ui): split layout registry

Every PR should answer:

• What changed?
• Why was it needed?
• What contracts or runtime behavior are affected?
• What was tested?
• Are there migration notes?

Each production repository should include:

README.md
LICENSE
CONTRIBUTING.md
SECURITY.md
CODEOWNERS
.github/workflows/ci.yml
.github/dependabot.yml
.gitignore

GitHub Actions artifact upload should use the current maintained action version:

uses: actions/upload-artifact@v7

Release DLLs should be uploaded from stable target paths:

path: target/release/*.dll

Recommended main branch protection:

• require pull request before merge;
• require status checks;
• require CI success;
• block force-pushes;
• block branch deletion;
• require linear history where practical;
• require review for runtime-critical repositories.

NewEngine repositories should support both local iteration and CI reproducibility.

Local developer flow:

cargo check --workspace --all-targets --locked
cargo test --workspace --all-targets --locked
cargo clippy --workspace --all-targets --locked --no-deps -- -D warnings

Release flow:

cargo build --workspace --locked --profile release

Native plugins must document external toolchain requirements such as:

• MSVC / clang-cl;
• CMake;
• Ninja;
• Vulkan SDK;
• platform-specific SDKs.

We welcome contributors who value disciplined engineering and creative freedom.

Before contributing:

1. Read the repository README.md.
2. Check CONTRIBUTING.md.
3. Run the repository CI commands locally.
4. Keep changes scoped.
5. Avoid unrelated formatting churn.
6. Prefer explicit contracts over hidden behavior.
7. Document new runtime assumptions.

Please do not report security issues through public issues.

Use the repository SECURITY.md when available. If a repository does not yet provide one, open a minimal private contact request through the maintainers.

Licensing is repository-specific.

Some repositories may use permissive licensing, while internal runtime or studio infrastructure may use a proprietary policy. Always check the repository-level LICENSE, crate metadata and contribution terms before reuse.

Take Some() Entertainment builds tools for people who want to create without asking the engine for permission.

Host the runtime.
Declare the contract.
Load the plugin.
Route the asset.
Verify with CI.
Ship the experience.