Newsfeeds

[AI Design]: Why characters in Ebony Spire: Heresy behave the way they do - by Constantin Bacioiu

Gamasutra.com Blogs - 10 October 2017 - 7:07am
How I designed the AI in my dungeon crawler. The article looks at a way to implement two different approaches: a need driven system and a ratio based decision making system!
Categories: Game Theory & Design

Dissecting Design -- A Valley Without Wind - by Josh Bycer

Gamasutra.com Blogs - 10 October 2017 - 7:07am
Each week, Josh Bycer of Game-Wisdom takes a deep dive into one video game for his Dissecting Design series. This week, it's all about the replayability of A Valley Without Wind.
Categories: Game Theory & Design

Day 23 of 100 Days of VR: Creating a Spawning System for Enemies in Unity - by Josh Chang

Gamasutra.com Blogs - 10 October 2017 - 7:07am
Today on day 23 we’re going to learn how to spawn enemy waves. Currently, the game isn’t challenging, we only have one enemy! We’re going to fix this by spawning waves of enemies to defeat.
Categories: Game Theory & Design

Open-World RPGs and the Hinterlands Problem - by Damon Reece

Gamasutra.com Blogs - 10 October 2017 - 7:06am
An analysis of common pitfalls in contemporary open-world RPGs that lead to narrative inconsistency and player dissatisfaction.
Categories: Game Theory & Design

Fantasy Flight Games Announces Legacies Expansion For Star Wars: Destiny

Tabletop Gaming News - 10 October 2017 - 7:00am
Fantasy Flight Games has announced a new set for Star Wars: Destiny, their card and dice game of sci-fi combat. This set adds in new mechanics such as a new die symbol and card type. There’s also going to be two new starter sets for the game, focusing on Luke Skywalker and Boba Fett, two […]
Categories: Game Theory & Design

Defined table field

New Drupal Modules - 10 October 2017 - 6:56am

This module provides a new "Defined table" field type, that allows administrators and content builders to add tables to content.

Table header row and column (data labels) can be either predefined in field settings (the same for a field instance) or set to dynamic and definable per entity.

Possible label sources:

  • Taxonomy vocabulary
  • Custom input

Other table field modules:

Categories: Drupal

Wyrd Posts New Medical Automaton Artwork

Tabletop Gaming News - 10 October 2017 - 6:30am
It’s Monday! Ok, so it’s not. It’s actually Tuesday. I can tell because of the shirt I’m wearing. Many of us had Monday off here in the states, including me. So it’s a bit of catch-up this morning. One item is Wyrd’s regular Monday post. In this case, it’s some alternate art for the Medical […]
Categories: Game Theory & Design

Taxonomy Move

New Drupal Modules - 10 October 2017 - 6:29am

Move terms between vocabularies.

Categories: Drupal

Leaflet Entity Browser

New Drupal Modules - 10 October 2017 - 6:29am

This module allows you to use a Leaflet map as a views widget inside Entity Browser.

Note: This module depends on the following patches to the Leaflet drupal module (if the issues are not fixed already):

Categories: Drupal

New Chindit Forces Available For Bolt Action

Tabletop Gaming News - 10 October 2017 - 6:00am
You’ve quite possibly gotten your order in for the previous Chindit sets that Warlord Games released for Bolt Action. Well, now it’s time to expand your forces out with some new kits. They’re now taking orders for an HQ unit, some heavy weapon crews, and characters. They’ve also got an entire force bundled together for […]
Categories: Game Theory & Design

Drupal Modules: The One Percent: Drupal Modules: The One Percent —Content connected (video tutorial)

Planet Drupal - 10 October 2017 - 5:32am
Drupal Modules: The One Percent —Content connected (video tutorial) NonProfit Tue, 10/10/2017 - 07:32 Episode 39

Here is where we seek to bring awareness to Drupal modules running on less than 1% of reporting sites. Today let's consider Content connected, a module which displays where content has been referenced.

Categories: Drupal

ADCI Solutions: Web Designers methods and tools for enhancing a workflow

Planet Drupal - 10 October 2017 - 4:28am

Designers do love order, so don’t believe in stereotypes. Our Drupal team’s designer created her own approach of the working files organization. It helps her to communicate with the rest of the team - developers and managers - efficiently.

 

