Wishful Coding

Deterministic Risk using Stratego battle mechanics.

I wanted to play a game of Risk with my brother, but he complained that Risk involves too much luck. Sometimes a single unit would successfully defend against a large army.

I came up with the idea of using Stratego pieces, and after some testing, this are the rules we came up with.

Start of the game

The flag is not used. Only missions about conquering continents are used.

1. Hand out mission cards.
2. Divide all territory cards.
3. Each player places all desired units on their territories.

We tried several value systems, but they where much to tedious to be fun. Place as many units as you want.

I found it works well to hold back the spy, a few bombs and some miners. These can then be placed to stop strong units or find mines.

A turn

A turn follows the normal Risk order. Place units according to controlled continents, attack or place floor(territories / 3) units, make up to 7 moves, and possibly take a territory card.

Attacking

Attacking happens by picking a unit of one of your countries with 2 or more units on it, and a unit in a neighbouring hostile country. The unit with the lowest rank is removed from the game.

If the country is taken, any number of units may be moved to it.

In case of equal ranks the defendant wins.

We tried some other rules, but found that most would make the game very slow(move one unit), the marshal too powerful(allow empty territory), or bombs to overpowered(defendant picks unit).

Placing units

This works the same as in Risk, but units cost their rank to place. This makes it cheap to scout and expensive to revive the marshal.

For this purpose the bomb has a rank of 5 and the scout and spy switch costs, making the common scout cheaper than the special spy.

Game end

The game ends when a player has completed his mission.

Remember to remove missions that don’t make sense with 2 players.

Ranks (costs)

• 10 Marshal
• 9 General
• 8 Colonel
• 7 Major
• 6 Captain
• 5 Lieutenant
• 4 Sergeant
• 3 Miner
• 2(1) Scout
• 1(2) Spy
• ∞(5) Bomb

Randomness

Yes, the game is not 100% deterministic, depending how you look at it.

This randomness is in the dealing of the mission and territory cards and the fact that you can’t see the opponents units. You can theorise though.

However, given a starting position, it would be possible for 2 computer players to always arrive at the same end-game.

Ingredients:

• Raspberry Pi
• USB battery
• Headphones
• Case(optional)
• Bunch of wires
• Female 1” header
• Pile of resistors
• Leftover shard of breadboard

Put the buttons, resistors and wires on the breadboard in a basic pull-up configuration.

Use tin, glue and pushpins to connect everything together.

Admire.

Install cmus and write some code to control it using the GPIO buttons.

import RPi.GPIO as GPIO
import socket
from time import sleep

GPIO.setmode(GPIO.BOARD)
GPIO.setup(23, GPIO.IN)
GPIO.setup(21, GPIO.IN)
GPIO.setup(19, GPIO.IN)
GPIO.setup(15, GPIO.IN)

s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
s.connect('/home/pi/.cmus/socket')

def play_pause(e):
    s.send(b'player-pause\n')

def next(e):
    s.send(b'player-next\n')

def volume_up(e):
    s.send(b'vol +10%\n')

def volume_down(e):
    s.send(b'vol -10%\n')

GPIO.add_event_detect(23, GPIO.FALLING, callback=play_pause, bouncetime=200)
GPIO.add_event_detect(21, GPIO.FALLING, callback=next, bouncetime=200)
GPIO.add_event_detect(19, GPIO.FALLING, callback=volume_up, bouncetime=200)
GPIO.add_event_detect(15, GPIO.FALLING, callback=volume_down, bouncetime=200)

while True:
    sleep(1)

Make sure the code runs at startup.

# /etc/rc.local
su - pi -c "screen -d -m cmus"
sleep 5
python /home/pi/play.py >> /var/log/pyplay.log 

Enjoy!

Oh, the audio is pretty bad. It might need an USB sound card.

I’m using Arch on my new laptop because of problems with Fedora. But one problem with Arch linux is that it sometimes requires manual intervention when updating. If you don’t pay attention, this command might break your system.

pacman -Syu

The solution of course is to diligently check archlinux.org/news for breaking changes. But I obviously forget that all the time. If I have time at all.

Thinking this over, I was reminded of an annoying feature in OS X where if a cron job produced output, it would put that output in an mbox file. As long as you don’t clean up that file, every new terminal will say “You have new mail.” at the top.

Wouldn’t it be great if every new terminal would warn you about upgrading? Wish no more. I did exactly that with a few small scripts.

The first is a script that downloads the Arch RSS feed to a mbox, added to my crontab.

sudo systemctl enable cronie
crontab -e
0 * * * * /home/pepijn/bin/archheadline.py

#!/usr/bin/env python
import feedparser
from email.mime.text import MIMEText
from mailbox import mbox, mboxMessage

feed = feedparser.parse("https://www.archlinux.org/feeds/news/")
mail = mbox('/var/spool/mail/news')
ids = set([m['Message-ID'] for m in mail])

for entry in feed.entries:
    if entry.id not in ids:
        message = MIMEText(entry.summary, 'html')
        message['From'] = "ArchNews"
        message['Subject'] = entry.title
        message['Message-ID'] = entry.id
        mail.add(message)

mail.close()

The second is a script that should be added to your .zshrc or .bashrc depending on your shell. It will check the mbox file for new messages and print a notice to your terminal.

~/bin/unread.py || echo "$? breaking changes."

#!/usr/bin/env python
from mailbox import mbox, mboxMessage

mail = mbox('/var/spool/mail/news')
new = 0
for m in mail:
    if 'O' not in m.get_flags():
        new += 1

mail.close()
exit(new)

To get rid of the warning, open the mbox with a mail viewer. Probably mutt, knowing a few Arch users. I simply run mail to mark the messages as old, and optionally actually read them.

mail -f /var/spool/mail/news
p 1 # print first message
q   # write mbox and quit