Welcome to the Dungeon Crawler Limited Asset Jam 2025!

A game development challenge to make a first person grid based dungeon crawler using a limited set of assets!

In this context, a dungeon crawler is a grid based RPG viewed in first person and with 90 degree turning.

Examples of classic dungeon crawlers are Dungeon Master, Eye of the Beholder, Pool of Radiance and Bard's Tale etc.

For those of you unfamiliar with the annual Dungeon Crawler Jam or the dungeon crawler genre, take a look at previous jams and their entries: 2021 2022 2023 2024 2025

For a previous jam, Kordanor has made an introductory video explaining the jam concept and the dungeon crawler definition. It is strongly recommended that you watch this, however note that this jam differs in asset requirements and rating.

This jam is hosted by, and all jam assets are created by, an informal group on the DungeonCrawlers.org Discord Server, with no official relation to DungeonCrawlers.org or the annual Dungeon Crawler Jam, however you'll see many familiar rules (and participants).

Goal

Using limited assets, create a finished and reasonably polished dungeon crawler; not a prototype, proof of concept or tech demo, but a small game you can play from beginning to end.

Limited Assets

A limited set of assets will be provided for use in the jam, which will include a large number of 12x12 tiles using a limited palette, as well as music and sound FX in a retro style. If you'd like to help author these assets, please reach out on Discord! Example graphical tiles:

Limited Assets Rules

• Core Rules
  At the heart of all of the rules are these the following two rules. All of the specifics below are guidance on how to best follow these rules. When in doubt, consult these two rules, or ask on Discord:
  1. Limit yourself to only using the game assets provided
  2. To keep with the spirit of the jam, where doing any transformation or combination of assets, the original asset must always still be recognizable
• Graphics
  • The jam asset pack will include (possibly hundreds of) 12x12 tiles using a consistent palette
  • You may additionally use up to 8 original, hand-made (no Gen-AI), "bonus" tiles in the same style - 12x12, limited palette per tile. Bonus tiles must be shared on the itch game page, and unless otherwise specified are released as CC0 and may be included in the next version of this jam's asset pack
  • The assets may be palette swapped, stretched, scaled, used as textures on 2D/3D primitives (quads/cubes/spheres/cylinders/particles/etc), but all textures must be recognizably from the asset pack (or your bonus tiles)
  • "Palette swapping" means changing all pixels of a color in a tile to a (new) single color (including transparent)
  • For the bonus tiles and palette swapping, you are not limited to colors in the original asset, but sticking to a limited palette will help with consistency and to follow the "original assets must always be recognizable" rule
  • Cropping tiles to extract recognizable elements (e.g. just the door from a door + frame tile, or a lever from one tile to place in front of a different background) is allowed, as long as the result is still identifiable
  • Tiles do not necessarily need to be used 1:1 for wall textures (e.g. you may texture a wall with a 3x3 grid of tiles, as long as the originals are still identifiable)
  • It is not allowed to use models, textures, fonts or other assets that come with your game engine (with the exception of primitives as noted above)
  • Example against the spirit of the jam: any overlaying or compositing where the result is essentially a completely new texture that could more simply have been authored
  • Exception: A logo/intro screen for you/your brand/engine is allowed (e.g. "by Super-Great Games", "powered by Godot")
  • Custom materials, shaders, post-processing, lighting, etc, are all allowed, as long as all textures are sourced from the assets (examples: dithered lighting, outlining)
  • Examples:
  • Simple 3D deformations, such as extruding along pixel boundaries or generating an appropriate normal map are acceptable, while advanced 3D work that involves authoring complex new meshes (e.g. using the tiles to texture a high resolution model of an ogre) is not allowed.
  • 3D Examples:
• Fonts
  • Only the fonts provided in the asset pack may be used
  • Fonts may be styled (drop-shadows, outlines, etc) as long as they remain recognizable
• Audio
  • Music and sound effects should be sourced from the provided assets
  • Audio can be distorted by effects and overlayed but, as with skewing the textures, it may not be transformed entirely out of recognition. I.e. you can not crop a track down to a note and use that as an instrument to create entirely new melodies
  • Original voice recordings are allowed, but the same AI-rules apply as with all other asset creation (a recommended sampling rate/settings to match style will be provided)