Try out our approach and improve the workflow

 

 

Categories: Drupal

Fate Adversary Toolkit Review

Gnome Stew - 10 October 2017 - 3:00am

I’m going to admit something right up front. I’m cheating with this review. I’m running a Dresden Accelerated game, and reading through this book is allowing me to review it, as well as potentially steal things for my campaign. Does that make me a bad person?

My love of the Dresden Files is what led me to start looking at Fate. I picked up the Dresden Files RPGs, and while I loved the “story” side of the RPG, I couldn’t quite grasp the rules. This was around the time that the Fate Core Kickstarter was going on, so I jumped on board, and as soon as I started reading the rules in Fate Core, things started to click.

Fate is a broad, powerful system. You can handle the same situation a multitude of ways, and none of them are wrong. The downside to this is—you can handle the same situation a multitude of ways, and none of them are wrong. With such a broad system, seeing different ways to apply the broad concepts introduced in context can really help a Fate GM narrow down how they want to use the game.

As part of the Fate Core Kickstarter, a book called the Fate Toolkit was produced, which had a series of optional rules and concepts for handling specific situations, and some of these options were used to flesh out how Dresden Accelerated handles the same topics as its older sibling. The Toolkit mentions that future Toolkits for the system would be produced, and the first of the new line of Fate Toolkits is the Adversary Toolkit.

The Sourcebook’s Aspects

 I have both the physical copy of the Fate Adversary Toolkit as well as the PDF, so this review is informed by both. The book is a lean 112 pages, with a single page ad at the end. The trade dress is similar to other Fate products, with the purple color denoting the Toolkit line. The physical copy is hardcover and digest size, and feels solid for a smaller hardcover book.

Like most of the core Fate products, the cover art is full color, and the interior art is black and white. The art is high quality, and a mix of different genres to illustrate various examples in the book. Yes, there is at least one image of a cyborg ape.

The Fate Toolkit Series and Introduction

 The introductory sections of the book mention that this series is meant to be ongoing, with references to things like the Horror Toolkit. The design intention for these rules is to be modular, with the ability to swap out specific rules in other Fate games without changing anything except the specific rules being used from this series. The introduction then gives a brief overview of what the chapters are in the book.

Types of Adversaries

This chapter introduces the broad categories under which adversaries get organized using the Toolkit’s rules, which breaks down to Enemies, Obstacles, and Constraints.

  • Enemies are further broken down into Threats, Hitters, Bosses, and Fillers. Threats are designed to survive long term in a fight; Hitters are meant to do damage, but aren’t too difficult to dispatch; Bosses have a combination of traits, but they are often the “point” of an encounter; and Fillers aren’t so much good at anything as they exist in a scene to show that they are there.
  • Obstacles are broken down into Hazards, Blocks, and Distractions. Hazards cause harm, Blocks exist to force characters to overcome or go around them, and Distractions are choices that might slow down the character’s progress.
  • Constraints are subdivided into Countdowns, Limitations, and Resistances. Countdowns are boxes that tick off when something happens, and change the scene when the boxes are all full. Limitations are elements that make performing certain actions less desirable, but not impossible, and Resistances are facts that make dealing with a given adversary impossible unless a specific way of dealing with that thing is engaged.

This is a short chapter, and it just introduces the concepts and describes them in a little more detail than I did above. I’m intrigued at this point, and I’m interested to see how all of this gets implemented in the actual rules. I’m also a sucker for well laid out explanations of what is coming next in a book like this, so I like that everything is defined up front.

Building Adversaries

This section of the book gets into the actual mechanics of how to make everything work. There are also numerous examples of the various types of adversaries, showing off the rules explained in this section in the example stat blocks.

Enemies

For many of the enemy types discussed above, there is advice on applying skill bonuses to what that enemy is designed to do, as well as using the Weapon rules to dial up or down the threat level. The book also addresses how many stress boxes and/or consequences different roles should have. There are also some example stunts that are intentionally not built to work as PC stunts. These might allow for a boss enemy to escape, or to give a big bonus in the situation where it will give the enemy the biggest advantage.

Much of the information on enemies revolves around asynchronous design, where you don’t build GM characters the same way you would PCs. This comes up in other Fate products (for example, several Fate products only assign minor characters special skills for what they are intended to do in a scene), but in this case, there are several pages of guidelines on what to “break” for your enemies and what effect that will have in the game.

