All RPGs and Storygames by Tod Foley are now available at DrivethruRPG. Bring these games to your table!
Select which image derivates should be exposed on images via metadata properties. Can be used w/ JSON:API etc.
Allow adding a base64 encoded representation of image derivates to its metadata properties. Can be used w/ JSON:API etc.
Download this in-depth report and learn how Redis Enterprise can power your next worldwide game launch. ...
Obligatory recap: I’ve read about a system for creating urbancrawls (similar to hexcrawls but set in a city) from The Alexandrian. I had also been enjoying the Sorcery! gamebooks by Steve Jackson and their strange magic setting. Enter this series of articles, where I use The Alexandrian’s urbancrawl system to design my own urbancrawl with a strange magic theme.
- Part 1 of this series
- Part 2 of this series
- Part 3 of this series
- Part 4 of this series
- The Alexandrian’s Urbancrawl series
- Steve Jackson’s Sorcery!
We left off last time with:
- a list of districts
- a definition of what a neighborhood was
- a list of layers we were going to use
- a rough map
- a list and brief description for all neighborhoods.
Here’s a recap of our layer list from way back in part 1 and a few notes/additions along the way:
- Gazetteer/Landmarks: Done! This was part of the last few articles. We got a Gazetteer layer entry for each neighborhood along with the description for each.
- Gangs: This is getting broken down into two separate layers, a guards layer and a gangs layer. The gangs layer will be a little different than most others because I want “contested” neighborhoods but this wasn’t worth making multiple layers for since I want many small gangs all over the city. In this case I’ll note each neighborhood with a “primary” gang, but neighbor gangs may also be encountered there as they vie for territory.
- Guards: While the guard forces of the city are technically independently contracted mercenaries (and thus sometimes come into conflict), there is no overlapping territory, so outright conflict is more likely to be result of some key event rather than regular clashes between say the city guard and the temple district guard.
- Heist: This promises to be one of the most difficult layers to make. While some layers we can get away with being handwavy or templaty, this one looks to be 24 actually planned out 5 room dungeons or bigger.
- Weirdness: This is another layer that can’t be handwaved or templated. Each one of these has to be unique.
- Aboleth: This layer is all plots and minions of the aboleth overlord. They’re not on it. Like the example for the Alexandrian’s articles where Count Ormu is lord of the vampires, and once you collect enough vampire clues you can confront him, the aboleth is somewhere on the map but isn’t up for random encounter or hunting down until a certain critical mass of interruption of their minions.
- Patrons/houses/politics: Like the gang layer, this layer is high contested/populated by multiple groups with a “primary” house or independent noble that is technically tasked with oversight of the neighborhood, but with the possibility of encountering representatives from other houses there as well.
- Shops: Though I don’t know how much use it will get, I want to put a unique/special shop in each neighborhood for PCs to find.
- Ruins/undercity: The event that destroyed most of the university district also destroyed buildings all over the city. In addition, there are numerous entrances to the sunken levels underneath the current city.
- Bugs and fungus: I’ve got an idea for a bug themed “boss critter”. This means I want bugs to have their very own layer (otherwise it makes it harder to amass the clues needed to start hunting down the bosses. Before this concept, I had toyed with the idea of adding slimes to this list, but with bugs in their own layer, I’m not sure I see a value in a fugus/slime layer. They’re just too inactive and uninspiring for anyone to go hunting for them. Unless maybe a cult of Jubilex. Hmmmm…
- Cultists: I have this idea that the area was populated by some reclusive people before the city was built. They tried to stop further building before it got too big but were sent packing. Their descendants have infiltrated the city and work to bring it down or at least return it to their possession.
Some additional thoughts I’ve been kicking around:
Levels: Since this is an “open world” game, such that it is, I’m a little worried about PCs wandering into locations/encounters etc… that are far more than they can handle. I want it to be possible, but not something that happens regularly. To deal with this, the DC to find points of interest will scale with the challenge it presents. This will include an additional bump if what they’re looking for is kill on sight (which doesn’t include that many items anyway).
Roster: While some layers will be carefully keyed with every item on them premade, others don’t need to be so meticulously planned. With a fw planned points of interest, the rest of the layer can be handled by a roster of NPCs (some generic some specific) and maybe some on the fly 5 room dungeons. Thus most layers will need at least one roster, and some several.
Random encounters: I want random encounters in the city. Most, if not all of the encounters here can be pulled from the rosters of the various layers with just some differences in the encounter list for each neighborhood based on which layers are active and which are common and uncommon there.
Contents: I want to be sure to include a variety of types of items on the layers list. It would be boring if say, everything on the bugs layer was just bugs to fight. Here are the basic categories I want to be sure to include:
- NPCS: Using the very old school definition here which encompasses both (demi)human and Monsters, etc… Some of these will be best dealt with with diplomacy, others by skill checks, others by combat, but I’m not going to shoehorn which is which. Let the players figure it out.
- Tick/trap/puzzle: Probably not as common as in a dungeon setting, but it wouldn’t do to lease these out.
- Point of interest: Just some fun/notable scenery
- Combination: These come in three sizes, a single room/location, a small location (like a 5 room setup), and a large location (which will probably have to be pre-planned)
So now I know what I’m making, and how I’m making it. It’s time to stop procrastinating and eat this elephant. So next time I’ll have a layer roughed out and we’ll go from there. Wish me luck!
When sending email from your application, using queuing process can reduce the application response time and increase speed.
By sending the message to queue instead of sending directly at the end of server response, you may achieve better user experience. Once messages are in queue, you just need a scheduled cron task to initiate scheduled email sending.How ?
Queuing is simple in Drupal 8
This week's roundup includes a look at the Switch Lite announcement and Valve's experimental discovery mechanisms, as well as some picks on 2019's best games so far, Dragon Quest Builders 2, & more. ...
Display a very simple sitemap filtered by the Menu Manipulator module.How to use
- Place the Menu Sitemap block in Admin > Structure > Block layout
- Enjoy! :)
Homebrew setting creation is an important facet of the RPG experience. For many of us, world creation is what got us interested in RPGs in the first place. But whether you’re designing a setting for the first time or the hundredth time, there are some simple tips that can make the experience more productive and enjoyable.Getting Started
The first step is don’t be intimidated. Playing published RPGs can give you the impression that hundreds of genius ideas must be put to paper before the game even starts. This is not the case. Many RPG settings are developed organically through play and experimentation, and yours should be too. So focus on having fun, don’t be over-worried about originality, and let the creative process take its course. While there is preliminary work to do before playing, it’s probably not as much as you think.Think of the Aesthetics
A great place to start is thinking in big, broad terms. Be inspired by your favorite media, and look for themes and ideas that get your creative energy flowing. Love Ghost In The Shell? Definitely lift some cyberpunk aesthetic. Get pumped about Avatar: The Last Airbender? Some elemental magic and spiritual themes could be good. Genre mash your heart out, and don’t shy away from cliches. Instead, embrace a cliche and put a spin on it. So if your cyberpunk world is full of neon tubes, corrupt corporations, and elemental masters, maybe the strongest elemental masters are the most powerful CEOs! And the more powerful your magic, the more neon tube cybernetics you have to contain all your power flowing through your veins. Maybe elemental magic isn’t just for fighting; it powers all sorts of technology and daily life, and has become so important, it’s used as currency.Think of the Core Conflict
Every great piece of media, while having a rich world, has a core conflict to explore. This makes the world feel alive, like it’s in motion and taking the players along for a ride. So what’s the big problem in your setting? Connect it to the aesthetics to make things feel cohesive. Maybe in this corrupt magical CEO world, a huge economic crisis has happened and companies are calling in all their debts. They’re forcibly reclaiming magic from the lower castes, and sometimes over pumping so much power out of people, it kills them. A classic haves and havenots story tailored to your world design. But don’t forget to connect this conflict to the players! In order to make it seem real, this problem needs to affect the players’ lives, their allies’ lives, and day to day struggles. Perhaps the players are all debtors trying to escape possibly lethal debt collection, and trying to train, focus, and gather enough elemental magic to pay off the creditors. Or maybe the players are actually a paid team of debt collectors, and have to journey to dangerous places and reclaim what “belongs” to the corporation, dealing with the moral struggles that entails.Think of Factions
This is my favorite part of setting creation. The world really starts to feel fleshed out when you think about the social factors at play. The important thing to remember when creating factions is that dynamics matter much more than detail. It’s not so important to think about what a faction wears or eats or what language they speak, unless that somehow directly relates to the conflict and how that faction interacts with others. We already have the idea of two groups: haves and havenots. And we know one is oppressing the other. So what are some more interesting dynamic ideas to come out of this? Perhaps the havenots use extensive smuggler networks to move magic around and keep it hidden from the collectors. Maybe the havenots aren’t as educated or well trained, making it hard for them to produce useable elemental magic on their own. Or better yet, maybe the magically gifted among the havenots are forcibly recruited into wealthy society and removed from the people, keeping the economic disparity strong. This means gifted people hide their talents to try and support their communities from the sidelines.Embrace the Unknown
You’re not going to answer every question about your setting while you brainstorm it. A lot of it is going to work itself out naturally as you play. What does it look like when the wealthy extract a magically gifted person from their neighborhood? Maybe you can brainstorm a whole session around it, and play it out to fill in the details. Or better yet, maybe a player has that sort of event in their backstory, and they can contribute their own ideas on how and when that happens. Don’t be afraid to let the players contribute! In fact, you can invite the players to contribute to this whole process, because great ideas can come from many minds when everyone respects and builds on each other’s contributions. My game Heroic Dark makes use of this fact, and makes setting creation into a structured, collaborative process for everyone at the table. The players become invested in the game world, because their ideas are a piece of it, and it makes the dangerous adventures in that world so much more compelling. Everyone is more willing to take risks, face challenges, and do heroic things because they want to see how their and others’ ideas play out in the high intensity story everyone is crafting together.
So after setting creation, it’s important to remember that worlds evolve. As you play the game, the players experience a mix of wins, losses, narrow survival, and tragic deaths. But as the consequences play out, you might find a setting detail is starting to feel vestigial or incongruent based on what has happened. Let the gameworld change! In our sample setting idea, if magic extractions always went unchallenged before, but now the havenots have been pushed to the edge, maybe they don’t take things lying down and extractions become dangerous and violent. This change could lead to another; as the wealthy see their authority challenged, they invent new, more brutal methods of extraction that are harder to resist.Conclusion
Setting creation can be a much more fluid, relaxed, and flexible exercise than you may be used to. Following a stripped down process like this produces surprising results, because when you don’t weigh yourself down with figuring out every little detail and trying to be a genius, your creative juices can really flow. Between aesthetics, conflict, and faction dynamics, you should have a rich and living world ready for a fantastic adventure. By diving in before everything is nailed down, you let the details fill out organically and naturally, instead of arbitrarily making decisions just to put words on a page. But the most important thing to remember is to have fun. This is ultimately a game, not a writing competition, so the best measure of the success of your setting is having a good time.
Defines the following permissions to enable a user to translate a webform's configuration without granting them the 'translate configuration' permission needlessly.
- translate any webform
- translate own webform
DrupalEasy: Demystifying drupal-core-require-dev and drupal-core-strict in the "Drupal Composer/Drupal Project" Composer template
If you build Drupal 8 sites using the Drupal Composer/Drupal Project Composer template (DCDP), then you've likely noticed the development dependency webflo/drupal-core-require-dev. If you're like me, you probably didn't give it much thought the first 20 or 30 times you used the template.
After a while though, I started to dig deeper into the details of DCDP, wanting to be able to understand exactly how it worked and what customizations I may want to make. DCDP was really my first real exposure to Composer, and the more I learned, the more I wanted to learn (as is often the case). My curiosity led me to this drupal-core-require-dev rabbit hole.Some background
First, let's level-set ourselves - when you run either "composer install" or "composer create-project" (which is actually calling "composer install" as well) without the "--no-dev" switch, Composer will install all dependencies listed in your composer.json file in both the "require" and "require-dev" sections (as well as dependencies of dependencies). If you take a look at DCDP, you'll notice that in the "require-dev" section, there is one entry: webflo/drupal-core-require-dev.
So, as most folks who start Drupal 8 projects using the recommended DCDP command listed in the README (composer create-project drupal-composer/drupal-project:8.x-dev some-dir --no-interaction), Composer is installing everything in the "require" and "require-dev" sections - including webflo/drupal-core-require-dev.
What exactly is webflo/drupal-core-require-dev? Well, it is a "virtual" dependency - meaning it doesn't include any code, rather it just includes a composer.json file that specifies the specific versions of Drupal core development ("require-dev") dependencies that are used to run Drupal core tests. The interesting (and sometimes problematic bit) is that webflo/drupal-core-require-dev doesn't specify any versions for non-development ("require") dependencies. If you take a look at Drupal core's composer.json file, you'll see that for the most part, specific versions of dependencies aren't specified - rather a range is.
This leads to the situation where a project built with webflo/drupal-core-require-dev could have different dependency versions (as long as they adhere to the version constraints is Drupal core's composer.json) than what comes with Drupal core if you had just downloaded it from drupal.org.
For example, if on the date version 8.7.0 of Drupal core was released one of the development dependencies was at version 1.3.1, then that is the version that is provided with Drupal core 8.7.0 downloaded from drupal.org regardless of when you download it. But, when using the DCDP as-is, if since the release of Drupal core 8.7.0 the development dependency was updated to 1.3.2, then when the project is installed using "composer create-project", your project will be using version 1.3.2 of the dependency. While this seems minor, it has led to some issues.
Also - be aware that there are different versions of webflo/drupal-core-require-dev for every minor version of Drupal core. So, if you're updating your site from Drupal core 8.6.x to 8.7.x, then you must also update to webflo/drupal-core-require-dev to 8.7 as well. This is the reason the update command for DCDP includes webflo/drupal-core-require-strict: composer update drupal/core webflo/drupal-core-require-dev "symfony/*" --with-dependencies
After learning this, I had an obvious question: what's the advantage of having Composer install updated versions of Drupal core dependencies? The only thing I found was that if you're a core or contrib developer, then it would be useful to know if your code breaks using updated dependencies. I'm hard-pressed to think of another reason when this makes sense. For most Drupal 8 projects, I think it would be beneficial to use the exact dependencies that the particular version of Drupal core ships with. This way, we can be 100% certain that our project has the same dependency versions that the community's testing infrastructure has validated for the particular version. Luckily, that's what webflo/drupal-core-strict is for.
It works almost the exact same way as webflo/drupal-core-require-dev except that it includes exact versions for all dependencies of Drupal core - for both development ("require-dev") and non-development ("require") packages. The exact versions are the ones that have been tested and are included in the "official" version of Drupal core (for each minor version) downloadable from drupal.org. Like webflo/drupal-core-require-dev, there is a minor version of webflo/drupal-core-strict for each minor version of Drupal core.
So, why does DCDP use webflo/drupal-core-require-dev? Well, there's some debate about if it should or not.
As a side-note, if you host on Pantheon, and use their Pantheon-flavored version of DCDP, then you're probably already using webflo/drupal-core-strict.Starting a project with DCDP using webflo/drupal-core-strict
First, the bad news - if you want to start a new project using webflo/drupal-core-strict, you can't use DCDP out-of-the-(virtual)-box. But, there's a couple of possibilities. At first glance, it seems that you could fork DCDP, make the relevant change to webflo/drupal-core-strict in the composer.json file, then use "composer create-project" on your fork. But, this would also require posting your fork on Packagist (which is discouraged), updating your fork's README (for the create-project and update commands) as well as keeping your fork up-to-date with any DCDP updates. I wouldn't recommend this method.
A better option is to use the "--no-install" option of Composer's "create-project" command:
1. Use the recommended command on the DCDP page, but add a "--no-install" at the end of it:composer create-project drupal-composer/drupal-project:8.x-dev some-dir --no-interaction --no-install
This will download DCDP to your local, but not install dependencies.
2. Edit the composer.json file with:
- New project name
- New project description
- Remove "webflo/drupal-core-require-dev" from the "require-dev" section
- Add "webflo/drupal-core-strict": "^8.7.0", to the "require" section (ensure the version matches drupal/core).
- Change the version requirement for drupal/console to: "drupal/console": "^1.0", (to avoid version conflicts)
- Change the version requirement for drush/drush to: "drush/drush": "^9.0", (to avoid version conflicts)
- Remove "composer/installers" from the "require" section (it is already specified in webflo/drupal-core-strict).
3. Run "composer install".
You'll need to remember that when you want to update Drupal core, you'll want to use the following command (instead of what is in the DCDP README):composer update drupal/core webflo/drupal-core-strict "symfony/*" --with-dependencies
If you're not crazy about either of these two options, there is a third (future?) - leave a comment on this issue and ask for webflo/drupal-core-strict to be used in DCDP.Change an existing project from webflo/drupal-core-require-dev to webflo/drupal-core-strict
What if you already have a project based on DCDP and you want to change it from using webflo/drupal-core-require-dev to webflo/drupal-core-strict? Here's some possible ways of doing it:
As always, to be safe, please test things like this on a copy of your project.Method one: manually downgrade dependencies
This is definitely a tedious process. It involves first removing webflo/drupal-core-require-dev using:composer remove webflo/drupal-core-require-dev
Then, attempt to require drupal-core-strict:composer require webflo/drupal-core-strict:^8.7.0
Depending on a number of factors you're likely to get a bunch of "Your requirements could not be resolved to an installable set of packages." messages. How many you get is mostly a result of the length of time since the previous minor release of Drupal core - the longer it has been, the more dependencies have probably been updated. For each dependency listed, you'll need to downgrade it using something like:composer require symfony/yaml:3.4.26
What is happening is that webflo/drupal-core-require-dev allows dependencies to get upgraded outside of the Drupal core release timeline, while webflo/drupal-core-strict does not. So, you'll need to downgrade dependencies that have been updated. You'll have to do it one-at-a-time - try requiring webflo/drupal-core-strict, see the error message, downgrade the offending dependency, then repeat. In some cases, it isn't immediately obvious which dependency needs to be downgraded, or which version it needs to be downgraded to, so be prepared to use the "composer depends" command a few times.
Eventually, requiring webflo/drupal-core-strict will succeed and you'll know that you're done.
There is one major downside to this method though - by requiring specific versions of each dependency, the versions are effectively pinned in the composer.json file. So, the next time you update Drupal core (and webflo/drupal-core-strict), these specific version constraints will conflict with the updated webflo/drupal-core-strict. One solution would be to remove all of these dependencies from the "require" section of your composer.json file.Method two: rebuilding your codebase
If Method one is tedious and precise, then this method is more of a (less tedious) big hammer. Depending on the complexity of your codebase, this might be a better option for simpler projects. In short, make a copy of your composer.json (for reference), then use "composer remove" to remove dependencies on drupal/core, webflo/drupal-core-require-dev, and anything that depends on them. Then, use "composer require" to add back drupal/core and webflo/drupal-core-strict:composer require webflo/drupal-core-strict:^8.7.0 drupal/core:^8.7.0
Then, add back (composer require) all the dependencies you had to remove. Be sure to add back the same versions of each dependency (this includes Drupal profiles, modules, and themes!) to end up where you were when you started. Once everything is back, then you'll probably want to "relax" the version constraints of your dependencies in your composer.json by adding a "^". For example, if you re-add a contrib module using:composer require drupal/pathauto:8.1.3
Then in the "require section" of your composer.json you'll have:"drupal/pathauto": "8.1.3",
This will prevent drupal/pathauto from being updated. So, you'll want to change this to:"drupal/pathauto": "^8.1.3", Method three: delete and update
[One] solution is to modify your composer.json file, attach the same version limit to drupal/core and drupal-core-strict (e.g. ^8.7.3) to limit what [composer update] needs to look at, and then [delete] both your composer.lock and your vendor directory and run "composer update".
One caveat about this method is that it will update everything. Any outstanding dependency updates (including Drupal profiles, modules, and themes) will be applied (unless you constrain them in your composer.json). Here's what Greg suggests:
- Pin your contrib modules that are not updated to an exact version in composer.json.
- Remove vendor and composer.lock, add webflo/drupal-core-strict [to your composer.json], and generate a new lock file [with "composer update"].
- Remove the pins of your contrib modules in your composer.json by adding ^ [similar to the example in the previous method.]
- Run composer update --lock
Is there an easier way to do this? If so, I'd love to hear about it. Let me know in a comment below.Which to use?
So which one should you use? If all your contrib projects are up-to-date, then I'd go with Method 3. If not, then I'd recommend Method 2 or 3 depending on which you're more comfortable with.The future
Of course, in the future, much of this may be moot (for new projects, at least), as there is an active effort to bring an official version of DCDP to Drupal, including a new scaffolding dependency (committed to drupal/core on July 10, 2019!) and something akin to drupal-core-require-dev and drupal-core-strict. To find out more, check out the Composer Support in Core Initiative.
Thanks to Greg Anderson, one of the Composer in Core Initiative coordinators, for his input and review of this article.