All RPGs and Storygames by Tod Foley are now available at DrivethruRPG and RPGnow. Bring these games to your table!
After having read several great articles on Mike Shea’s blog, I picked up his book The Lazy Dungeon Master. It’s a fast read, and worth the $5.99 asking price, (It’s around 60 pages and mostly about common things DMs spend a lot of time prepping that they don’t need to and how to streamline them, supported by a pretty cool survey he collected about DMing.) In his book, Mike talks about the minimal level of prep required for locations and gives (among others) this example location:
The Saltmines: Former center for the town’s industry, now closed down when they found a dark power buried deep within. Leads from Yellowtop to Ashland Fortress.
What the book doesn’t discuss, and what I was curious about, is how exactly, using Mike’s “lazy” method, one goes about mapping and populating a location like this that has the potential to be the proverbial “twisty little passages, all alike“. So, I emailed Mike and asked how he handled that type of location. He very quickly got back to me and I asked for his permission to share here. Here’s an excerpt: (Link to his product is mine, not his):
On the Lazy Dungeon Master and maps.
If the characters are going to explore a dungeon-type setting, I’ll usually try to steal and reskin a map to fit the situation. Either that or I’ll sketch a very rough stick-figure map that shows how locations are connected.
Since writing the Lazy Game Master I focused a fair bit of time on the idea of building “fantastic locations”. These are the interesting places that characters discover in their journeys and can be connected by various caves, tunnels, or passages. To me, the overall dungeon isn’t as interesting as the individual interesting locations in that dungeon so I tend not to let them get too complicated.
… There might be five fantastic locations in the cove interconnected by natural water-carved caves. Each location will have a name and three interesting traits (or “aspects”) that the characters can investigate or use if there’s a battle. Here are some examples:
- The Tentacle Pillars: Huge stone tentacles that appear to pierce out of the ground; sinkhole that leads into the tunnels below; old octopus statue sitting on a pedestal that appears very old.
- The Weeping Caverns: Stone caverns eaten away by streams of saltwater; carvings of strange symbols on the walls; illuminated shells of phosphorescent mollusks.
- The Nursery: Submerged oily pool filled with psychic baby octopuses; large channeling crystal piercing down from the ceiling; chained screaming madman on the wall.
Those three come to mind but its early and I can’t think of three more at the moment. Hopefully you get the idea =)
If you poke around on Sly Flourish for more discussions of Fantastic Locations you’ll find more about it including the book of 20 locations I wrote around these ideas.
Hope that answers your questions. …
The two approaches that Mike offers are good ones: swipe a map from elsewhere, or reduce a big complicated complex to a five room dungeon with “you travel east for a while, through a maze of tunnels until you come across . . . “. I don’t have much to say about the first one, except to point everyone to my favorite site for random dungeon generators. But the second suggestion about reducing a big complex to a five room dungeon with handwavey bits between rooms has made me think quite a bit.
You see, I’m not sure I’m quite ready to give up my twisty mazes full of empty rooms, red herrings, and minor treasures just yet.
Maybe it’s nostalgia for the afternoons of lonely fun (which I have just amusingly learned is now called a game’s “solitaire component“) and gold box CRPGS, maybe it’s just me perpetuating the same skinner boxes of my youth where poking into nooks and crannies of maze like passages eventually resulted in a handful of GP until they could be traded in for a new breastplate, but to me half the fun of RPGs is skulking down damp passageways, ransacking moldering garbage heaps and searching areas where the map is weird in hopes of finding secret doors.
Maybe the answer lies somewhere in between the two. In one of his “MegaDungeon Monday” articles, The Angry GM discusses the “encounter space” which by his definition is a piece of the dungeon in which all inhabitants work as a unit. So if you have the stacks of a great library with study cubbies and there’s a wight in the stacks and skeletons in the cubbies, but engaging with the wight will alert the skeletons and they will open the cubby doors and surround the PCs, that’s an encounter area.
This middle ground definition allows for a bit of both worlds. You can create just a handful of encounter areas, each with something interesting in it, but you still get the nooks and crannies to explore, because each encounter area (most anyway) is comprised of a handful of rooms, some of which are interesting, some of which are not, some of which hold secrets and treasure, some of which don’t etc . . .
But, how much exploring and poking about in otherwise uninteresting space to do is really a secondary concern. Because the trivial answer is that you should do only as much of it as is interesting. Uninteresting exploration of uninteresting space is a waste of time and should be avoided. I have indeed played in games where no one did much exploring and if there was space that wasn’t an active encounter, paused only long enough to say: “I loot the room.”, toss off a search check, and move on. It may just be selective memory, but the reason for this was that exploration in these games was boring. Rooms were just a collection of squares, sometimes from a battle map, tiles, or a software program, description was minimal and there was the feeling that if a room contained a statue or a desk it was because it was filler, not because it may have been something interesting to interact with.
So the bigger question is, how do you make exploration interesting, even of areas that aren’t inherently interesting themselves? While I don’t claim to be an expert, there are a few tips I can give:
- Grid maps are counter productive: Grid maps are great for combat, but shitty for exploration gameplay, which is good because it implies that there’s not a lot of reason to painstakingly map areas that you want players to explore, only combat encounters (and if one turns into the other that a very simple map with walls and features of interest is sufficient). Players will naturally imagine areas you describe verbally, in ways that they will not when presented with pictures, and it’s very easy to ad lib and add as much detail as you can improvise with verbal descriptions, which is not the case with drawings.
- Pick a few adjectives: Part of the draw of exploration is immersion, which is enhanced by good description (in fact, a quick search of the stew shows we’ve written articles about using sensory cues to describe things no less than a half dozen times). In this case, I suggest giving a few seconds of thought to the traits of an area (a dungeon as a whole is fine, but you can break it down further if it warrants) and make a back of the envelope (3×5 card) list. Refer to this list often and weave a few of the traits into every description. If that library above is “crumbling” you can describe the collapsing shelves, the piles of tumbled books that fall apart at a touch, the dust in the air. If instead it’s “flooded” you can describe the mold crawling up the shelves, the ankle deep black water with floating piles of mush that may once have been books, and the warped damp pages.
- There have to be successes,especially early ones: This goes back to that skinner box I mentioned earlier. Even if you explicitly tell your players that searching and exploring will net secrets and treasure, if they meet with no success while doing so, they’ll stop. On the other hand, even a few small successes will have them searching under the cushions of every moldy couch they find. Of course these finds have to be of value. Finding a handful of coins is (should be) of value to low level characters, but the same isn’t true for high level ones. As such, it’s fine to have these caches be money, but it’s equally useful to hide secret paths, maps, clues and items of strange origin, as well as items which do little except establish flavor, all of which will retain value through characters’ careers. Consider having a small table of incidental loot that can be found in each large area so this is easy to do off the cuff.
So I put it to all of you, because I’m not sure what the end conclusion is. Is poking into nooks and crannies, riffling through the pockets of ancient moldering coats, and sifting through dungeon trash heaps a valid and fun play style or am I biased and it’s more fun to hop between big set pieces? If it is a compelling play style, what are your best tricks to keep it fun and interesting? Like I said above, I’m not the expert on this, so I’d love to hear everyone’s thoughts and techniques.
Drupal Modules: The One Percent: Drupal Modules: The One Percent —Multiple Registration (video tutorial)
Here is where we seek to bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll consider Multiple Registration, a module which gives you the ability to create role-specific registration pages.
Yesterday a project on github was moved, causing Drupal's own build process, and that of many other websites, to “break”. Here's what happened:
- The coder library was removed from github (it's main home is on drupal.org).
- Drupal core's composer.json had a reference to the now non-existent repository.
- Anyone attempting to obtain Drupal by downloading it's source and running composer install couldn't.
- Many other developers who tried to build their websites were similarly left disappointed.
This seems to be a risk that comes with dependency management, and raises the question of should vendor be committed to version control? I'm hoping that this post will help you answer that.
The DC Universe Online dev plans to shut down the PS3 version of the F2P MMO game on January 31st, 2018 in order to 'focus our resources on further optimizing the game for PlayStation 4.' ...
Commerce Paycom integration
Still under active development, description will be updated soon
Here at Aten, we do a lot of work with Drupal, mostly on large redesign projects for nonprofits and universities. We’ve been in the business for a while now (since 2000), and one thing we’ve been talking about for years is the predicament of “buy-maintain-replace” release cycles. Specifically, website redesigns often fall prey to a problematic purchasing cycle that directly counteracts strategic goals.
It goes like this: first there’s a capital campaign, then a big spike in funding to do a redesign project, followed by modest support budget for a few years. During support, things everyone would like to change start to pile up, often beginning as a “backlog” or “wish list,” inevitably becoming a “gripe list” for all the things that are slowly and surely making your website obsolete. Time passes and the gripe list grows. We hear things like, “Our current website is horribly outdated; it isn’t even responsive.” Rather than invest in old technology and continue addressing the growing list of issues, tasks are pushed off for a future redesign. Eventually, there is a new capital campaign. The cycle starts over, rinse and repeat.
If you’re coming from a product background and you’re programmed to value ongoing development and continuous innovation, this already sounds bad. But if you’re from traditional IT management, you might think of redesigns more like purchasing any other technology solution. You buy it, it gets old, you replace it – often with some form of ongoing support between major expenditures. The smaller the support requirement, the more successful the project. Likewise the longer you can go without upgrading, the more successful the project.
The trouble is, your website, app, etc. doesn’t really work that way. Your website shouldn’t just be checking boxes on functionality requirements the way your phone system or workstations do; rather, your website is the public face and voice of your organization. It needs to keep up and tell your story clearly, every day. It needs to evolve as quickly as your organization does. And that requires ongoing investment. More than that, it requires a fundamental shift in the way decision makers think about planning digital projects.
There’s already a ton of fantastic material about the need to adopt a product approach over the more traditional project mindset. One of my favorite posts on the subject was written back in 2015 by the team at Greenpeace titled, “Product teams: The next wave of digital for NGOs?” I especially love this infographic. The illustration is spot on: first, a huge spike in money and time with a brief climax at launch, followed by diminished investment during a prolonged support period with equally diminished satisfaction, all to be repeated over and over again.
Interestingly, this problematic “buy-maintain-replace” cycle actually aligned closely with the release cycle for previous versions of Drupal. For years, timing for the “buy” stage in the cycle aligned surprisingly well with the stable release for major Drupal versions. First, you built a website on Drupal 4. Support phase ensued. Over a few years wish lists turned to gripe lists. Momentum grew behind doing the next major redesign, right on time for the stable release of Drupal 5. Rinse. Drupal 6. Repeat. Drupal 7.
While we were talking more and more about a product approach, the technology actually lent itself to the project mindset. Quick example: retainers are a big part of our business at Aten, and have been important for helping us support clients in the product approach. With retainers, clients invest consistently in their digital platforms over the long term. We identify strategic priorities together, maintain a backlog, organize sprints and deploy iterative releases. But with past versions of Drupal, an organization still needed to invest heavily for major release upgrades. At some point in the cycle, there were diminishing returns associated with ongoing investment in an outdated system. We started prioritizing tasks based on the fact that a large redesign was looming. We said things like, “Let’s just wait on Drupal 7 for that.” In many ways the underlying platform was promoting a “buy-maintain-replace” development cycle. The product approach was still valuable, but hampered by inevitable obsoletion of the technology.
Enter Drupal 8.
With Drupal 8, there’s a lot to be excited about: configuration management, component-based theming, improved performance, content moderation, modernized development tools, support for API-first architecture, and the list goes on. But I want to focus for a minute on Drupal’s release cycle.
Drupal’s vastly improved upgrade path is a huge win for the platform and a major reason organizations should consider migrating to Drupal 8 sooner rather than later.
With past versions of Drupal, major release upgrades (i.e. D6 to D7) required a significant development effort and usually constituted a major technology project. As I’ve touched on already, upgrades would typically coincide with a complete redesign (again, buy-maintain-replace).
With Drupal 8 the release cycle is changing. The short, non-technical version is this: Drupal 8 will eventually become Drupal 9. If you stay up-to-date with underlying changes to the platform as it evolves, upgrading from 8 to 9 should be relatively simple. It’s just another release in your ongoing development cycle.
With Drupal 8, an organization can invest consistently in its digital platform without the problem of diminishing returns. As long as you adopt the product approach, your platform won’t become outdated. And that’s fantastic, because the product approach is what we’re all going for – right?
Resources and Related Reading:
- The product approach to building a website (from atendesigngroup.com)
- Product teams: The next wave of digital for NGOs? (from mobilisationlab.org)
- Drupal 9 and Backwards Compatibility: Why now is the time to upgrade to Drupal 8 (Angie @webchick Byron via slideshare.net)
- Making Drupal upgrades easy forever (from dri.es)
Note: this is a back-end utility module with no user interface. All interaction with the module is currently handled through Drush unless a module referencing this as a dependency adds additional functionality.High Level Overview
JSON Content is intended for importing and exporting (coming later) content while minimizing hurdles related to interrelation of content. All content for import and export is formatted in a JSON structure parallel to the entity value arrays to make extending the data as simple as possible.
Drupal 8.4 is here! The most current minor release of Drupal 8 officially came out on October 4. This release contains lots of changes that push Drupal 8 forward in some big ways, but what are those changes and what do they mean to you?
The changes introduced in Drupal 8.4 affect everyone from Drupal developers to content administrators and site owners. I’ve broken things down into four categories, and we’ll cover the high points of each one. If you’re interested in really digging into the details, check out the full release notes available on drupal.org.Security
The initial release of Drupal 8.4 doesn’t contain any major security updates that make it a mandatory update in the hours, or days, immediately after release. That being said, this is still an update that is critical for site security because as soon as a new minor release of Drupal comes out, security issues in previous minor releases are no longer patched.
I recommend updating to Drupal 8.4 as soon as possible because there is always a chance of a critical security release. You don’t want to get stuck dealing with the complexities of updating from Drupal 8.3 to 8.4 when you’re also racing the clock that starts ticking when a security vulnerability is made public.Browser Support
Drupal 8.4 made some major updates to the versions of Internet Explorer that are supported out of the box. Previously, Drupal supported Internet Explorer 9 and up. Since Microsoft discontinued all support for Internet Explorer 9 and 10 in April of this year, Drupal has followed suit and will only be supporting Internet Explorer 11 moving forward.
No need to panic yet though - your site won’t cease to function in Internet Explorer 9 and 10 as soon as the 8.4 update is implemented, but bugs related to those browsers will no longer be fixed. Starting in Drupal 8.5, which is currently scheduled for release in March of 2018, existing workarounds for these browsers will be removed. This will impact every site differently, depending on how much support your frontend provides for these older browsers, so start talking to your developer now about the best approach for your site.New and Updated Features
Drupal 8 introduced the idea of experimental modules in core. These are modules the Drupal core team has decided provide valuable functionality and should be included in core but still need testing. Many of them can be used in production releases without any issues, but, until they are officially declared stable core modules in a minor release, there may be breaking changes or non-existent upgrade paths as new minor releases of Drupal come out.
Quite a few notable modules were moved from experimental to stable status in Drupal 8.4, so I’ll provide a quick rundown here.
Datetime Range - Dates are challenging for web developers. Especially when you start dealing with things like ranges and events that span time zones. The Datetime Range module is another great tool in the Drupal developer’s toolbox. The module makes managing date and time ranges and integrating them with other parts of Drupal, much simpler.
Layout Discovery - There isn’t much to see on the frontend with this module, but it’s a really big step forward for Drupal core because standardized layout systems have never been possible with Drupal in the past. This module sets the groundwork for a common layout system across core and contributed modules.
Media - Finally! Media in Drupal core! This is a huge addition and one that will affect the team at Elevated Third in a big way because we have leveraged the contributed Media suite of modules very heavily thanks to its ability to provide a centralized media library that makes media management a breeze for content admins. Transitioning from the contributed Media module to the core Media module will bring it’s own set of challenges, but the good news is that transition does not have to happen immediately.
Inline Form Errors - This is a great little module we’ve used on quite a few sites to make the admin experience better. With Inline Form Errors, we’re able to quickly implement a system for providing users feedback when they fail to complete the necessary actions in a form.
Workflows - This is another piece of functionality lots of Drupal users have been craving. In the past, our team has leveraged the Workbench suite of modules to provide content workflow capability, but now, with Workflows in core, we have the groundwork for providing more advanced content administration experiences without the need for additional contributed modules.Behind the Scenes/Developer Tools
In addition to everything we’ve already walked through, Drupal 8.4 implemented some major changes under the hood that are worth knowing about. These changes most directly affect developers but impact anyone involved in the Drupal ecosystem because they significantly increase the complexity of this update over previous Drupal core updates.
Symfony updated from 2.8 to 3.2 - When Drupal 8 was released, you probably heard a lot about Drupal “getting off the island” and embracing the standards and practices of the larger PHP development community. Incorporating Symfony into Drupal core made this transition much simpler than it would have been to write all of the required backend components from scratch. Symfony is a PHP framework that provides a huge amount of functionality to Drupal under the hood. Just like Drupal, Symfony also has major releases, and Drupal needs to be sure it’s leveraging the latest and greatest from Symfony. This kind of update won’t often happen because Symfony releases major versions every two years. When a Drupal minor release does incorporate a major Symfony version update, the complexity of the update does increase.
Drush support - Drush is a command line tool a huge number of Drupal developers leverage to make day-to-day development work much more efficient and easier to manage. It is an invaluable tool for our development team here at Elevated Third. With Drupal 8.4, Drush version requirements were increased, so our team found that we needed to upgrade our tools, in addition to Drupal core. This requires careful planning to be sure everything plays nicely during the update process, and after the updates have been applied.What happens next?
The Drupal core release cycle works around minor releases every six months. The next expected minor release is Drupal 8.5, in March of 2018. Between now and then, there will likely be multiple patch releases that will introduce bug fixes and security updates, which will be much simpler updates and should be applied as soon as they are released.
Minor release updates introduce more complexity than the Drupal world has ever seen for updates within a major release, but the tradeoff is that when Drupal 9 comes out, you won’t have to completely rebuild!
Stay tuned for my next post detailing the Drupal 8 release cycle, where I’ll dig more into how this works, why and when you should update and what we can expect for the future of Drupal.
Following a short open beta earlier this month, EA has altered how the game's loot box system works in-game to "help keep everyone on a level playing field." ...
Epic's multi-platform take on the emerging Battle Royale genre crossed 800,000 concurrent players over the weekend, roughly a 300k jump in three weeks. ...
The deadline to pitch talks for the Board Game Design Day closes Wednesday, November 1, while the deadline for the Level Design Workshop the Tools Workshop, or eSports day close Friday, November 3. ...
This October, Acquia welcomed over 650 people to the fourth annual Acquia Engage conference. In my opening keynote, I talked about the evolution of Acquia's product strategy and the move from building websites to creating customer journeys. You can watch a recording of my keynote (30 minutes) or download a copy of my slides (54 MB).
I shared that a number of new technology trends have emerged, such as conversational interfaces, beacons, augmented reality, artificial intelligence and more. These trends give organizations the opportunity to re-imagine their customer experience. Existing customer experiences can be leapfrogged by taking advantage of more channels and more data (e.g. be more intelligent, be more personalized, and be more contextualized).
I gave an example of this in a blog post last week, which showed how augmented reality can improve the shopping experience and help customers make better choices. It's just one example of how these new technologies advance existing customer experiences and move our industry from website management to customer journey management.
This is actually good news for Drupal as organizations will have to create and manage even more content. This content will need to be optimized for different channels and audience segments. However, it puts more emphasis on content modeling, content workflows, media management and web service integrations.
I believe that the transition from web content management to data-driven customer journeys is full of opportunity, and it has become clear that customers and partners are excited to take advantage of these new technology trends. This year's Acquia Engage showed how our own transformation will empower organizations to take advantage of new technology and transform how they do business.