Specification update...

README.md

@@ -1,6 +1,6 @@
 # Small Dungeon Crawler Specification
 
-```
+```text
  _____   ____     ____   _____
 / ___|  |  _ \   / ___| / ___|  Small
 \___ \  | | | | | |     \___ \  Dungeon
@@ -19,25 +19,30 @@ General:
 
 Scoring:
 - As this was intended as a challenge for various programming languages and programmers, scoring rules are:
-```
+```text
-+2 points per weapon, armour, jewelry, enemy, attribute, skill, class or spell definition.
++1 points per single gameplay element definition.
-+1 point per full line of code (in C, this means that blank lines or lines with characters '{', '}', '};', '},' are ignored).
+-1 points per memory leak of 10 bytes.
--1 point per compiler warning, on maximum warning options (in C, that would be -Weverything or -Wall -Wextra).
--2 points per memory leak of 10 bytes (again, libraries and drivers aren't accounted in this case, they can leak).
 ```
 - Then, final score is the total number of points divided by count of lines of code.
 
+## 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...
+
 ## 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.
-- World state is updated on every action (key pressed), unless some menu is active, which includes animations and bots too.
+- 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, but bindings are allowed.
+- Default keyboard action mapping must be consistent across games that follow this specification.
 - Important gameplay elements must be implemented, and the amount of them is up to developer to decide.
 
 Default keyboard action mapping:
-```
+```text
 Use        - KP0 - O
 Inventory  - KP- - I
 Wait       - KP5 - .
@@ -53,41 +58,42 @@ Down+Right - KP3 - N
 
 Examples:
 - Game following this specification can be implemented in terminal or graphical window, as developer decides.
-- It's not important if game has 3 or 300 types of weapons or armours, it's important that it has them.
+- It's not important if game has 3 or 300 types of certain game element, it's important that it has them.
 - Lastly, it's important to have most minimal implementation in terms of source lines of code, for any language.
+- 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.
 
 Elements:
-- Attributes influence health, mana, stamina and experience points of all creatures (party members and bots).
+- Attributes influence core points (health, mana, stamina...) of party members and bots.
-- Skills are passive abilities influencing damage, condition, proficiency and other item usage modifiers.
+- Skills are passive abilities influencing item usage modifiers (damage, condition, proficiency...).
-- Spells are active abilities (activated when casted) that apply certain effects on the world state.
+- Effects are active abilities applying some function or procedure (spells, curses, shrines...).
-- Potions, manuals and scrolls are items that temporarily increase or decrease any previously defined element.
+- Items cause that temporarily or permanent increase or decrease any previously defined element.
-- Weapons are equipment that must have attack category, damage, condition, value.
+- Equipments are items that can be equiped to party members or bots (weapons, armours, jewelry...).
-- Armours are equipment that must have defence category, resistance, condition and value.
+- Currency (gold, coins, gems...) is collectively gathered and can be used for trading items and equipment.
-- Jewelry is type of equipment that can be enchanted and give some effect to party member.
+- Levels are procedurally generated when new layer is entered, more about them below.
-- Coins are collectively gathered and can be used for trading, buying and selling items and other equipment.
 
 ## Player
 
 General:
-- Player controls party of 6 characters (like in Wizardry), as one group in tactical turn-based combat.
+- Player controls party of 6 characters (like in Wizardry), as one group in turn-based combat.
-- Each party member has health, mana, stamina and experience points, attributes, skills, spells, equipment and inventory.
+- Each party member has its own attributes, skills, effects and equipments.
-- Collectively, party has coins (currency), equipment and inventory, which can be shared and redistributed.
+- Collectively, party has currency and inventory (item array), which can be shared.
-- Movement is done with Keypad and Vim-like-keys, respectively KP1...KP9 and H, J, K, L, Y, U, B, N and fullstop.
+- All party members are randomly generated, they have randomized attributes, skills, effects and equipment.
-- All party members are randomly generated, they have randomized attributes, skills, spells and equipment.
+- Players party is preserved when entering new level layer, but gone after losing, aka permadeath.
 
 ## Enemies
 
 General:
 - When an enemy is in view range of player, they'll start following until they enter the battle state.
-- Enemies always leave random amount of coins, and randomly some item like potion, scroll or manual.
+- Enemies always leave random amount of coins, and randomly spawn some amount of items.
-- Attack decisions are made by attacking ranged and magical party members (archers and wizards) first, then fighers.
+- Attack decisions are made by attacking ranged party members first, then melee party members.
 
 ## 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.
-- Maximum width and height limitation is undefined (developer choice), minimum width and height must be respectively 80 and 24.
+- Maximum width and height limitation is undefined (developer choice), minimum width and height must be respectively 80 and 40.
 - 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.
@@ -97,7 +103,7 @@ 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.
-```
+```text
 @           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)
@@ -126,6 +132,6 @@ Graphical extension:
 
 - 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.
-- Combat actions are attack, block, shoot (ranged), evoke (magical), cast (spell), quaff (potion), read (scroll) and wait (skip).
+- Combat actions are attack, block, shoot (ranged), apply (effect), use (item) and wait (skip).
 - Attack, block and shoot use stamina points, which can be recovered on wait or when party is resting after the battle.
-- Evoke and cast use mana points, which can be recovered slowly but automatically after the battle.
+- Additionally, combat actions can use other core points, which can be recovered slowly but automatically after the battle.

xungeons.c

@@ -215,8 +215,8 @@ static void generate_level (void) {
 	level = calloc ((unsigned long int) (level_width * level_height), sizeof (* level));
 
 	for (room = random (6, 18); room > 1; --room) {
-		width  = random (12, 36);
+		width  = random (level_width  / 6, level_width  / 2);
-		height = random (12, 36);
+		height = random (level_height / 6, level_height / 2);
 		x      = random (1, level_width  - width  - 1);
 		y      = random (1, level_height - height - 1);
 		for (i = 1; i < height - 1; ++i) {