bittyBIG Engine

bitty Ideas, BIG fun!

A lightweight 2D/3D game engine built around a professional visual scripting workflow where blocks and editable code are two seamless views of the same program.

The engine is being designed around fast iteration, direct manipulation, compact projects, and a visual programming workflow powerful enough for serious development without forcing users to choose between blocks and code.

Concept / Active Development — September 2026

At a glance

Blocks are the center

The palette, editor, runtime, scene tools, properties, assets, and 2D/3D systems exist to make visual scripting fast and powerful.

Blocks and code are equal

Users can move between a visual representation and readable editable code without switching project modes or losing work.

2D and 3D belong together

Sprites, models, lights, cameras, UI, collision, and sprite-based entities in XYZ space can live in the same scene and project.

Lightweight by default

Small runtime, small project files, minimal hidden duplication, fast startup, fast editing, and intentional allocations are design constraints from day one.

Primary promise: build gameplay quickly with visual logic, drop into code whenever that is faster, and return to blocks without breaking the project.

Core principles

One program, two views

Blocks and code represent one shared program model. Neither side is a disposable export of the other.

Professional visual scripting

Friendly and readable, but dense enough for serious projects. The visual language is intentionally not modeled after Scratch or Blockly.

Direct manipulation

If something is spatial, users should be able to place, move, rotate, scale, and inspect it visually before running the game.

Fast iteration

Blocks, custom blocks, properties, scenes, and assets should refresh without unnecessary full-engine restarts wherever practical.

No silent data loss

If code no longer maps cleanly to blocks, preserve it, explain the mismatch, and offer repair or custom-code options.

AI-friendly structure

What the user sees should correspond cleanly to code and data so humans and tools can reason about the same program.

One program, two seamless views

The editor is built around a shared typed program representation. Blocks and code are projections of the same underlying logic wherever possible.

Block View

Drag and snap
Palette and search
Zoom and navigation
Events and custom blocks

↔

Shared Program Model

Typed nodes / AST
Stable IDs and references
Event and function signatures
Metadata and source mapping

↔

Code View

Readable editable code
Ctrl+F and diagnostics
Symbol navigation
Generated boilerplate folded away

Example: change CubeCount = 30 to CubeCount = 50 in either view and the same underlying program node becomes 50. The other view updates from that shared source of truth.

Custom-code escape hatch: if a code edit cannot be represented visually, the engine should preserve the code and show an explicit Custom / Modified Code node instead of deleting or mangling it.

Unified 2D + 3D world

bittyBIG Engine is intended to use common concepts—entities, transforms, components, properties, events, and functions—rather than treating 2D and 3D as unrelated products.

Entity core

ID / name, transform, properties, parent / children, and scripts / behaviors.

Optional components

2D sprite renderer, 3D model renderer, sprite-in-3D plane, 2D or 3D collision, camera, light, audio source, and more.

The same project can support pure 2D games, 2.5D platformers, true 3D top-down games, and 2D sprite actors moving through a real 3D environment.

Lightweight doctrine

“Super, super, super lightweight.” This is a design constraint, not a late optimization pass.

No redundant updates or draw calls without a reason.
Avoid per-frame allocations in hot paths.
Share immutable data and resources where possible.
Keep editor-only systems out of shipped builds.
Avoid hidden project duplication and oversized generated assets.
Prefer simple ownership boundaries over convenience layers that duplicate state.
Build instrumentation early: frame time, memory, draw calls, asset size, and build size.

Development roadmap

The roadmap is intentionally ordered around proving the unique core first. The goal is not to build a giant engine before proving that the block/code workflow feels excellent.

Milestone	Primary proof	User-visible result	Gate
0	Foundation rules	Project spec + legal/runtime boundary	Start
1	Shared program model	Typed logic exists without either UI	Core
2	Code editor view	Readable editable code from the model	Core
3	Block editor view	Professional blocks render/edit the same model	Core
4	Two-way sync	Edit either side and preserve intent	Proof
5	Custom blocks	Reusable user-authored logic components	Power
6	Properties / events	Fast typed data + clean event signatures	Power
7	Project / assets	Small, inspectable project structure	Base
8	2D scene + runtime	Build and play a tiny 2D game	MVP
9	Core systems	Input / audio / camera / render integration	MVP
10	3D runtime	3D entities move and play in XYZ	3D
11	3D scene editor	Visually author a playable 3D / 2.5D room	3D
12	Build / productization	Export, package, docs, updater	Ship

Current development focus

Current target: Milestone 1 — Shared Program Model.

Define the smallest program-node set needed to reproduce the current spinning-cube proof: variables, literals, assignment, loops, calls, events, arithmetic, and conditionals.
Represent that behavior as pure structured data with stable IDs.
Serialize and reload it without changing meaning or IDs.
Generate readable code from it.
Change CubeCount 30 → 50 through the code representation and confirm the structured model updates.
Only then render the same model as the first bittyBIG visual blocks.

Independent development & relationship to Stencyl

bittyBIG Engine is an independently designed editor and engine project. It is not intended to be a clone of Stencyl's desktop IDE or proprietary toolset.

The current working assumption is that publicly available Stencyl Haxe runtime code may be studied and, where the applicable open-source license permits it, potentially used as an initial runtime foundation or reference. Proprietary Stencyl desktop editor/toolset code is not assumed reusable or redistributable.

The bittyBIG editor is being designed as its own product around a separately documented architecture: a shared program model, professional block/code dual editing, unified 2D/3D scene authoring, compact project structure, and lightweight runtime ownership.

Development boundary: any third-party code used by bittyBIG Engine must follow its applicable license, and proprietary editor/toolset code is outside the project's assumed implementation base unless separate written permission or licensing terms explicitly allow otherwise.

Working definition of success: a developer can think in blocks, think in code, or mix both without paying a workflow penalty—and can build either a tiny 2D game or a true 3D game without dragging around a giant engine they do not need.