I’m a big fan of grouping large numbers of lesser bad guys together as one character, and this chapter has rules on doing this on the fly, when those bad guys have been introduced as Fillers. There are some rules for throwing their stress boxes together in a specific way and what direction to remove stress from them, but I’ll be honest, grouping Filler enemies together is my least favorite part of the enemies section. I can see the advantage to doing it, but I’m just much more likely to make them into a slightly larger single enemy to begin with.

Obstacles

The next section is on Obstacles. The biggest difference between an Obstacle and an Enemy is that the Obstacle might get a turn in initiative, or just go off when a certain thing happens in the narrative, but the Obstacle can’t be directly stressed out. Some might allow for an Overcome action to determine how to shut it down, but directly engaging it is meant to be a multi-step process.

Hazards are designed to do damage when they are triggered, and Blocks narratively separate parts of the scene. They may do damage, but they aren’t primarily designed to do so, the way Hazards are.

Distractions are put into the Obstacles category, but they feel a little different than the other two. They are meant to put some texture into an exchange by causing the players to decide. Innocents need to be saved, which might let the bad guy escape, for example. The book introduces a format for detailing Distractions, which helps the GM determine the purpose it serves in the scene.

Constraints

The final section in the Building Adversaries chapter is Constraints. Depending on how they are used, Constraints might be more like modifiers used for enemies than actual adversaries by themselves.

Countdowns are fairly simple–you set a number of boxes, what happens to cause a box to tick off, and what happens when the countdown is finished. There is some discussion about how to portray the final effects of the countdown, depending on the scale of the countdown and what you have established as the stakes.

Limitations are modifiers meant to make certain direct actions less desirable. A pool is filled with electric eels, a room is flooded with radiation, etc. They mention establishing a Limitation as a Fact or an Aspect, and how if you establish it as an Aspect it has more application to the rules. I think the discussion on Facts should have been a bit longer, because I’m not sure why I should use a Fact instead of an Aspect in this case.

Resistances are essentially hard pronouncements. A creature can only be harmed with X. No starship can fly past the boundaries of this nebula without special shielding. Narratively, a thing cannot be done unless a specific other thing is used or done first. I like the hard narrative statement, because other implementations of similar rules in other versions of Fate have felt a little clunky. There is a lot of freedom in determining how to get the “key,” so limiting the solution to the big problem is just one part of the story that doesn’t need to be overly mechanized.

Using Environments

This section gives an in-depth discussion of planning the zones that you use for exchanges, and how to place things like Blocks and Hazards within those zones. I will freely admit, I’m pretty loose on establishing more than two zones or so at a time, and this section shows the benefit of putting some thought into those potential zones that could come up, but haven’t when the exchange starts.

On top of general advice on designing zones with adversaries in mind, there is some discussion about relative zones and conceptual zones. Relative zones can be used for things like chases, where the area that the character inhabits is based on context. This section also mentions that when using things like relative zones, characters might occupy more than one zone at a time. For example, you might have the city where the chase is taking place, with its own aspects, and the character is in the city zone, as well as the “a few steps behind” zone in the chase.

I like the idea of conceptual zones, but I really want to see more about them. Essentially, they are introduced to be used for games where exchanges are less about beating people up than about convincing people that they are right or wrong. Conceptual zones might be things like “no standing at court” or “allowed in the inner council room,” and certain actions just aren’t possible until characters are “close” to one another in conceptual terms. As introduced, they are intriguing, but I really want to see more about them before I feel comfortable using them.

Rogues Gallery

This section of the book is by far the largest section, and takes up over half the pages. With a name like Rogues Gallery, you might expect a large number of pre-made adversaries for a game, and you would be right. However, those pre-made adversaries are all collected in adventure outlines that you can use for one shots, with advice on how to expand those one shots into short campaigns, as well as thoughts on how to drift the adversary and the situation into other genres.

The genres used are Fantasy, Urban Fantasy, Cyberpunk, Pulp, 80s Action, Space Opera, Spy Thriller, Supers, Post-Apocalyptic, and Regency Romance. Examples of all the different rules introduced in the previous chapters can be found in this section, but not every rule is used in every example adventure. This makes sense, because the whole point is using the right tools for the right job.

