# Boboban

**Motto **: Ima fucking spec this.

1. **Map.**

- The map is a a tiling of hexagonal spaces proceeding from a center. Thus a 3-map would consist of 19 hexes.
- Every hex on the map may contain at most one object, and may have attached at most one hex property.
- Hexes will be addressed via (a, b) where a denotes the radius (1 is the center square) and b denotes the radian angle [1,1] is the center hex, [1, 4] is the bottom-most hex in the 6-ring and so on).
- The map defines the base damage for player spells and melee (either of which can be 0), the coin cost for each step taken as well as the base experience and coin drop for NPCs.

2. **Hex properties.**

- Victory hex. When all victory hexen are occupied by victory objects, the player wins.
- Grant hex. When player first steps on hex player is granted (item, spell, experience, health, coins).
- Teleport hex. When player or NPC steps on hex, player or NPC is teleported to another hex.

3. **Map objects.**

- Impassable object. "Rock".
- Trap object. Passage damages passer.
- Destructable object. Player can destroy it, like PCB in supaplex.
- Victory Blocker object. Exactly identical to destructable object, but victory is impossible until it is destroyed.
- Movable object. Player can push it, like crates in sokoban.
- Victory object. Other than its victory magic, exactly identical to passable object.

4. **Items.** All items will have at least one and at most three properties selected from the defined list (provided a slot-indicating property is always chosen), with an associated charge (from 1 to 100) that is decreased by 1 every time the item is used, arbitrarily divided in "common" (gray), "rare" (white), "mystic" (green), "epic" (blue) and "legendary" (orange) fifths. Once the charges of a property are drawn to 0, it is deleted. If the slot property is deleted, the item is destroyed.

Available properties :

- "of the Tractor" (charges). When activated by player, a tractor item will pull whatever movable object drawing one charge per step.
- "of Healing" (charges). Adds 1% of player HP to player on each step, drawing one charge.
- "Cursed" (charges). Substracts 1% of the player's coins (but not less than 1) each step and draws one charge. If player has no coins, one health is substracted instead.
- "Spyked" (charges). Returns a tenth of melee damage to attacker.
- "of Mirroring" (charges). Returns a tenth of magic (ranged) damage to attacker drawing one charge.
- "Staff" (charges). Halves incoming melee damage, drawing one charge per hit. Right hand.
- "Orb" (charges). Halves incoming magic damage, drawing one charge per cast. Left hand.
- "Axe" (charges). Doubles player's melee damage, drawing one charge per cast. Right hand.
- "Wand" (charges). Doubles player's magic damage, drawing one charge per cast. Left hand.
- "Helmet" (charges). Substracts 6 from any melee damage incoming and draws one charge. Head.
- "Mail" (charges). Substracts 13 from any melee damage incoming and draws one charge. Chest.
- "Cuisses" (charges). Substracts 10 from any melee damage incoming and draws one charge. Legs.
- "Hat" (charges). Substracts 6 from any magic damage incoming and draws one charge. Head.
- "Robe" (charges). Substracts 13 from any magic damage incoming and draws one charge. Chest.
- "Hosen" (charges). Substracts 10 from any magic damage incoming and draws one charge. Legs.

5. **Spells.** All spells have 3 levels, Novice, Advanced, Master.

- Missile. Goes straight, delivering 1x / 2x / 3x damage to 1 / 2 / 3 enemies or objects in path.
- Fireball. Goes straight, explodes once it hits something for 1 / 2 / 3 damage in a 1 / 2 / 3 radius and 1 / 2 / 3 burning damage for 1 / 2 / 3 turns.
- Lightning. Hits closest enemy 1 / 2 / 3 hexes away for 1x / 2x / 3x damage and then jumps to closest enemy or object at a similar distance up to 1 / 2 / 3 times.
- Ice Spray. Hits 1 / 4 / 9 adjacent hexes, reducing speed of enemies inside by 1 / 2 / 3 for 1 / 2 / 3 turns.
- Jump. Moves player 1 / 2 / 3 hexes against gravity vector plus 1 hex in a random direction after that.
- Teleport. Moves player 2 / 3 / 4 hexes in any direction, through any obstacles.

6. **Player.** Player base health is 100, Player accrues experience for killing NPCs. Every 256 experience increases player level by 1, adding 1 skill point to be used for any skill of player's choice. Available player skills :

- "Bruiser". Increases player melee damage by 1 (in addition to map base).
- "Wizard". Increases player spell damage by 1 (in addition to map base).
- "Tough". Increases player hitpoints by 1.

7. **NPCs.** Map defined, must specify their name, skills, spells, items, hp, coin and experience drop as well as a movement / use model. Can be aligned with Player or not, and don't have to be aligned with each other.

8. **Campaign.**

- Acyclic graph of however many maps, think v. Alternate routes are permitted.
- Defines icons to be used for all objects / npcs etc inside all maps.
- Defines whether health replenishes at beginning of map or not.
- Defines whether shop is available in between maps and what it may contain.
- Defines whether maps can be replayed or not, and what to do with the results (player keeps whole thing, or only delta from last run, if positive).
- Defines gravity vector (6 possible directions, or no gravity).

