Lucifer’s Pastime Manual
Lucifer’s Pastime is a board game akin to chess where players can choose the types of pieces they use and how they are arranged at the beginning of the game. They can also put new pieces on the board at any time through a resource management system. The idea behind the game is to combine the flexibility of card games with the rigorous strategy of chess, shogi and go. As of 7/11/21, it is possible to play Lucifer's Pastime on the computer using the client linked near the bottom of the page.
The Board is made up of an 11 x 11 grid of hexagonal cells. Each hexagon is referred to as a cell. Rows are delineated by the numbers 1-11, columns by the letters A-K. Pieces are indicated on the board by letters(this is a place holder). Which player pieces belong to are indicated by white letters for player 1, black for player 2.
Players have their choice of five cards and one spell card, and a queen card. Cards indicate a type of piece and provide information on it. Pieces are unique in the way they can move and their no summoning zone(explained in next section). Spell cards describe an effect players can induce during the game. Summoning a piece to the board(putting it on the board) requires mp. Players start the game with 200 mp.
Zones and Colors
Zones are cells on the board with rules on how pieces can interact with them. A piece’s Movement Zone is where it can move(explained in depth in a later section). A piece’s
No Summoning Zone is where your opponent cannot summon a piece in any way. There are no spell cards that circumvent no summoning zones. A piece’s Starting Cell is the cell it occupies at the start of a turn. The Beginning Zone is where players can summon pieces on their first turn.
Playing the Game
On both players first turn, they can summon up to 16 pieces in their Beginning Zone only, one of which must be a Queen(one Queen will have no cost during this turn). A player’s Beginning zone is the first three rows closest to them(1-3 for player 1, 9-11 for player 2). Player 1 goes first. During their subsequent turns, a player can either summon a piece anywhere on the board(except their opponent’s No Summoning Zones), move a piece, sacrifice their pieces or use their spell card.
Pieces are captured(taken off the board by an opponent) if an opponent piece moves into the cell it occupies. A player wins if their opponent has no queens on the board. The game is a draw if Queens are the only type of piece which can move on the board.
Players can sacrifice their pieces when performing a ritual summon. Ritual summons are a special type of summon that occur in two of a player’s successive turns, one to sacrifice pieces(remove from the board) and another to summon a piece. Any type of piece can be ritually summoned and requires two sacrifices. The sacrifices must be within 2 cells of each other and the piece that is ritually summoned can only be summoned the 2 cells its sacrifices occupied. Pieces with a ritual requirement, can only be ritual summoned and one of the sacrifices must be the requirement. A ritual summon does not need to be completed.
Movement is similar to chess in that pieces can either “leap” to cells or they have a path of cells. A path is a straight line of cells connecting from a piece’s starting cell. A piece can have up to 6 paths(for each side of its starting cell). If another piece is within a path, you cannot move that piece past the obstruction. Movement cells that are not part of any of a piece’s paths, can be leapt to(placed on) as long as another one of your pieces is not already occupying it(see other rules). In the following examples, green colored cells indicate where that piece can be moved to. The purple cell indicates the starting cell. Letters indicate pieces(see Notation). Take note of which piece belongs to which player(see The Board).
1. A player can have up to 10 of one type of piece on the board at once.
2. A player can summon a queen twice during a game, including the free one on the first turn.
3. Players can use their spell card once per game.
4. Pieces cannot be summoned in an occupied cell.
5. A player cannot capture their own pieces.
6. Players can only sacrifice exactly 2 pieces during their turn.
7. Both player’s cards must be visible to each other during the game.
8. False Angel has a minimum cost of 1 mp and no maximum.
9. Spell card effects are prioritized over all rules.
(All Art and visuals are place holder)
Two colors on one cell indicates an overlap of zones.
The Spell Cards
A cell on the board is denoted by a letter and number coordinate. a1 is located on the left corner of the board. Turns are numbered. Pieces are denoted by letters. When multiple actions occur on the same time, those actions are written in the order of occurrence and separated by a comma and space. The remaining mp of a player at the end of their turn is written last following a vertical bar.
A – Apprentice SRB – Royal Banquet
I – Iron Maiden SP - Premonition
N – Nekomata SR – Resurrection
It – Ittan-Momen SSS – Soul Swap
H – Harpy SRE - Regicide
S – Slime SFB – Field of Blood
Rc – Redcap
Hs - Holstaur
Ro – Red Oni coordinate-coordinate – moving a piece
B – Blue Oni *coordinate - summoning a piece
P – Priestess coordinate~coordinate – capturing a piece
Im – Imp spellcard – using a spell card
F – False Angel coordinate’coordinate - sacrificing pieces
Qs – Queen Slime card1 : card2 – User’s card 1 swaps with opponent’s card 2
Au – Automaton
Sy – Sylph
Q – Queen
Example of Turns
3. A b1-b2 |150 The apprentice on b1 moves to b2
4. A*c3 |148 An apprentice is summoned to c3
5. A b2~c3 |150 The apprentice on b2 captures the piece on c3
6. A'a3 A'b3 |148 The apprentices on a3 and b3 are sacrificed
7. SSB, Q*f5 |100 Royal Banquet is used, a queen is summoned to f5
8. SSS, H : S |148 Soul Swap is used, user’s harpy card is swapped with the opponent’s slime card
Last Updated: 7/22/21
How to use the client.
I've begun development on a computer version of Lucifer's Pastime, probably the only feasible way of actually playing it. I'm using the
godot game engine and barely know what I'm doing. I'm figuring it out as I go along. Here is the current state of the project and my unedited
ramblings about my design and wish list of features. Do whatever you feel like with it. If nothing else, the included visual components may be
useful to somebody. I'll update this every week or so.
If you find any bugs while poking around the latest update, I'd really appreciate it if you told me here:
Here are the updated scripts in the first "patch" I've made. Hopefully this will fix the issue mentioned in the last update. There's also been some
convenience added since now parantheses or square brackets can be given to the notation's text box and deck editor's.
After playing with a kind playtester, I've discovered a critical bug in the notation script. The get_cell function is passed too information and that
screws things up. I have a general idea on how to fix it though. When I do that, I'll update the client upload and post the updated notation script. From
now on, instead of reuploading the whole project for every change I make, I'll just post the relevant scripts.
Highlights: Deck viewer added, clicking to copy notation output, a few gameplay changes, lots of bug fixes.
(all parts are needed to extract and they have to be renamed to the same thing except their extension)
Well, we're here. Over the course of about 3 months, I've developed the game to a point I'm satisfied with. Five months since I initially came up with
the idea after dabbling in yugioh and wixoss(which I'd recommend if you have time and are okay with an untranslated game). What I've made isn't perfect by
any means(the icons are blurry and I can't figure out why), but I hope the effort and hours I've put in show through anyway.
Aside from the mentioned highlights, too many other things and little touches have been added for me to even remember them all. The changes in how a few
pieces move and their cost we're done out of gut feelings I've had for a while.
So for now, this is it. The executable client has been released. I will update it if I notice a bug or one is brought to my attention, but feature-wise
this is all I have planned. Thank you
to everyone who's been following this project and given me encouragment and advice. I'm not sure if I would have even finished it without that.
Highlights: All notation input features implemented.
(multi-part upload is because my connection sucks; all parts are needed to extract and they have to be renamed to the same thing except their
As of now, it should be possible to play the game remotely by exchanging notation. The intention is for all in-game actions to be doable through
notation input. You can also add player decks before a game via notation input, as you can see in the sample start file. Resurrection, regicide or field of
blood might cause an issue. I did not test their monstrous if statements in Notation.gd. If somebody encounters a bug, I'd appreciate being informed in the
thread linked above. Questions are also welcome
After this, there's a few more things I want to add like being able to see player decks during a game, a new game option, flipping the board depending
on which player is "you", etc. The next update is the final one I plan on doing with certainty and will include executables. Addtional features and
gameplay changes may or may not happen. I will update the game to fix any bugs though. (note: alt + space is the spell keyboard command now)
Highlights: Summoning and Movement notation partially implemented, visual improvements.
Thanks to the split function, notation input seems doable. This update is a proof of concept. By the next one, I'd like notation to be finished. The
other changes are purely cosmetic. You also need to press shift now to view no summoning zones and cell coordinates(simplest way to prevent conflict with
notation input). After notation is finished, there a few quality of life features I want to add, but after that I'm pretty much finished for the time
being. It would be nice to have computer ai and stuff like that, but that's really above my pay-grade. Someday though I might return and add those
things.(note: the scaling of the context menu seems messed up here. This can be fixed in Context Menu.gd by changing the two numbers there).
Highlights: Spell Cards Finished, rudimentary win condition added.
With this update, every single core gameplay feature has been added. It's technically possible to play the game now if you've got another person at
the computer with you. I tested all the spell cards, but not that thoroughly, so there may be player-specific bugs. By now, I have enough confidence to
say Godot isn't optimized for turn-based games. Using the yield function is unavoidable, but it's really cumbersome and broken. Its documentation is also
inacurate. This has been a problem for years now and it's still not resolved.
The way I've coded things, where lots of complicated checks are preformed
constantly despite not being needed most of the time, and most of the spell cards' logic being contained outside of its scripts, kind of bothers me. It
works and I don't know if there is a better way to do it, but it feels wrong and clunky. Signals are a deceptively useful tool Godot has. They do
simplify interaction between "nodes", but they make things a bit of a clusterfuck, especially when you have a lot of things going on at the same time,
which necessitates a specific usage of yield that makes a global timer that runs out after something small like .1 seconds. It's messy.
Anyway, my next big target is notation. I'm not even sure if I'm capable of adding this feature. It's almost like remaking half of the game in
text format, and adding a custom way of parsing text, which I'm not sure is even doable. I'll make an attempt though. Sample deck: [[0,1,2,3,4,16], 4]
Highlights: Current piece ammount and mp restrictions added, first spell card added.
This is admittedly a smaller update than usual, but an important one nonetheless. The spell card I programmed is Royal Banquet and it's actived
by pressing the space button. The foundational logic for spells is done. Implementing spell cards into the selected deck will take more thought. A
lot of "core" scripts will need to be updated with "has x card been used" variables for more complicated cards. I can see lots of return statments and
headaches in the near future. As of yet, I haven't heard any comments about the quality of my code. Is it inefficent spaghetti, or is it not too bad? I
have no clue, but at least it works. I wont release the next update until every spell card is finished.(Note: line 40 of the Release script needs another
Highlights: Deck Editor implemented, first turn implemented, sacrificing finished.
It's now possible for players to pick their own pieces, one of the most key gameplay components. I'm not too sure about how intuitive the ui is, but
to briefly explain it: first you set a p1 deck and p2 deck, then you can start a game. Having to press the "start game" button may seem superfluous now,
but in the future this will include more options, which will likely be in a pop-up. The first turn with its 16 optional summons are now in too.
Lucifer's Pastime feels more like an actual game than ever before. To be honest though, I'm getting kind of tired of it. Maybe being the creator of
something hampers your enjoyement of it. I'll try to see the rest of this project through to the end, but future updates might take longer. After it is
finished, it still needs to be play-tested. I don't know if I'm up for that. Sample for deck text edit, just hit enter: [0,1,2,3,4,16]
Highlights: Movement highlighting added, no summoning zones implemented, sacrifice distance implemented.
It's now possible to see where a piece can move while you're moving it, a much needed feature. You can also see a player's no summoning zone by pressing
1 or 2 accordingly(press again to hide it); this updates every turn. There's more to be added to sacrificing, but the first part is done. Then a set-up
"turn 0" is next to pick a deck, and the players' first turn. I think spell cards will be the hardest core gameplay feature to implement and
test. After that though, the game itself will essentially be finished.
Highlights: Piece-specific movement implemented, mouse bug fixed.
Movement was logically challenging to implement. I haven't tested every piece, but the general system works as far as I know. No summoning zones are my
next big target and their implementation will be similar. I've also changed red oni and blue oni to be more symmetrical and hopefully "balanced".
Highlights: A context menu has been added, rudimentary movement, capturing and sacrificing has been implemented, previously mentioned bugs fixed.
At this point, I think most of the lowest hanging fruit has been taken care of. I'm surpised I managed to get this far. A month ago, I didn't know if
this would take months or years, but now I can actually see a full game on the horizon. So far, the beginning of development had the most bumps and
hurdles, but after getting the hang of GDscript more or less, it's gotten far easier. Godot really makes a lot of things simple. It's cross platform, so I
had to make a context menu "from scratch" with my own graphics, but the pre-made nodes made the process simple nonetheless. Movement was trickier to
implement. There aren't any noticeable bugs and it seems reliable enough, but I can't guarantee it wont break for some hard to reproduce reason.
(note: on line 53 of the sacrifice script, I put a '-' instead of '=', realized this after uploading file)(note2: the mouse picks up a piece when it
clicks and drags it, but also when it releases its left click on it too. This is the crux of the problem with movement)
Here's the first update. Highlights: Files are better organized now, a basic turn structure has been created, a graphical element has been
added to summoning. I've also added a mouse hover animation to the board, which looks pretty nice. Summoning fails often because the mouse enters a cell
at the same times it exits one, and information about a cell/lack thereof is sent when the mouse enters/exits. Using a script for the mouse
itself to get this information might be a fix for this. Having a script for each cell is a pain, but for certain things it seems necessary. At least
the animation works perfectly.
This work is licensed under a ShareAlike 1.0 Generic International License.