2021-05-09

Learning to be a Mentor

This is just a very quick post about the Tabletop Mentorship Program, a scheme run by the wonderful Mike Belsole and Grace Kendall over the last couple of years or so. The idea is that they connect people who do just about anything within the games industry, or who want to, from game design to illustration to podcasting or reviewing, with more experienced members of the community who can help them take their next steps. A mentoring period is over three months, during which the mentor and mentee agree to meet (via an online call of some sort) at least six times, for at least half an hour each time.

After discussing the scheme with a couple of friends, I signed up as a mentor for the January run of the scheme. I must admit that I was somewhat nervous, as I am still close to the bottom of the industry ladder, and wasn't sure how much I could offer, but reassured by the friends, and the information on the scheme's website, I gave it a go.

I was matched with a designer who was working on their first "serious" design (they had tinkered with others, but not got far with them), and we hit it off well on a personal level, and over the three months it was great to see the designer preparing their game and pitch for showing to publishers. They were well motivated and, I think, just needed a little reassurance on a few things and some pointers based on at least some experience of interacting with publishers, which I do have a bit of.

Overall, I found my first time as a mentor to be a really enjoyable experience. My mentee claims I was helpful, and I felt that I learned a lot from the process as well. The scheme also has great support through a Discord server, through which you can get help, advice, or just chat, plus there are regular talks on YouTube (some streamed live, some recorded), interactive discussions, and social meetups.

Applications are now open for the next round of mentorships (which will be the last for this year as the organisers will then be working on restructuring the scheme to be a long-term prospect), and I have already signed up again. If you think you could offer something as a mentor (if you have any experience in any games business related activity, there is a good chance you can!), or would like to find a mentor for yourself (or both, in fact!), it's well worth looking on their website to find out more. Applications for this round are only open until 17th May, so there isn't a lot of time.

2021-04-27

An Ancient Space Station Rediscovered

I was having a clear up the other day and found some components stashed in a pile. Not a playable prototype, or even part of one, but a few elements of one of my early game projects that I was trying to build back in 2014, not long after I started this blog, a game that I called Space Station 7, which was about shenanigans between rival peoples/species on a space station that may or may not resemble something that appeared on TV in the 90's. I have the bones of a rules document in my Google Drive, a basic nanDECK script and associated data file, and a few blog posts discussing my thoughts (you can see everything with the SpaceStation7 tag, if you are interested) along with another, partially-written draft that I never finished, but includes some more ideas I wanted to throw in.

After working on this project for a few months I ran out of steam and inspiration and moved onto other things. For instance, it was early 2015 when I first discovered the 24 hour design contest and shifted a lot of my focus to actually getting games to a playable state quickly, which led indirectly to me getting involved in Playtest UK meetups, and the rest is history.

Nothing wrong with prototypes like this.

So I was clearly biting off more than I could chew at the time. I think the game was heading towards being a mid-weight, Euro-ish design that, if I had managed it, would have certainly had way too many weird bits and exceptions. Either than or it would have been utterly dull. 

I have a lot more experience now (though still have plenty of weaknessed) and finding this stuff has reawakened my interest in the project. Having read through the old blog posts and the rules (such as they are), I think there is still something there that I could work with. 

In summary, what we have is:

  • Action is centred on a space station, but players also have their own homeworlds and colonies.
  • Players have "workers" who are essentially ambassadors and other representatives of their species, which can visit various locations each round to undertake actions.
  • Actions are actually triggered by card play, and "workers" have to be in appropriate locations to take advantage of the card plays (e.g. you need a representative in the Council Chamber to partake in debates and votes).
  • Actions take a while to come to fruition and need to "develop" by playing other actions or simply waiting. Some of these actions might be played face-down as covert actions.
  • Play of actions may be "programmed" each round and revealed in stages.
  • Assassinations (of workers/representatives) happen, but the role of the victim is refilled by the homeworld, so they are not lost for ever.
  • Taking direct actions against other players can result in "grudge" tokens being exchanged, indicating tensions between worlds, and can make certain other actions harder or easier.
  • A was also considering a small, semi-random, semi-set deck of cards to provide a series of events that provide a scenario or plot arc for the game, a bit like having an external threat-of-the-week in a TV show to interact with while they go about their regular intrigues and shenanigans.
I'm planning on sleeping on this and seeing if the Enthusiasm Beast takes over. I have plenty of other projects to be working on, but one more can't hurt, can it?


2021-04-09

Researching The Artifact