• Text
  • There is no limitation to text, but the same AI-rules apply as with all other asset creation
  • If you feel this is too permissive, consider using no text, or outlawing all words containing the letter "I" or similar
• If you feel unclear on whether something is allowed or not, feel free to reach out on Discord. It's meant to be a game jam where you challenge yourself to only use premade assets

Theme

The theme will be announced when the jam commences.

Rules

Be sure to read the rules carefully before you start outlining your game idea. You are advised to remember that there will be a theme. It's important to take that into consideration when you plan and prepare. It might stir things up quite a bit if you lay down a lot of work in advance.

• The game must have first-person exploration at all times. Exceptions are point to point overworld map movement (fast travel), combat screens, cut scenes, town screen, inventory screen other relevant screens.
• The game must have explorable locations. It doesn't have to be a dungeon in the traditional sense. It can be urban environments, outdoors, spaceship interiors, planetary surfaces etc. (depending on the jam theme). Whichever environment the game has it must be viewed and explored in first-person.
• The game must feature step movement on a square grid (no hexagons, octagons, etc.). Smooth transitions between grid squares are allowed. Half-steps or dividing a logical grid square into smaller squares are NOT accepted. The size of a square should equal the size of the wall segments it is connected to. Consider a grid square as a cube with a ground, four walls, and a ceiling. If there are visible enemies, they must also move on the same grid as the player.
• The game must feature 90-degree turns in four cardinal directions. Smooth transitions between 90-degree angles are allowed. Turning must be invoked by keyboard (or gamepad) control. Mouse-look is permitted as a temporary way to look around, but it should snap to 90 degrees when not in use. Games that allow 90-degree turns up and down are also acceptable.
• The game must have a player controlled character (or party of characters), or the abstraction of a character or persona.
• The game must at the very least have some basic stats. (Minimum a single health/power bar)
• The game must have combat or a similar mechanic for determining outcome of certain situations, enemy encounters and events.
  
• The game must have a win condition.
• The game must have a death/perish/fail condition, or some other end-of-game mechanic. Roguelite mechanics where you restart game upon death but retain some progress is allowed.
• The game must have at least one way to affect character stat(s). Examples are resting, potions, items with bonuses, food, water, powerups etc.
• The game must include an interpretation of the (to-be-announced) theme.
• Your game must not contain nudity, hateful language or visuals. Please consider avoiding extremely strong language and excessive gore, as the games in this jam should be suitable for a general audience. Failure to do so may result in disqualification.
• Uploads will be locked when the jam ends, if you have made a mistake such as forgetting to include a required DLL and your entry is unplayable, please contact the jam organizers on Discord for assistance.

Frequently asked questions

• Will there be a theme? Yes, there will be a theme announced right before the jam starts.
  • Exact theme details are TBD, however likely there will be a couple themes to choose between, or possibly something different such as an image to use as theme inspiration.
• Where do the limited assets come from? The assets are being made by volunteers in the DungeonCrawlers.org Discord server. If you'd like to help, drop in and say hi!
• Can I make custom 3D models? Only simple primitives (quads/cubes/spheres/cylinders/particles/etc) textured in a way that the original tile asset is identifiable are allowed. Simple modeling, with primitives (whether this comes from how an engine lays out a dungeon, or made in a modeling program) such as a beveled corner on a wall, should be fine. If you have a specific example and want clarification, please reach out on Discord.
• What game engine can I use? You may use any game engine like Unity, Unreal Engine, Godot, Love2D etc.
• Can I use my own game engine? Yes, you may use your own home-brew game engine.
• Can I re-use any old source code? You may re-use helper libraries and classes that makes little sense to write again from scratch.
• Can I start working on the game before the jam starts? No. The game must be a new game project started and finished within the jam time frame, not just another week of work on an existing one. You are, however, strongly encouraged to have a working first-person grid-based view and movement set up ahead of time.
• Is it okay to start working on feature X before the jam? If it's a feature useful in making any dungeon crawler (e.g. rendering, movement, interactable doors, general UI), then probably yes, but if it's specific to the particular game you want to make, then probably no. One way to think of it: if it's a feature generally already provided by another engine such as Unity or RPG Maker, implementing those features in your engine of choice is reasonable prep work.
• Can I put a price tag on my game? The game must be free to download and play to the end. A commercial version of the game may of course be released after the jam ends, perhaps with added content and features.
• Can I use AI generated content or pre-made assets or asset packs? No, you must use the provided limited assets, and any bonus assets made for the jam must be made by the jam participants.
• Will there be prizes? No prizes are planned at this time.