The Cyberpunk and Post-Apocalyptic adventures felt a little flat to me, but they certainly serve to illustrate using the rules in the context of those settings. If you are wondering, 80s action could be read as “G.I. Joe,” and Spy Thriller could be read as “Mission Impossible.”

I really love the inclusion of the Regency Romance scenario as an example of a Fate game that revolves around social interactions instead of straight up combat. There is a brief discussion of the conceptual zones in this one, but it feels like it could have used a deeper treatment.

Success with Style  Straight up, this book does what it says it will do—it’s a toolkit to make using adversaries in Fate simpler and more effective. 

If you want options for building adversaries that are simple and straightforward, and should work even if they don’t engage all the special rules in a particular version of Fate, this book should serve your purposes. If you want a book that is going to give you plenty of Fate scenarios for short campaigns or one shots, this book is also going to work for you. The discussion of the more tactical use of zones and the proper levels of skills and application of the weapon rules is going to be extremely useful for GMs that have been running Fate for a while. Straight up, this book does what it says it will do—it’s a toolkit to make using adversaries in Fate simpler and more effective.

Free Invoke of a Consequence

I wish the book had spent more time on the conceptual zones, and given a few more detailed examples of using them in the sample adventures. Some of the sample adventures felt a little flat. I wish there had been more than one adventure that revolved around social or political maneuvering, rather than physical combat, since Fate can adapt so well to other kinds of stories. I would have liked a more traditional collection of enemies, obstacles, and example constraints all in one place, instead of sprinkled throughout the book as contextual examples—although I think if the book only has one or the other, the contextual examples were the right call.

TL/DR Recommended—If the product fits in your broad area of gaming interests, you are likely to be happy with this purchase.

If you are generally interested in Fate, it’s unlikely you will regret picking this book up. Not only does it give you solid guidelines for building adversaries that do what you need them to do in the scene, in a clear format, it also gives you several options for one shots or short campaign ideas in addition to the rules for building and modifying adversaries. It does what it says on the cover, and then goes a little bit beyond.

If you have the Fate Adversary Toolkit, let me know what you think of it. If you have some ideas on what you want to see in the future (specific products or broad games lines), let me know as well! I would love to hear from you.

 

 

 

 

Categories: Game Theory & Design

Config Auto Export

New Drupal Modules - 10 October 2017 - 2:17am

This module detects changes to the configuration system and exports those changes into a configurable directory of your choice. In addition to that it is able to fire a POST request with parameters to a http service that you configure which can then react to those configuration changes.

Use case

Imagine procution servers which are deployed fully automatically and configured securely such that none if the directories are writeable except public and private storage areas.

Categories: Drupal

Aten Design Group: Form and View Modes vs. Field Access in Drupal 8

Planet Drupal - 10 October 2017 - 12:13am

Drupal 8 advertised many new, promising features after its release. One of the exciting new changes was the addition of form modes. Form modes promised to let you manage the content entry side of your site just as you often managed content display with view modes. This change seemed like it would eliminate the need for much of the custom and repetitive code I often needed to write inside a hook_form_alter.

Over time, I've realized that form modes aren't everything I had hoped they would be. While it's easy to create new form modes, it's literally impossible to use them without custom code or contributed modules. Drupal simply doesn't have a way to know when to use one form mode over another. Should it be based on role? Permissions? A field on the node? Content moderation state? There are contributed modules for most if not all of these, but nothing out-of-the-box.

This forced me to think about why I needed a form mode in the first place. Almost always, the answer was to disable or hide a field from a user because that user shouldn't be allowed to change that field. The same was also often true of my view modes (only to a lesser extent). I realized that this particular problem is not one of user experience, but of access control.

Drupal 8 has hook_entity_field_access(). This hook is called for every field for the specified entity type when the entity is viewed or when its form is shown. When you deny access to a field, either for viewing or editing, that field will not be shown to the user. In any scenario. This should be your preferred method for hiding fields that certain users should not be able to access.

Using field access over form and view modes to hide fields when a user should not be allowed to see or edit a field is the secure and "Drupal way" to do things. This prevents mistakes in configuration, which might accidentally leak field information via teasers, searches, and Views. It also future proofs your site. If you ever turn on REST or JSON API or add a new form or view mode down the line, you can never accidentally expose a field that needs to be kept private.