So, another game design project I have ongoing at the moment, and another collaboration. This one is working with Alex Cannon, who says I am allowed to blog about the project as long as I make him look good. I will do my best!

This game came out of one of the fabulously intelligent and charismatic Alex's occasional Twitter threads of game ideas, after I responded to a short idea along the lines of "friendly worker placement", where players maybe get benefits in some way from nearby workers placed by other players.  I couldn't help thinking about scientific research where, while research groups can be intensely competitive, the whole field relies heavily on the output of others. You know, the whole standing on the shoulders of giants thing. Or at least standing on each others' chairs.

We had a chat and after bouncing various thoughts around, we got to the idea of teams of scientists working to investigate a big alien artifact; a crashed space ship or something. The idea is to find ways to exploit the various forms of technology found in the artifact and earn fame, fortune and victory points!

A first shot at manipulable components, even if it wasn't actually a playable game.

As we live something like 100 miles apart and have been pretty much locked down due to Covid-19 restrictions, we needed to collaborate online. Our method so far has been to make notes and write rules in a couple of Google documents, alongside a spreadsheet for component data, all of which we are both able to edit. I built a set of nanDECK scripts for the various components, and can run those quickly to generate files that can then be uploaded to a Screentop.gg project that we both have access to. It means that I currently have to take action any time we want updated components, but unless there is some structural change required, it takes only a few minutes from changing the spreadsheet to being able to play.