Evidently, both classical Sokoban and classical Supaplex can be reimplemented as subsets of this design ; so my question is twofold : who wants to build the engine for this ? And, who wants to translate the two datasets for it ?

Tuesday, 10 April 2018

Hey, this is really cool! I'm still in the process of grokking the overall spec, so I might end up putting a bunch of questions in multiple comments.

I'm a bit confused about the proposed addressing scheme for the hexagonal tiles. First off, I'm not sure I understood correctly, so I'll lay it out here: in general, a r-map is a hexagonal "circle" of radius r, centered around an origin. The surface would then be computed as: 1 + 6 * 1 + 6 * 2 + ... + 6 * (r - 1). Is this correct?

Now, for the addressing scheme: it seems to me that this is an axial coordinate system (illustration here), but centering the origin in (1,1) seems a bit counterintuitive, since there'll be negative coordinates anyway. Say, for the 6-ring in the example, the *top*-most tile would be at (1,-2) -- which is in no way problematic, only the pedant mathematician would expect the origin to be centered in (0,0).

Have I understood this correctly? If not, could you give out a more elaborate example?

Tuesday, 10 April 2018

No, no, no. It's strictly positive, the first number counts rings and the 2nd number counts discrete angles. The "top-most" tile will always be (r, 1) and the bottom-most tile will always be (r, p/2). So your 2nd circle will go (3, 1) through (3, 18). That make sense or do I need to draw it ?

Tuesday, 10 April 2018

I think I got it, but the numbers don't check out, so just to make sure, I'll give formalization another shot: a r-map comprises r concentric "rings", of length 1, 6, 6*2, ..., 6*(r-1), centered around the coordinate (1,1). The first ring has length 1, the second 6, the third 12, etc. (pen and paper drawing agrees on this), so in general: the first "ring" has one tile, while ring k (1 < k

Tuesday, 10 April 2018

Bah, this got cut off for some reason, lemme repost:

I think I got it, but the numbers don't check out, so just to make sure, I'll give formalization another shot: a r-map comprises r concentric "rings", of length 1, 6, 6*2, ..., 6*(r-1), centered around the coordinate (1,1). The first ring has length 1, the second 6, the third 12, etc. (pen and paper drawing agrees on this), so in general: the first "ring" has one tile, while ring k (1 < k

Tuesday, 10 April 2018

Sorry for the annoying triple-post. wp parsed some of the input as tags, trying to wrap the math in preformatted tags:

I think I got it, but the numbers don't check out, so just to make sure, I'll give formalization another shot: a r-map comprises r concentric "rings", of length 1, 6, 6*2, ..., 6*(r-1), centered around the coordinate (1,1). The first ring has length 1, the second 6, the third 12, etc. (pen and paper drawing agrees on this), so in general: the first "ring" has one tile, while ring k (1 < k < = r) has 6*(k-1) tiles.

Then in general, for 1 < k < = r, coordinates can be represented as (k, i) where 1

Tuesday, 10 April 2018

Quadderple posting this, with apologies for the noise and duplication:

I think I got it, but the numbers don't check out, so just to make sure, I'll give formalization another shot: a r-map comprises r concentric "rings", of length 1, 6, 6*2, ..., 6*(r-1), centered around the coordinate (1,1). The first ring has length 1, the second 6, the third 12, etc. (pen and paper drawing agrees on this), so in general: the first "ring" has one tile, while ring k (1 < k <= r) has 6*(k-1) tiles.

Then in general, for 1 < k <= r, coordinates can be represented as (k, i) where 1 <= i <= 6*(k-1). Then the first coordinate on the outermost ring (could be top-most by convention) is (r,1), the "last" coordinate is (r,6*(r-1)), while the "middle" (could be bottom-most by convention) is (r,6*(r-1)/2 + 1). I've verified this on a hand-drawn 3-map.

Looking at it, I see two problems: 1. the degenerate r = 1 case is a bit annoying (but could be handled gracefully), and 2. I'm not sure what moves are available to the player. I guess it would make sense to preserve the directions as represented by the coordinates (away from/towards the center and forwards/backwards on the current ring), and it makes sense to make this explicit, since there's no such thing as up/down-left/right movement in this universe.

I think I have a pretty clear image of how this should look now, I'll see if there's some easy way to arbitrarily draw these r-maps.

Tuesday, 10 April 2018

There we go. I think you got it!

What degenerate case, it's the map maker's job to make an interesting map/campaign. These map exactly on the concept of patch tree, so you know, only play those signed by people you trust.

As to movement, player always moves to an adjacent square. Can be done with clicking, this item screams to be implemented in html5.

Tuesday, 10 April 2018

Hey, take a look at this! (archived) I deliberately omitted the second ring, just to illustrate the flexibility of the generation process.

One more question: is the game real-time or turn-based? One of the main differences between Sokoban and Supaplex is that the latter has a notion of time (IIRC there was even a time limit for gathering "victory blockers"). Also, some of the harder Supaplex levels relied a lot on avoiding/running from those bastard forks.

Tuesday, 10 April 2018

Turn based. Each step is a turn.