OOP Utilities
The OOP module provides high-level, object-oriented wrappers around Minecraft systems such as entities, teams, scoreboards, timers, and gameplay state. Each feature is documented on its own page - see the links below.
Install this module
Add the oop artifact when you want object-oriented gameplay abstractions on top of the core Kore DSL.
Generated resource names for OOP-specific features are centralized in OopConstants so they're easy to find and override. Helper-specific generated names now live in HelpersConstants inside the helpers module.
Utility-style features such as renderers, math helpers, raycasts, areas, state delegates, and VFX now live in the helpers module.
All Features
- Boss Bars - Register, configure, and manage boss bars.
- Cooldowns - Scoreboard-based cooldown system that decrements every tick.
- Entities & Players - Create entities and players, execute helpers, batch commands, entity commands, and entity effects.
- Events - Advancement-based event system for player and entity actions.
- Game State Machine - Scoreboard-based state machine with transition helpers.
- Items - Object-oriented item creation and spawning.
- Scoreboards - Objective management and per-entity score operations.
- Spawners - Reusable entity spawner handles for summoning mobs.
- Teams - Object-oriented team management with colors, collision rules, and nametag visibility.
- Timers - Scoreboard-based timers with optional boss bar integration.
Why use oop
Choose the oop module when your datapack starts to revolve around reusable gameplay concepts rather than isolated commands.
- Entities and players become named handles instead of repeated selectors.
- Systems such as timers, cooldowns, boss bars, and spawners generate their own supporting commands and objectives.
- Your Kotlin code reads closer to gameplay intent, which makes larger datapacks easier to maintain.
You do not have to go “all in”: the OOP layer is meant to sit on top of Kore, not replace it.
Typical workflow
Most OOP utilities follow a common structure:
- Register or declare the gameplay object once (
team(...),registerCooldown(...),registerSpawner(...), etc.). - Let Kore generate the supporting commands, objectives, or load/tick handlers.
- Use the handle in functions with concise methods such as
player.giveEffect(...),cooldown.start(...), orspawner.spawn().
That workflow keeps setup centralized while leaving your gameplay functions focused on intent.
Vanilla Kore vs OOP Kore
The OOP module wraps the low-level command DSL into object-oriented abstractions. Here's a complete side-by-side comparison showing how the same mini-game setup looks with each approach.
Vanilla Kore
OOP Kore
Key Differences
| Aspect | Vanilla Kore | OOP Kore |
|---|---|---|
| Entity references | Manual selectors (allPlayers { ... }) repeated everywhere |
Named objects (player("RedPlayer")) reused across functions |
| Commands | Low-level calls like scoreboard.players.set(...), effect.give(...) |
Method calls on entities: player.giveEffect(...), player.joinTeam(...) |
| Game state | Manual scoreboard objectives and raw set calls |
registerGameStates { state("running") } + states.transitionTo("running") |
| Cooldowns | Manual scoreboard decrement loops | registerCooldown("dash", 3.seconds) - tick function auto-generated |
| Spawning | Raw summon(EntityTypes.X, pos) |
registerSpawner(...) + spawner.spawn() |
| Boilerplate | Selector construction, objective registration, execute blocks | Handled internally by the OOP abstractions |
The OOP module doesn't replace vanilla Kore - it builds on top of it. You can freely mix both styles, using OOP utilities where they simplify your code and dropping to vanilla commands when you need fine-grained control.
