2024-06-30 09:54:50 -04:00
|
|
|
# Small Dungeon Crawler Specification
|
2024-06-30 09:53:18 -04:00
|
|
|
|
2024-07-01 11:53:04 -04:00
|
|
|
```text
|
2024-06-30 09:54:50 -04:00
|
|
|
_____ ____ ____ _____
|
|
|
|
/ ___| | _ \ / ___| / ___| Small
|
|
|
|
\___ \ | | | | | | \___ \ Dungeon
|
|
|
|
___) | | |_| | | |___ ___) | Crawler
|
|
|
|
|____/ |____/ \____| |____/ Specification
|
|
|
|
```
|
|
|
|
|
|
|
|
## Source Code
|
|
|
|
|
|
|
|
General:
|
|
|
|
- This specification can be implemented in any programming language and in any formatting style.
|
|
|
|
- True aim is that it should be minimal in terms of source lines of code, and resource usage when possible.
|
|
|
|
- All memory leaks should be cleaned, which can be checked with Valgrind, compiler warnings aren't taken in account.
|
|
|
|
- Some APIs, drivers and libraries like SDL2, Raylib, OpenGL and Vulkan leak memory, those leaks are forgiven.
|
|
|
|
- Also, cleaning up all compiler and/or linter warnings is a benefit, but is not required at all.
|
|
|
|
|
|
|
|
Scoring:
|
|
|
|
- As this was intended as a challenge for various programming languages and programmers, scoring rules are:
|
2024-07-01 11:53:04 -04:00
|
|
|
```text
|
|
|
|
+1 points per single gameplay element definition.
|
|
|
|
-1 points per memory leak of 10 bytes.
|
2024-06-30 09:54:50 -04:00
|
|
|
```
|
|
|
|
- Then, final score is the total number of points divided by count of lines of code.
|
|
|
|
|
2024-07-01 11:53:04 -04:00
|
|
|
## Theme
|
|
|
|
|
|
|
|
General:
|
|
|
|
- Theme can be anything, it's up to developer to choose it and decide if it'll be consistent or not.
|
|
|
|
- Some examples given here are using "default" dungeon crawler theme of fantasy world inspired by Tolkien.
|
|
|
|
- However, you can have future theme, medieval one or weeb one with battlemaids and catgirls...
|
|
|
|
|
2024-06-30 09:54:50 -04:00
|
|
|
## Gameplay
|
|
|
|
|
|
|
|
General:
|
|
|
|
- Note that further explanations for gameplay elements are given separately, in text below for consistency.
|
|
|
|
- Game screen layout consists of 2 panels, on the left is world state preview, on the right is player state preview.
|
2024-07-01 11:53:04 -04:00
|
|
|
- World state is updated on every action (key pressed), unless some menu is active, which includes bots too.
|
|
|
|
- Default keyboard action mapping must be consistent across games that follow this specification.
|
2024-06-30 09:54:50 -04:00
|
|
|
- Important gameplay elements must be implemented, and the amount of them is up to developer to decide.
|
|
|
|
|
|
|
|
Default keyboard action mapping:
|
2024-07-01 11:53:04 -04:00
|
|
|
```text
|
2024-06-30 09:54:50 -04:00
|
|
|
Use - KP0 - O
|
|
|
|
Inventory - KP- - I
|
|
|
|
Wait - KP5 - .
|
|
|
|
Up - KP8 - K
|
|
|
|
Down - KP2 - J
|
|
|
|
Left - KP4 - H
|
|
|
|
Right - KP6 - L
|
|
|
|
Up+Left - KP7 - Y
|
|
|
|
Up+Right - KP9 - U
|
|
|
|
Down+Left - KP1 - B
|
|
|
|
Down+Right - KP3 - N
|
|
|
|
```
|
|
|
|
|
|
|
|
Examples:
|
|
|
|
- Game following this specification can be implemented in terminal or graphical window, as developer decides.
|
2024-07-01 11:53:04 -04:00
|
|
|
- It's not important if game has 3 or 300 types of certain game element, it's important that it has them.
|
2024-06-30 09:54:50 -04:00
|
|
|
- Lastly, it's important to have most minimal implementation in terms of source lines of code, for any language.
|
2024-07-01 11:53:04 -04:00
|
|
|
- As this isn't obfuscated code challenge, code should be readable to the person who wrote it, no harm in that.
|
|
|
|
- Person with too much free time could implement this specification in 1 line of valid C code if wanted.
|
2024-06-30 09:54:50 -04:00
|
|
|
|
|
|
|
Elements:
|
2024-07-01 11:53:04 -04:00
|
|
|
- Attributes influence core points (health, mana, stamina...) of party members and bots.
|
|
|
|
- Skills are passive abilities influencing item usage modifiers (damage, condition, proficiency...).
|
|
|
|
- Effects are active abilities applying some function or procedure (spells, curses, shrines...).
|
|
|
|
- Items cause that temporarily or permanent increase or decrease any previously defined element.
|
|
|
|
- Equipments are items that can be equiped to party members or bots (weapons, armours, jewelry...).
|
|
|
|
- Currency (gold, coins, gems...) is collectively gathered and can be used for trading items and equipment.
|
|
|
|
- Levels are procedurally generated when new layer is entered, more about them below.
|
2024-06-30 09:54:50 -04:00
|
|
|
|
|
|
|
## Player
|
|
|
|
|
|
|
|
General:
|
2024-07-01 11:53:04 -04:00
|
|
|
- Player controls party of 6 characters (like in Wizardry), as one group in turn-based combat.
|
|
|
|
- Each party member has its own attributes, skills, effects and equipments.
|
|
|
|
- Collectively, party has currency and inventory (item array), which can be shared.
|
|
|
|
- All party members are randomly generated, they have randomized attributes, skills, effects and equipment.
|
|
|
|
- Players party is preserved when entering new level layer, but gone after losing, aka permadeath.
|
2024-06-30 09:54:50 -04:00
|
|
|
|
|
|
|
## Enemies
|
|
|
|
|
|
|
|
General:
|
|
|
|
- When an enemy is in view range of player, they'll start following until they enter the battle state.
|
2024-07-01 11:53:04 -04:00
|
|
|
- Enemies always leave random amount of coins, and randomly spawn some amount of items.
|
|
|
|
- Attack decisions are made by attacking ranged party members first, then melee party members.
|
2024-06-30 09:54:50 -04:00
|
|
|
|
|
|
|
## Dungeons
|
|
|
|
|
|
|
|
General:
|
|
|
|
- Every dungeon level is 2D matrix (tilemap or gridmap) of random width and height in arbituary limitation.
|
|
|
|
- Procedural generation is up to developer to implement, but level layouts and elements must always be randomly generated.
|
2024-07-01 11:53:04 -04:00
|
|
|
- Maximum width and height limitation is undefined (developer choice), minimum width and height must be respectively 80 and 40.
|
2024-06-30 09:54:50 -04:00
|
|
|
- Elements of dungeon are walls (clip), floors (noclip), decorations (clip/noclip) and special elements (defined below).
|
|
|
|
- Special elements of dungeons execute game state changing arbituary function when 'use' command is given.
|
|
|
|
- Difficulty is tied to number of levels passed, it increments with each level, and generates rarer dungeon elements.
|
|
|
|
- Player can go down to next level, but never return to previous level, no stair-hopping allowed.
|
|
|
|
|
|
|
|
Terminal extension:
|
|
|
|
- Basic VT100 escape codes should be used to output buffers in colours, offset the cursor and change screen size.
|
|
|
|
- Visually distinct colours and styles should be used to express different game elements (defined below).
|
|
|
|
- Terminal should be updated in real-time and include size changes, using curses-like approach to print at terminal size offset.
|
2024-07-01 11:53:04 -04:00
|
|
|
```text
|
2024-06-30 09:54:50 -04:00
|
|
|
@ CYAN BLINK - Player (blinking for easier recognition)
|
|
|
|
# GREY REVERSE - Wall (biome can be expressed with colour)
|
|
|
|
. GREY REVERSE - Floor (biome can be expressed with colour)
|
|
|
|
> PINK BOLD - Stairs (go to next level)
|
|
|
|
} PINK BOLD - Portal (go to random noclip tile)
|
|
|
|
a...z|A...Z RED ITALIC - Enemies (weaker lowercase, stronger uppercase)
|
|
|
|
$ WHITE BOLD - Coins (random number)
|
|
|
|
) YELLOW NORMAL - Shooting weapons (bow, crossbow, sling...)
|
|
|
|
| YELLOW BOLD - Piercing weapons (spear, halberd, lance...)
|
|
|
|
! YELLOW BOLD - Slashing weapons (sword, greatsword, dagger...)
|
|
|
|
? YELLOW BOLD - Swinging weapons (axe, mace, flail...)
|
|
|
|
/ YELLOW ITALIC - Magical weapons (staff, wand...)
|
|
|
|
- GREEN NORMAL - General jewelry (ring, amulet, earing...)
|
|
|
|
] GREEN BOLD - General armours (complete set)
|
|
|
|
= BLUE NORMAL - General potions (affect attributes)
|
|
|
|
% BLUE BOLD - General manuals (affect skills)
|
|
|
|
; BLUE ITALIC - General scrolls (affect spells)
|
|
|
|
```
|
|
|
|
|
|
|
|
Graphical extension:
|
|
|
|
- Every tile (2D sprite) should be of same dimensions for pixel art, to form a grid, loaded as a spritesheet or individual sprites.
|
|
|
|
- Optionally, sprite-overdraw can be used to draw on top of player sprite, for example armours and weapon sprites.
|
|
|
|
- Unlike with terminal extension rules, there are no visual rules here, it's up to common sense of the developer to make them.
|
|
|
|
|
|
|
|
## Battles
|
|
|
|
|
|
|
|
- Each party member gets the turn to do one combat action (defined below), then one of the enemies does the same.
|
|
|
|
- Battle is over when all party members or enemies are dead, and battle menu is hidden until next battle.
|
2024-07-01 11:53:04 -04:00
|
|
|
- Combat actions are attack, block, shoot (ranged), apply (effect), use (item) and wait (skip).
|
2024-06-30 09:54:50 -04:00
|
|
|
- Attack, block and shoot use stamina points, which can be recovered on wait or when party is resting after the battle.
|
2024-07-01 11:53:04 -04:00
|
|
|
- Additionally, combat actions can use other core points, which can be recovered slowly but automatically after the battle.
|