We started regular Drupal usability meetings twice a week almost a year ago in March 2016. That is a long time and we succeeded in supporting many key initiatives in this time, including reviews on new media handling and library functionality, feedback on workflow user experience, outside-in editing and place block functionality. We helped set scope for the changes required to inline form errors on its way to stability. Those are all supporting existing teams working on their respective features where user interfaces are involved.
However, we also started to look at some Drupal components and whether we can gradually improve them. One of the biggest tasks we took on was redesigning the status page, where Drupal's system information is presented and errors and warnings are printed for site owners to resolve. While that looks like a huge monster issue, Roy Scholten in fact posted a breakdown of how the process itself went. If we were to start a fresh issue (which we should have), the process would be much easier to follow and would be more visible. The result is quite remarkable:
Now that Drupal 8.3 is in beta, it is time to look at progress around core initiatives again and see how you can help move one or more of them forward. Once again I asked initiative contributors to help compile this post to inform you all of progress across the board. This is just a sampling of some improvements, there are a lot more that we could not cover here.Default content and new core theme
The default content and new core theme teams decided to join forces because the goals are intertwined. The teams found it hard to demonstrate good default content without a supporting visual look and vice versa. The plan to go with a farmer's market site changed to a more general publication site, but that still allows for plenty of things to showcase. We are looking for a designer / art director for the project (deadline today!).
The media team held a sprint in Berlin in December. Unfortunately none of these media improvements landed in Drupal 8.3, however we are very close to complete the base media functionality early in Drupal 8.4. There was significant progress on the visual media library too. Next step is to finalise the plugins for images, documents and oEmbed.
Join in the #drupal-media channel on IRC.Migrate
The Migrate API became beta in Drupal 8.2.x with 8.2.5 and will apply to 8.3.0 as well. On the other hand other parts of the migration system like the Migrate Drupal API are still alpha stability and received some big updates. Two huge additions are the migration path for Drupal 7 node translations to Drupal 8 content translation and support added for configuration translations (and implemented initially for user profile fields).
Join in the #drupal-migrate channel on IRC.Multilingual
Most of the recent progress on the multilingual initiative was in collaboration with the migration team and that is still heavily ongoing. Further feature development around multilingual features is not on the table currently, as most contributors moved on to more pressing areas given the advances achieved in multilingual with Drupal 8 already. Therefore it is being proposed to officially remove the multilingual initiative from the list.PHPUnit
The work in the PHPUnit initiative is focusing on converting a large part of old Simpletest web tests to PHPUnit based browser tests. The goal is to commit a larger patch on February 21st to the Drupal 8.3.x branch. After that one third of Drupal core’s web tests would be converted to PHPUnit browser tests. We are also discussing the timeline for deprecating Simpletest.
If you want to convert your tests in your contrib / custom module, please read the PHPUnit browser test tutorial and help out on https://www.drupal.org/node/2794285 in case you run into problems. Please follow the PHPUnit initiative issue for status updates. Join us in IRC in #drupal-phpunit.
(This update written by klausi & dawehner)Workflow
The biggest user facing change with workflows since the last update is the introduction of the Workflows module as a separate concept from content moderation. Now other modules can use workflows for user levels, commerce and other needs as well, when the workflow has nothing to do with content moderation. Many API changes were also made including support for moderation of non-translatable entity types and entity types without bundles (as long as revisions are enabled). Publishing entities implementing EntityPublishedInterface is also possible now, not just nodes.
Wondering how to join an initiative? Meeting information for each initiative is listed at https://groups.drupal.org/node/514585
Drupal core announcements: A big chunk of old tests using WebTestBase wil be converted to PHPUnit BrowserTestBase on Feb 21st
As part of the PHPUnit initiative a considerable part of Simpletests will be converted to PHPUnit based browser tests on February 21st 2017. A backwards compatibility layer has been implemented so that many Simpletests can be converted by just using the new BrowserTestBase base class and moving the test file. There is also a script to automatically convert test files in the conversion issue.
Developers are encouraged to use BrowserTestBase instead of Simpletest as of Drupal 8.3.0, but both test systems are fully supported during the Drupal 8 release cycle. The timeline for the deprecation of Simpletest's WebTestBase is under discussion.
Some times you want to disable big pipe, for example to make sure you can set breakpoints in JS files in attached libraries. Just drop in this module and enable it in settings.php like so:$settings['big_pipe_override_enabled'] = TRUE;
When changing this value, you should clear the cache.
There are numerous ways to determine damage in a roleplaying game. It may depend on the weapon (or spell) used, the skill of the combatant, and/or the roll of the dice. In this article, we’ll look at four ways of calculating damage. It’s not meant to be a master’s thesis on the topic. Rather, it’s an overview of some major methods. This topic should prove useful for those gamemasters (GM’s) who wish to homebrew their own game or hack published systems. For others, it will hopefully provide food for thought and fodder for discussion.
Here are some options:
In many venerable systems, damage is rolled separately from “to hit” rolls. These are very familiar to most players, so they are a good option for convention games. There are no unique mechanisms to explain. They provide an added tension to each combat round. You’re never sure if you’ve landed a killing blow or not.
However, they do increase the number of overall dice rolls during combat. This may bog things down during large battles. Also, the additional roll can create the situation where you hit well, but do little damage. I’m sure most of us remember a time when we hit with a 20, but only did 1 point of damage. Some systems suggest dealing maximum damage on a “critical hit” to avoid this extreme situation.
In this mechanism, weapons do a predetermined number of damage points. For example, a sword might do 8 points while a dagger only does 4. This makes combat speedy, and damage easy to determine. For a one-shot or convention game, it might be just the thing. However, it may be a bit TOO simple and doesn’t provide any variability or tension. It also doesn’t account for any degree of success. Barely hitting an opponent does the same damage as a critical hit.
DEGREE OF SUCCESS DAMAGE
In this setup, your “to hit” roll also determines your damage. If you hit well, you do a lot of damage, if you hit poorly, you do less. It could be a static scale. For example, a full hit might do 10 points of damage, while a partial hit only does 5. It could also be a bonus added to a traditional damage dice roll. This system eliminates cases in which a player rolls well to hit, but then rolls poorly for damage.
How, this is a bit more complicated, and may require a little math to determine the degree of success. I use this system for my homebrew game and find a chart helps a great deal.
All three methods discussed so far imply a traditional hit point mechanic. However, some systems take a different, more story-based approach. In thoses systems, damage affects your ability to perform other tasks. For example, if you take a hit in a dice pool system (such as RISUS), you lose one die on future rolls. When you are out of dice, you are down for that combat. A penalty to a dice roll is another version of this mechanic. For example, you might suffer a -2 on the first hit, then a -4 on the second hit, and so on. This system is more cinematic than hit point systems, with the hero getting worn down because of combat. Also, there are no hit points to keep track of, perhaps streamlining combat.
This type of system may be a hard-sell for players who prefer more traditional games. There isn’t generally an easy way to differentiate between weapons. A dagger hit works about the same as a phaser hit, and you just have to accept that as part of the game. Finally, some call this the “Death Spiral” when it becomes difficult to succeed at any action as you lose dice or modifiers.
The type of damage system you select may depend on the type of game you’d like to run. What might work for a long traditional campaign might not be necessary for a light-hearted one shot. You’ll also want to consider the level of complexity that you are comfortable using during play. You don’t want to tie the albatross (or cumbersome system) around your own neck.
What method works best for your game? What other methods of calculating damage can you suggest? Let us know below.
Game devs Catt Small and Shawn Alexander Allen take the stage at GDC 2016 to talk about how you can create more diverse and inclusive games, and why that's a valuable thing you should be doing. ...