Best of all, using the field access hook is much easier to implement than all the hoops you'll have to jump through to get the right form modes displayed at the right times.

How to use hook_entity_field_access()

First, make a custom module in the standard way. Create a .module file and create the following function:

<?php use Drupal\Core\Access\AccessResult; use Drupal\Core\Field\FieldDefinitionInterface; use Drupal\Core\Session\AccountInterface; use Drupal\Core\Field\FieldItemListInterface;     /** * Implements hook_entity_field_access(). */ function yourmodule_entity_field_access($operation, FieldDefinitionInterface $field_definition, AccountInterface $account, FieldItemListInterface $items = NULL) { } ?>

From this hook, you should always return an AccessResult. By default, you should simply return a neutral access result. That is, your hook is not concerned with actually allowing or preventing access yet. Add the following to your function.

<?php function yourmodule_entity_field_access($operation, FieldDefinitionInterface $field_definition, AccountInterface $account, FieldItemListInterface $items = NULL) { $result = AccessResult::neutral(); if ($field_definition->getName() == 'field_we_care_about') { if (/* a condition we'll write later... */) { $result = AccessResult::forbidden(); } } return $result; } ?>

The above code will deny access when our still unwritten condition is true, in every other case, we're just saying "we don't care".

There's an infinite number of scenarios in which you might want to deny access, but let's say that we want to make a field only editable by an administrator. We would add the following:

<?php function yourmodule_node_field_access($operation, FieldDefinitionInterface $field_definition, AccountInterface $account, FieldItemListInterface $items = NULL) { $result = AccessResult::neutral(); if ($field_definition->getName() == 'field_we_care_about') { if ($op == 'update' && !in_array('administator', $account->getRoles())) { $result = AccessResult::forbidden(); } } return $result->addCacheContexts(['user.role:administrator']); } ?>

Now, for every user without the administrator role that attempts to update field_we_care_about, the field will not be accessible. This works for more than just forms. For example, if we had the REST module installed, this would block the user from updating the field in that way as well.

The last part to note is that we added a cache context to our AccessResult. This ensures that our access decision is only relevant when the current user does or does not have the 'administrator' role. It's important to understand that we added the cache context both when we did and when we did not deny access. If we had just added the context when we denied access, if a user with the 'administrator' role happened to be the first person to attempt to access the field, then that result would be cached for all users no matter what.

Categories: Drupal

Superseeds: Planetary Guide Entry #023: Super-serum

RPGNet - 10 October 2017 - 12:00am
Connecting up the super-serum heroes.
Categories: Game Theory & Design

Appnovation Technologies: Appnovator Spotlight: Janice Cheer

Planet Drupal - 10 October 2017 - 12:00am
Appnovator Spotlight: Janice Cheer Meet Janice Cheer, Sales Enablement from Vancouver, BC. 1. Who are you? What's your story? /*-->*/ /*-->*/ /*-->*/ I’m a Chinese-Canadian who grew up in a small town called Squamish. After finishing high school, I moved out to Vancouver for school and obtained my Bachelor’s Degree in Business Administration with a minor in Marketing. Sin...
Categories: Drupal

Analytics Monitoring Tool

New Drupal Modules - 9 October 2017 - 11:50pm

A centralized tool to monitor whether GA, GTM or Omniture is working on multiple sites.

Categories: Drupal

Medium Posts

New Drupal Modules - 9 October 2017 - 9:17pm
Introduction

A Drupal module used for publishing posts from Drupal to Medium.com by using Medium API.

This module is based on Medium’s API and Medium SDK for PHP.

Categories: Drupal

Hook 42: September A11Y (Accessibility) Talk Review

Planet Drupal - 9 October 2017 - 6:20pm

We have all heard about website accessibility and know what it means in a broad sense, but what does website accessibility look like in a practical sense?

This month’s A11Y Talk featured Scott O'Hara from The Paciello Group. In this A11Y Talk, Scott O'Hara addressed questions like:
- How do I get started in a11y?
- How do I get my team to care about it?
- Where does one start in trying to incorporate a11y into the work they or their team produce?
- Who is in charge of a11y at your company anyway?

Categories: Drupal

Pages

Subscribe to As If Productions aggregator