Over the early iterations (we have been having a discussion, and usually a play of whatever we have set up at the time), we homed in on a few concepts that we wanted to build around, and which we have pretty much stuck with even though a load of other things have changed...

  • There are no victory points in the game; you win by being the first to achieve three objectives (in the form of "projects".
  • There are no spendable resources to gain and then spend; instead you just have access to levels of knowledge according to the positioning of your researchers (workers) and the layout of the board tiles.
  • On every turn, you add a tile to a central layout, with domino-like placement rules and can place or move one of your researcher tokens.
  • Access to knowledge via your researchers on tiles allows you to play cards to a personal tableau, representing your personal developments and special resources and capabilities.
Mid-February. The round markers are movable player tokens
and the squares are knowledge "resources".

We almost immediately simplified the tiles so that the ones that get played every turn are essentially two-square dominoes, largely for simplicity's sake, but we haven't really felt the need to change this, apart from having big tiles to add to the array when you complete a "project" (one of the objectives). 

The main changes apart from that have been to evolve the development cards that you are playing along the way, gradually adding more variety, restricting the number of developments you can have in your tableau, introducing a mechanism for upgrading from one development to another, and adding special actions to most of the developments. All this now means that there are all sorts of additional actions you can do on your turn, and you will end up losing access to some of them as you change your priorities in upgrading and rebuilding.

Up-to-date, with a three-player game and a lot more going on.

There is still a very long way to go in developing the game, but it seems to be evolving its own character and challenge. Last week we hit a milestone in having our first test play that involved a third player. While this definitely revealed a few shortcomings, as would be expected, our big takeaway was that the game did not completely collapse when played by someone who didn't design it. 

One of the most interesting points made by our third-party tester was that the game felt strategic but not tactical, and it that maybe there should be a better balance between the two -- or at least we should think hard about whether we want a game like that.  The observation was that to a very large extent you could make a plan early in the game, and then execute that plan, and the challenge was to complete the plan as quickly as possible, with minimal concern for what the other players were doing.

This is all a matter of perspective, as while the other player was executing his plan, Alex and I were getting in each others' way a bit, but the point stands: there was a different experience for different players and, at the very least, we need to decide if we are OK with that. And if we are not (in general, wildly different experiences between players might indicate a problem), we'll need to think about how to address it.

Did I make the talented and likeable Alex look good enough in this post? I guess only he will be able to rule on this. 


2021-03-29

LCR Redux... Maybe?

You may have come across a simple dice game, usually known as LCR, or Left-Centre-Right (or, for that matter, Never Say Die, which was the version I was introduced to as a kid).  The idea is that there are three dice (usually three, anyway), each of which has three faces that are either blank or have dots on, while the other three sides bear markings to indicate 'left', 'centre' and 'right' respectively.  Each player starts with a pile of chips (or money, if you are feeling saucy) and, in turn, rolls the three dice.  Blank faces (or dots) do nothing, but the letters indicate whether to pass a chip to the player on the left or right, or into the middle of the table.  The last player with chips remaining is the winner -- and, if money is at stake, claims the central pot.

I have a fistful of LCR dice, acquired several years ago,
that have stars instead of "centre" for some reason.

This can actually be quite fun,  although, as you can see, there is no element of player skill or choice involved in the game.  You just sit there, roll dice and shuffle chips around, and then somebody eventually wins.  The neat idea is that the flow of chips to the centre means that the game steadily moves towards an end (on average, a chip should go to the centre on every other player's turn) and won't get stuck in endless chip shuffling. The other neat idea is that even when you are out of chips, there is a chance someone will pass you one and you will be back in the game.

I have been thinking about this and wondering how I could build on the basic idea of LCR to create something that actually functions as a game, with actual player choices to make.  This clearly doesn't need deep decisions: I would want to keep the fast flowing nature of the original, but if each player had at least one choice to make each turn, it would be great.

So, some general thoughts on this...
  • Perhaps, instead of passing chips around, it is dice that get passed.
    • Or dice and chips.
  • There could be multiple coloured dice and one of the objectives could be to collect a set of one colour.
    • I prefer to not rely on colour, but sometimes it can't be helped -- and anyway, as this game would require custom dice, there could be a shape on each face to help with differentiation.
  • Maybe a real-time element, with more than one player able to be rolling dice at any given time.
    • A real-time part to the game can substitute for decision making (at least to a point) as the game effectively becomes partly a dexterity game. 
  • Possible decisions to make:
    • How many, and which dice to roll at any given time.
    • Who to pass dice or chips to.
    • Trying to collect sets of dice faces.
    • When to "bank" something.
    • Taking an action to end the game, and timing when to do that.
  • Whichever way, I think the game should have (most of) the simplicity and pace of the original.
Not really getting any closer to turning this into something, but I figure that if I at least write some of this down and publish it, it might be more likely that I do further work with it. That said, the amount of game ideas over the years that I have posted about once or twice but didn't go anywhere are extremely numerous.

Just for a bit of fun though, the dice themselves suggest some alternate uses -- and thank you to assorted Twitter people for bouncing more ideas around. For instance...
  • Dice with "left", "right" and "★" (as well as the colours) on them might suggest a fighting/boxing game, either battling another player or trying to defeat "opponents" represented by cards.
  • ...Or maybe something with a "Space Invaders" vibe, either with a similar mechanism as the boxing idea or with space ships actually moving on a board.
  • ...Or some other retro-arcade type game, like the ones where you are trying to follow a winding path or dodge oncoming obstacles.
  • ...Or Tug-of-War, with a rope being pulled left and right.
  • ...Or something related to Twister. I think there is already a dice-based Twister game you play with your fingers -- but right now I can't be bothered to research.
  • ...Or even a Yahtzee-style set collection game. Mind you, that is pretty much an option with any type of dice.
So there, a post with no conclusions or anything actionable. I'll think on this some more and write again if anything comes up. Input welcome! 😀

2021-03-10

Making Faces in nanDECK

The other day I was working on a game in Screentop, and decided that I wanted the dice I had in it to be spotty dice rather than the digit dice that are the default. All this requires is uploading an image which shows the required faces (this works for any custom faces). If my image has a transparent background, then you can set the fill colour for the die to be whatever you want and then use the same image for a range of different coloured dice.

I figured that nanDECK would be an effective way of constructing the image, and it didn't take long to make the script. I thought I would share my script here as a kinda worked example. I'll break the sections of the script down with discussion about what each section does.

So, here goes...

BORDER=RECTANGLE,#000000,0,MARKDOT
PAGE=21,29.7,PORTRAIT,HV

These lines are just boilerplate stuff that I put at the top of all my scripts, formatting a page for printing or creating a PDF at A4 size, with crop lines added. It's not necessary for what I am doing here, but I left them in anyway.

DPI=200
CARDSIZE=5,5

The next bit of the boilerplate, but a bit that I modify as necessary. My usual card size is 6.3 x 8.9 cm for poker-sized cards, but I want squares this time. As I am just making an image, the size doesn't really matter, so 5 cm square was just a convenient number.

[DotColour]=#000000
[CircleColour]=#999999
[TransparencyColour]=#ffbbff

It can be useful to define variables rather than using numbers in the guts of the code. Specifically the [DotColour] one meant that I could run the script once to generate an image with black dots, and then change the value (to #ffffff) in order to run again and output white dots.

The [TransparencyColour] is helpful because in nanDECK you can define a specific colour to be replaced by transparency in an output PNG file. As long as you select a colour you don't want to use in the actual image (I'm using a pink here), all is good.

RECTANGLE=,0,0,100%,100%,[TransparencyColour],[TransparencyColour]

So this is just filling the "card" with a solid background field of the colour I selected for the transparency.

ELLIPSE="1,3,5",2,2,1,1,[CircleColour],[DotColour],0.02
ELLIPSE="4,5,6",0.5,0.5,1,1,[CircleColour],[DotColour],0.02
ELLIPSE="4,5,6",3.5,3.5,1,1,[CircleColour],[DotColour],0.02
ELLIPSE="2,3,4,5,6",3.5,0.5,1,1,[CircleColour],[DotColour],0.02
ELLIPSE="2,3,4,5,6",0.5,3.5,1,1,[CircleColour],[DotColour],0.02
ELLIPSE="6",0.5,2,1,1,[CircleColour],[DotColour],0.02
ELLIPSE="6",3.5,2,1,1,[CircleColour],[DotColour],0.02

That's the guts of it. You can look at a standard spotted die face as having seven locations where spots can exist, and each spot is present on some faces, so this sort of arrangement does the job.

It's worth noting that this is just outputting images for faces, without any thought about where on the die those faces are placed. For instance, the standard die arrangement of opposite faces adding up to seven is not covered here, but at present, Screentop appears to simply treat a die as a randomiser, with no physical analogue, so this point is irrelevant for my current use case.

DISPLAY="dottydice.png",1,6,3,,[TransparencyColour]

And that last line outputs the six faces to a single PNG image, three "cards" wide, converting the colour we specified earlier to transparency.

And here's the output:

Black on transparency. Feel free to take and use if it is of any use to you. CC0 v1.0

And, as an alternative, re-running the script with the white version of [CircleColour] gives:

White on transparency. Feel free to take and use if it is of any use to you. CC0 v1.0

I don't know if this sort of thing is helpful or interesting, but here it is anyway. 


2021-02-27

From Spreadsheet to Screentop via nanDECK

 I have an old card game project that has been languishing without attention for a few years with the working title Monster Invasion, which was a solitaire game (which I could probably make into a cooperative multiplayer game) that I used to enjoy playing back in the day. I recently decided to give it a look again and see what I can do with it, which gives me a perfect opportunity for me to demonstrate my current workflow for building a virtual prototype on Screentop.gg, a 2D virtual tabletop that I am learning to love, with the wonderful nanDECK for creating the card graphics.

I'm not going to go into every detail of how this all works, but hopefully will give you a few pointers if you want to work in this way.

The state of the game as I got back to it was a nanDECK script taking data from a CSV file. This was last worked on in 2017, and I've developed my way of working quite a lot since then (even ignoring the shift to virtual prototypes), so my first task was to update the data source. nanDECK is capable of drawing data directly from a Google spreadsheet, as long as the spreadsheet has been shared appropriately (there are details of how to do this in the nanDECK documentation), so I imported the dats, made a couple of tweaks, and shared as appropriate.

My card data in a Google spreadsheet, all ready to go.

If you can see the image of the spreadsheet above, there are probably a couple of things to draw your attention to or at least explain. At the top right is the number 55; this is calculated as the sum of the values in the "Quantity" column, and I find it helpful to have something like that for my reference as I make changes. At the bottom is a line for a card back and a set of nine "blank" cards; this is to help me later build a card image for import to Screentop.gg later on. When I am working with physical cards it is convenient to work in multiples of nine, which is a good number to print on a single A4 page, and coincides nicely with a standard deck size for manufacturing purposes if we get that far. On Screentop I find it convenient to have sets of 55 cards in a five-by-eleven grid, which allows me that same number of cards plus a slot to use as a card back which, if I pad appropriately with blanks, I can make always appear in the last slot of the image.

As an aside, a similar strategy works well for Tabletop Simulator, though typically you use the final slot for a "blanked out" card face. Tabletopia required individual images, which are also easy to set up using the same tool chain, but I'm not doing that today.

As you may know, nanDECK is a system for building cards (and other game components) using a scripting language that allows you to have huge amounts of control if you want it. There is a "visual" mode to the system that I have never spent any real time trying to use, and I gather that works well for some people, but I can't offer advice on this. 

OK, so the nanDECK script. I'm not going to show you the whole thing here, but can show you some of the bits that are relevant...

The first part of my nanDECK script.

A few comments on this first part of the script, assuming you can see the image above...

The first few lines are there primarily for when I want to output a printable PDF document, but an important point here is line 3, which defines 'DPI=140'. This defines the resolution, and thus the file size of the output. Normally for printing purposes you might want to work with about 300 DPI (dots per inch) to get a high quality output, but for virtual prototypes you may have file size limitations, and so may need to reduce the resolution. In the case of Screentop, the limit is an image size of 4096x4096 pixels, and to fit within that constraint I need to either reduce the resolution to about 140 DPI as I have done here, or go for a slightly higher resolution and make the output image a more square shape than I have done.

Line 9 is the link to my spreadsheet. nanDECK is smart enough to recognise that this jumble of characters is a Google spreadsheet ID and acts accordingly.

Lines 11 to 20 define icon images to associate with the letters I am using in the "icons" columns of my spreadsheet. 

Lines 22 and 23 (and the earlier line 6) are a habit I got into long ago of printing a version number onto prototype cards so I can tell that I am using the set of cards that I mean to use -- and this can be important with a game that I am iterating over and revising rapidly.

Then at the bottom I start off the definitions of the actual cards, using an IF structure to select options according to the "CardType" column in the spreadsheet.

After skipping a few lines, here's the end of the nanDECK script.

Towards the end you can see the card back being made by drawing a coloured rectangle at line 55. I have got into the habit of using two-colour radial gradients like this (with various colour mixes) for place-holder card backs, sometimes with text over the top if that seems appropriate. I find them sufficiently pleasing for minimal effort.

Finally, line 60 is where the magic happens, outputting a single image file for cards 1 to 55 (i.e. all of them), arranged in a grid 11 cards wide. 

So, if I validate and build this script, I end up with a nice image of all my cards...

And here we have the output of my script: a big image ready for upload.

So, on to the next tool in the chain: Screentop.gg...

Screentop is a bit of a work-in-progress at the moment, but it is very useful as it stands and is being actively developed and supported. I like it because it does enough for most of the projects I am working on, and is far less demanding on computer resources than its 3D cousins, and just about anyone can join a game from their web browser if I send them a link. On the other hand, there are a few odd quirks to get past. One of these scares off a lot of people: rather than having intricate GUI elements, several of the tasks you may want to do will require using the "bulk editing" system, which uses a programming language and you need to type code into a window to make your changes. Back on the positives though, there is very useful documentation, which provides bits of code that you can just copy and paste as appropriate for most situations, and this makes it potentially rather less scary than the likes of nanDECK.

The Beginner's Tutorial for Screentop takes you through the steps of creating a deck of playing cards, and you can simply follow that, substituting your personal deck image (as I have just created) instead of the sample one they provide.  The tutorial only uses the necessary cards from the image, but I usually make cards for everything, including the blank cards, which allows for more flexibility and cleverness later, which I will go into shortly.

So, just a few minutes of work and I have a pile of cards, some of which are blank...

Cards now up on Screentop.gg - ready to go!

So the game is more or less playable now in it's present state, though I need some way of tracking two scores: power and threat. I can do that by adding some tokens, adding a little score board and a couple of tokens, or using one of the built-in component types, a counter. Or doing the tracking offline with physical components too, I suppose. I can leave that as an exercise to the reader, as I wanted to just show one little extra thing.

The way Screentop handles graphical assets is that you can upload an image and then divide it into a certain number of rows and columns, which are then indexable sub-assets. This is useful for handling entire decks of cards together or potentially other components like custom dice. (Tabletop Simulator is similar in this respect.) In this case, what this means is that once you have set up a deck of cards (or similar set of components), you can, with just a few clicks, upload a replacement for the graphical asset and it will instantly update the cards.

So, if I want to change the background colour of the boss cards, that's one line in the nanDECK script, and replace the blank cards with a pointless message, that's a quick edit of the spreadsheet. A couple of clicks in nanDECK regenerates the graphic, which I can then upload.

Uploading a fresh asset in Screentop is really quick and easy

And, ta-da!...

An updated version of the game in just a couple of minutes.

This updated version is actually the same session as the one in the previous screenshot, having refreshed the page a few times -- this behaviour is brilliant, but doesn't seem to always work first time. A fresh session would (and did) update the cards straight away.

Anyway, now we're all in place, I can start looking at the game and decide what I want to do with it. Card updates will be absolutely trivial with the basics now in place, so we'll see what inspiration comes. 

I'm not sure how interesting or useful this sort of post is, but I guess if you found it really boring you won't have got to this point anyway. Thanks for reading!












2021-02-26

Possible Future Games of History Past?

One of the things I like doing other than designing and playing board games is reading about history -- albeit slowly; I am not a quick reader and I don't have the attention span to keep going for long periods. Over the last couple of years or so I've been mostly reading books about earlyish medieval England, mostly around the years roughly 900 to 1200 CE, but looking into some other periods as well.  Many of the stories and personalities I read about suggest subject matter for games, and I have a couple of ongoing projects based on these (see The Castle War and Ætheling Business), but I am slowly building up a list of historical things I would like to make games about and I thought I would mention a few of them here.

These are mostly thematic hooks that I would like to work with, and don't yet have more than the vaguest idea of how to implement them, but as I generally have more difficulty attaching a theme or setting to a mechanism than vice versa, so this seems a reasonable starting place, and a list I can go back to if I feel the need to work on something new.

So, some of these ideas, in no particular order... 

The coronation of Henry the Young King
Image taken from Wikimedia Commons, where they 
assert that it is public domain.

Henry, the Young King, son of Henry II of England, crowned as co-king during his father's lifetime, died before he was able to take over the kingdom in his own right. He was part of a failed rebellion against his father, and then ended up touring Europe, racking up eyewatering debt but being a superstar of the tournament scene. This tournament tour thing -- which were more about ritualised, "play" wars rather than the arena-based jousts of movies -- sounds like it could be something interesting to explore as a game, particularly centred around a glamorous young man and his exploits. Maybe players are in Henry's traveling retinue and trying to excel on the tournament field and stay in favour by not outshining their leader.

The town where I live, Wantage, is probably best known as the birthplace of the Saxon king Alfred the Great, but there was a period leading up to the mid-19th century when it was a notorious and wretched hive of scum and villainy. This period came to an end when the town was cleaned up by a priest, the Reverend W J Butler, who encouraged and oversaw a period of building and regeneration, and many of the finer buildings in the town are directly linked to him. I would love to make a game about this period of Wantage's history, but make it so that it is reasonably accessible to non-gamers -- it would be great if it could be sold at the local museum. I kind of feel that I want this to be a tile laying game of some sort.

Much further back in time, the Second Punic War was the one with Hannibal and his elephants rampaging around what is now Italy and causing problems for Rome. There were three major pitched battles fought on Italian soil, all historically won by Hannibal's forces, but he never quite managed to finish Rome off. In each of these battles, Rome fielded a fresh, full-strength army, while Hannibal had a dwindling portion of his original army, bolstered by whatever allies he had been able to rally to his cause. My plan is to make a game (probably a card game) where players compete over these three battles; the Rome player always starts at full strength, but the Hannibal player loses resources each time. If Rome wins any of the three battles, that player wins the game, so the aim is largely to make each of the earlier battles more costly for Hannibal than necessary.

Back to Saxon times, Æthelflæd was a daughter of Alfred the Great, who was married to the lord of Mercia, after whose death she continued to fight to reclaim her kingdom's lands from the occupying Danes, and alongside her brother, King Edward the Elder, made great progress in returning chunks of England to Anglo-Saxon control. One of the sources I have read tells of how Æthelflæd launched raids into the Danelaw to liberate relics of saints from the occupied areas in order to return them to safety, and that aspect of her story is one which appeals to me for making into a game. This could actually work as a solo challenge game, or maybe an asymmetric 2-player thing.

A few decades later, in the reign of Edgar the Peaceable, there was a period of monastic reform in England, where the various abbeys and monasteries were... strongly encouraged, shall we say?... to adopt the Rule of Benedict for their practices. One book I read on this period paints this as a case of the king promoting this in order to ensure that all the monks were praying in the "correct" way as part of a national defence policy. After all, what is the point of having swords and armour if you don't also have the favour of The Almighty? There has to be a game in that reform process, which sounds again like it might be a solo game, but I don't have any clear ideas yet here.

Finally, back to the mother of the aforementioned Young King, Eleanor of Aquitaine. This was a woman who was a Duchess in her own right for most of her life, married to the King of France, and then the King of England, went to the Holy Land on Crusade, had three of her sons crowned as kings (two reigned in their own right), spent 16 years imprisoned by her husband, who she survived, living on into her eighties, influencing European politics through her own actions and her offspring pretty much to the end. I don't have a clear idea of what part of her story to build a game around yet, but I'm thinking about it...

I have no idea what, if anything, I will do with these thoughts, but I am sure the list will grow longer. I am up for collaborating on some of them, if anyone I gel with fancies a try; and if someone beats me to making some of them, that is cool too. Ideas are just ideas, and useless until they are acted upon -- and these are only half ideas.