LITIENGINE Documentation

repository·main·Indexed 21 days ago

https://github.com/gurkenlabs/litiengine

A free and open source Java 2D Game Engine for creating tile-based 2D games. It includes a comprehensive library featuring a 2D render engine, sound engine, physics engine, and entity framework, as well as utiLITI, a dedicated map editor. Requires Java 25 or later.

Tokens
1.8K
Snippets
4
Records
10
Agent score
74%

What's inside LITIENGINE

  1. Overview of LITIENGINE features

    main

    LITIENGINE is a free and open source Java 2D Game Engine designed for tile-based 2D games. Key features include:

    • Infrastructure: GameLoop, Configuration, Resource Management, and Logging.
    • 2D Render Engine: GUI Components, Spritesheet Animations, Ambient Lighting, and Particle Systems.
    • 2D Sound Engine: Support for .wav, .mp3, and .ogg formats.
    • 2D Physics Engine
    • Map Support: Tile Maps in .tmx format (compatible with Tiled Editor).
    • Input: Player input via Gamepad, Keyboard, and Mouse.
    • Entity Framework
  2. Use Wang terrains instead of plain tile editing

    main

    To maintain visual consistency and automatic edge/corner transitions, always prioritize Wang terrains over manual GID editing.

    • Preferred Method: Use paint_terrain or paint-terrain to resolve tile corner/edge transitions and neighbor GIDs across grid regions.
    • Discovery: Call list_terrains or list-terrains first to find available Wang terrain sets (e.g., ground, grass, stone, walls, paths) and their auto-tiling rulesets.
    • Fallback: Use plain tile editing (edit_tiles, fill_tiles, or set_tile) only for non-terrain decorative standalone tiles or when no matching Wang terrain set exists in the project tileset.
    # 1. Discover available terrain sets
    list-terrains
    
    # 2. Use terrain painting for automatic transitions
    paint-terrain <terrain_set> <region>
  3. Follow the LITIENGINE Level-Design Workflow

    main

    When authoring or modifying maps, follow a staged workflow to ensure gameplay stability before adding visual clutter. This prevents the need for massive structural changes later in the process.

    1. Big: Gameplay Structure

      • Define the entrance, goal, critical path, major rooms, gates, encounters, transitions, and collision topology.
      • Rule: Do not place decorative clutter until core gameplay questions are resolved.
    2. Medium: Spatial Identity

      • Establish walls, doors, major furniture, machinery, structural lighting, cover, and landmarks.
      • Ensure the environment reads clearly while supporting game mechanics.
    3. Small: Detail & Atmosphere

      • Add floor variation, wall details, debris, small props, particles, atmospheric lighting, and overlay details.
      • Rule: Details must reinforce composition, navigation, or atmosphere; avoid random noise.
  4. Enable Gamepad Support in Java

    main

    To enable gamepad support, your application must be launched with the --enable-native-access=ALL-UNNAMED flag. This grants Input4j access to the Foreign Function & Memory API.

    While Java 25 allows unauthorized native access with a warning by default, using --illegal-native-access=deny or future Java releases will reject it if this flag is not provided.

    java --enable-native-access=ALL-UNNAMED -jar your-game.jar
  5. Validate map playability after structural changes

    main

    A map that renders correctly may still be physically impossible to complete. After any structural change to walls, collision, doors, walkable floor, spawns, objectives, or exit triggers, you must validate playability.

    1. Call analyze_playability: Pass the actual player collider width, height, and clearance.
    2. Handle Failures: If the status is status: FAIL, you must correct all unreachable required targets before proceeding with gameplay placement or marking the map as complete.
    3. Visual Inspection: Use render_playability to inspect computed collision, reachable, and unreachable cells. Do not rely solely on visual floor tiles or apparent wall gaps to infer access.
  6. Install LITIENGINE via Gradle

    main

    LITIENGINE is hosted on Maven Central. To use it in your project, add mavenCentral() to your repositories and include the de.gurkenlabs:litiengine dependency.

    Note on Java Version: LITIENGINE requires Java 25 or later. Versions 22, 23, and 24 are no longer supported.

    ### Groovy syntax
    ```groovy
    repositories {
        mavenCentral()
    }
    
    dependencies {
      implementation 'de.gurkenlabs:litiengine:0.8.0'
    }

    Kotlin Syntax

    repositories {
        mavenCentral()
    }
    
    dependencies {
      implementation("de.gurkenlabs:litiengine:0.8.0")
    }
  7. Infer tile geometry and usage for unknown tilesets

    main

    If a tileset lacks useful labels, use the following process to infer its grammar and role:

    1. Inspect Atlas: Use render_tileset to see enlarged source pixels with local tile IDs to identify family layouts and motifs.
    2. Analyze Usage: Run find_tile_usage for the tileset and specific local tile IDs. Look for directional neighbor frequencies to identify edges, corners, fills, caps, and transitions.
    3. Contextual Comparison: Use render_tile_context at representative locations. Compare selected-layer, composite, and layer-stack views to distinguish terrain from overlays.
    4. Preview Changes: Always call preview_tile_edits before non-trivial mutations. This renders the transient result and reports affected bounds and collision-bearing tiles. It automatically restores the map after the preview.
    5. Commit: Only commit changes after the preview is verified, then re-render the context to ensure the result persisted.
  8. Use utiLITI MCP tools for map authoring

    main

    The utiLITI MCP server provides two levels of tools for interacting with LITIENGINE projects:

    Semantic Orchestration Tools (High-Level)

    Use these for complex, multi-step tasks and project-wide context:

    • analyze_project: Inspects project context, layer stack roles, tile GIDs, and object conventions.
    • plan_map_changes: Generates a staged level-design plan (Big -> Medium -> Small).
    • validate_map_changes: Verifies structural integrity, spawn availability, and collision boundaries.

    Level A Semantic Tools (Safe Batch Operations)

    Use these for safe, efficient operations on maps and entities:

    • get_project_context, get_map, query_region, search_entities, create_entities, update_entities, edit_tiles, fill_regions, render_map.
    • Best Practice: Use fill_regions for rectangular fills across layers and update_entities to move/resize objects in one revision rather than emitting individual calls per layer/entity.

    Level B Raw Tools (Low-Level Primitives)

    Use these when exact control is required:

    • create-map, add-layer, set-tile, add-prop, add-creature, add-trigger, add-spawnpoint, add-collisionbox, save-project.
  9. Supported custom property types for XML tilemaps

    main

    When defining custom properties in XML tilemaps, you must use one of the following supported type identifiers. These types determine how the LITIENGINE XML parser interprets the property values.

    Supported types:

    • string: Textual data.
    • float: Floating-point numbers.
    • int: Integer numbers.
    • bool: Boolean values.
    • file: File paths or references.
    • color: Color representations.
    • object: Complex objects.
    string
    float
    int
    bool
    file
    color
    object