Rating

All submitters and contributors who work on a submitted game will be able to rate entries based on the following criteria:

• Overall/Fun - Mostly, was it fun? How much did you enjoy it? How playable was it? How complete was it?
• Asset (ab)use - Did the game make good use of the assets and/or use them in interesting ways?
• Charm/Individuality - Did the game stand out in some creative way (other than asset use)?

When you rate a game you could follow this method:

• 5 stars if the game delivers beyond all expectations.
• 4 stars if the game delivers more than expected.
• 3 stars if the game delivers just what one would expect in the context of a dungeon crawler made in a week.
• 2 stars if the game delivers less than expected.
• 1 star if the game delivers nothing like one would expect.

How you define "delivers" is entirely up to you.

Hints & Tips

• Avoid creating a game with high difficulty. It's in your best interest to ensure that as many players as possible can successfully enjoy your game for an extended period. It's preferable to receive comments such as "The game was too easy" rather than "The game was too hard; I couldn't play it."
• Plan small, finish big! Define a narrow scope that is realistically achievable, and consider having stretch goals if time permits.
• Try to avoid incorporating complex and confusing mechanics that might cause players to give up early. If you decide to include complex and potentially confusing mechanics, please provide a detailed explanation either in-game or on the itch.io project page.
• The pace of the game is crucial. Excessively slow movement and turning might strain the player's patience beyond their breaking point.
• Include skippable intros and dialogues. Many players have limited time and attention spans for playing and testing games, and they might quickly lose interest if there is too much (unskippable) narration and dialogue.
• When uploading your game to your itch.io project page, please indicate the platform(s) it runs on. By doing this, players can use the itch.io client to install and launch your game.
• It is advisable to be prepared with your tools and have at least a rough design idea for your project before starting. Creating a game in such a short time can be a daunting task, so plan well and keep the scope narrow. It is infinitely better to submit a visually simple but feature-complete game that can be played from start to finish, rather than a single-level "demo" with eye-catching graphics but many absent or unfinished gameplay mechanics.

Recommendations

For keyboard controls, use the default keybinds that (most) players are used to in modern dungeon crawlers:

• W/S move forward/backward
• A/D strafe side to side
• Q/E turn left/right

Additionally, ideally support both left and right handed players. This typically means support for Arrow Keys and Num Pad to allow more people to be able to comfortably play your game. This can greatly impact final rating.

We strongly recommend that you focus on having a solid implementation of movement and turning. Instant step is easiest to do, but if you add transitional movement between grid squares and transitional turning there are some things you should consider:

• Too slow transition speed will make the player wait unnecessarily and it slows down the overall pace of the game.
• Make sure your game responds well to input while moving. Queuing the input allows the player to initiate a turn or a move before the current transition has ended. This prevents full stops and allows for fluid movement and turning.
• Perspective (field of view) is a very important part of crawling a dungeon. If the field of view is so narrow that the player can't see parts of the floor square he/she are standing on but instead is facing a wall which fills the whole viewport, orientation will be extremely difficult. It is highly recommended to show parts of the current floor square and also side corners. This enables the player to easily see if there is an exit to the left or right. See the above GIF for a good example of proper field of view. Often this is done by adjusting field of view and/or pulling the eye-position back a little bit.

When possible you should consider adding an option to toggle between instant and transitional movement and turning. Some players prefer one over the other.

We recommend that you do some research on existing games and discover for yourself what works and what doesn't.

Community

Thanks a ton to Zooperdan who runs the annual Dungeon Crawler Jam, from which many of this jam's rules and description are unashamedly copied.

Join our Discord server for discussions, feedback, brainstorming and recommendations for engines, tools, assets etc. to use when developing a dungeon crawler.

If you want to team up with someone let it be known in the discussion board or in our Discord server. There might already be someone there to team up with.

Use #dcexjam2025 (X) or #dcexjam2025 (BlueSky) to share progress or tweet about this jam or your game :)