Newsfeeds

My insight on how level flow is applied in games like Uncharted 4 & The Last of Us - by Trinh Nguyen

Gamasutra.com Blogs - 9 January 2019 - 7:48am
The past few months I have been doing research in the level flow and environment design in games like, "Uncharted 4" and "The Last of Us" This blog will be a crash course on: What is level flow & how level designers apply them.
Categories: Game Theory & Design

Virtual Cities: A Look At Rubacava - by Konstantinos Dimopoulos

Gamasutra.com Blogs - 9 January 2019 - 7:12am
An excerpt from the forthcoming Virtual Cities atlas taking a closer look at Grim Fandango's Rubacava.
Categories: Game Theory & Design

Growing the Conversation on Game Design - by Josh Bycer

Gamasutra.com Blogs - 9 January 2019 - 7:03am
Despite how it has come to define this industry, the study of game design for a lot of people continues to be discounted, and it's time for that to change.
Categories: Game Theory & Design

Netflix's Bandersnatch UX: Cinema meets Gaming, how to make the marriage last! - by Om Tandon

Gamasutra.com Blogs - 9 January 2019 - 7:02am
Bandersnatch: Netflix's attempt at gamifying cinema is a commendable attempt but leaves more to be desired, ideas on how it can benefit from deep learnings & psychology of games.
Categories: Game Theory & Design

Simple Comment Notify

New Drupal Modules - 9 January 2019 - 6:22am

Coming soon...

Categories: Drupal

Joachim's blog: Getting more than you bargained for: removing a Drupal module with Composer

Planet Drupal - 9 January 2019 - 6:19am

It's no secret that I find Composer a very troublesome piece of software to work with.

I have issues with Composer on two fronts. First, its output is extremely user-unfriendly, such as the long lists of impenetrable statements about dependencies that it produces when it tells you why it can't make a change you request. Second, many Composer commands have unwanted side-effects, and these work against the practice that changes to your codebase should be as simple as possible for the sake of developer sanity, testing, and user acceptance.

I recently discovered that removing packages is one such task where Composer has ideas of its own. A command such as remove drupal/foo will take it on itself to also update some apparently unrelated packages, meaning that you either have to manage the deployment of these updates as part of your uninstallation of a module, or roll up your sleeves and hack into the mess Composer has made of your codebase.

Guess which option I went for.

Step 1: Remove the module you actually want to remove

Let's suppose we want to remove the Drupal module 'foo' from the codebase because we're no longer using it:

$ composer remove drupal/foo

This will have two side effects, one of which you might want, and one of which you definitely don't.

Side effect 1: dependent packages are removed

This is fine, in theory. You probably don't need the modules that are dependencies of foo. Except... Composer knows about dependencies declared in composer.json, which for Drupal modules might be different from the dependencies declared in module info.yml files (if maintainers haven't been careful to ensure they match).

Furthermore, Composer doesn't know about Drupal configuration dependencies. You could have the situation where you installed module Foo, which had a dependency on Bar, so you installed that too. But then you found Bar was quite useful in itself, and you've created content and configuration on your site that depends on Bar. Ideally, at that point, you should have declared Bar explicitly in your project's root composer.json, but most likely, you haven't.

So at this point, you should go through Composer's output of what it's removed, and check your site doesn't have any of the Drupal modules enabled.

I recommend taking the list of Drupal modules that Composer has just told you it's removed in addition to the requested one, and checking its status on your live site:

$ drush pml | ag MODULE

If you find that any modules are still enabled, then revert the changes you've just made with the remove command, and declare the modules in your root composer.json, copying the declaration from the composer.json file of the module you are removing. Then start step 1 again.

Side effect 2: unrelated packages are updated

This is undesirable basically because any package update is something that has to be evaluated and tested before it's deployed. Having that happen as part of a package removal turns what should be a straight-forward task into something complex and unpredictable. It's forcing the developer to handle two operations that should be separate as one.

(It turns out that the maintainers of Composer don't even consider this to be a problem, and as I have unfortunately come to expect, the issue on github is a fine example of bad maintainership (for the nadir, see the issue on the use of JSON as a format for the main composer file) -- dismissing the problems that users explain they have, claiming the problems are by design, and so on.)

So to revert this, you need to pick apart the changes Composer has made, and reverse some of them.

Before you go any further, commit everything that Composer changed with the remove command. In my preferred method of operation, that means all the files, including the modules folder and the vendor folder. I know that Composer recommends you don't do that, but frankly I think trusting Composer not to damage your codebase on a whim is folly: you need to be able to back out of any mess it may make.

Step 2: Repair composer.lock

The composer.lock file is the record of how the packages currently are, so to undo some of the changes Composer made, we undo some of the changes made to this file, then get Composer to update based on the lock.

First, restore version of composer.lock to how it was before you started:

$ git checkout HEAD^ composer.lock

Unstage it. I prefer a GUI for git staging and unstaging operations, but on the command line it's:

$ git reset composer.lock

Your composer lock file now looks as it did before you started.

Use either git add -p or your favourite git GUI to pick out the right bits. Understanding which bits are the 'right bits' takes a bit of mental gymnastics: overall, we want to keep the changes in the last commit that removed packages completely, but we want to discard the changes that upgrade packages.

But here we've got a reverted diff. So in terms of what we have here, we want to discard changes that re-add a package, and stage and commit the changes that downgrade packages.

When you're done staging you should have:

  • the change to the content hash should be unstaged.
  • chunks that are a whole package should be unstaged
  • chunks that change version should be staged (be sure to get all the bits that relate to a package)

Then commit what is staged, and discard the rest.

Then do a git diff of composer.lock against your starting point: you should see only complete package removals.

Step 3: Restore packages with unrelated changes

Finally, do:

$ composer update --lock

This will restore the packages that Composer updated against your will in step 1 to their original state.

If you are committing Composer-managed packages to your repository, commit them now.

As a final sanity check, do a git diff against your starting point, like this:

$ git df --name-status master

You should see mostly deleted files. To verify there's nothing that shouldn't be there in the changed files, do:

$ git df --name-status master | ag '^[^D]'

You should see only composer.json, composer.lock, and the autoloader's files.

PS. If I am wrong and there IS a way to get Compose to remove a package without side-effects, please tell me.

I feel I have exhausted all the options of the remove command:

  • --no-update only changes composer.json, and makes no changes to package files at all. I'm not sure what the point of this is.
  • --no-update-with-dependencies only removes the one package, and doesn't remove any dependencies that are not required anywhere else. This leaves you having to pick through composer.json files yourself and remove dependencies individually, and completely obviates the purpose of a package manager!

Why is something as simple as a package removal turned into a complex operation by Composer? Honestly, I'm baffled. I've tried reasoning with the maintainers, and it's a brick wall.

Tags: Composer
Categories: Drupal

Missing Session Zero

Gnome Stew - 9 January 2019 - 5:00am

Lonely chair in the spot of light on black background at empty room

As highlighted in a recent GnomeCast, Ang, Matt, and I talked about how to approach session zero and handle launching a campaign. Near the end of the recording, Matt pondered about how to handle a missing player. I decided to create an article (this one!) about that very occurrence.

 What does the GM do when a player misses out on session zero? Share1Tweet1+11Reddit1Email

In case you missed the episode, here’s the basic run-down of what session zero is for. Session zero occurs before the campaign launches. It sets the groundwork for genre, system, play style, social contracts, safety measures while at the table, setting agreements (or even creation), character creation, tying the disparate characters together into a cohesive unit via backstory or hooks, and so on. It’s building the foundation the campaign will stand upon for the weeks, months, or years to come. Another thing that I like to do during session zero is to have an introductory encounter (not always combat) between the party and either the world or some NPCs to set the tone and drop some adventure hooks in front of the players.

Now to Matt’s question: What does the GM do when a player misses out on session zero? I have two different answers based on why the player was absent.

Intentional Absence

If the player, for whatever intentional reason, decided to drop out of the session zero experience, I tend to be a little more stern with them. All of the players need to be involved in session zero for it to be as effective as possible. I’ll take the world, setting, city, NPC, party, and introductory hook notes, compile them into a PDF (or several of them if necessary). Then I’ll email the PDF(s) to the player and tell them that the reading is mandatory in order for them to know what is going on with the future of the game.

 If the player, for whatever intentional reason, decided to drop out of the session zero experience, I tend to be a little more stern with them. Share1Tweet1+11Reddit1Email

The reason I make the reading mandatory is that we had a player miss session zero once. This included a high-level lesson from the GM on “string theory” and quantum physics. None of us came out as experts, but it was the foundation behind why our spacecraft had faster-than-light travel built in, and all other spaceships had to use jump-gates. During the course of play during the first session, the player who was absent from receiving this foundational knowledge, really goofed up on the controls of the ship (this was player ignorance, not a bad roll or an in-character moment). We ended up shooting across the galaxy and away from our objectives the GM had carefully planned out. Oops. Yeah, we could have stepped in and retconned the poor decision on the navigation of the ship, but that’s not our game style. We ran with the change in the story arcs, but I felt bad for the GM who had to toss aside sheafs of paper with his meticulous notes.

I’m not a huge planning GM. I do more improv, but there is some planning and prep work that goes into getting ready for the gaming session. Having a player completely disregard the group’s efforts to get together during session zero is inconsiderate and rude, to be honest.

What about the player’s character? When I email the PDF(s) to the player, I give them a narrow scope of character types to pick from to round out the party. Then I tell the player to create the character within those narrow scope of choices, and make sure to show up with a completed character (ready for me to review and approve) when they arrive for the first session.

If possible, I try to keep an open email dialogue going on with the player to see if they can get ideas, their character, etc. to me via email sooner than later. This will give me time to get through the new character and provide feedback before the first session kicks off.

Unplanned Absence

There are times where real life gets in the way of gaming. I completely understand that. Just a few weeks ago, we had two players carpooling to the game after a snow/ice storm. Weather was clear, but the remote roads were not. They ended up in a ditch and against a fence. Even though someone pulled them out and they got to the gaming location, they were no longer in the mood to roll some dice. I get that. I probably wouldn’t want to game either after a harrowing experience like that. (Note: Neither person was injured, so we were very thankful for that.) The litany of ways real life can intercede on our gaming plans is as lengthy as the history of the universe is old.

 There are times where real life gets in the way of gaming. I completely understand that. Share1Tweet1+11Reddit1Email

Be understanding. Be generous. Be kind. Know that the player wanted to be there, but could not because of whatever legitimate reason came up. My approach here is drastically different from the “intentional absence” response.

The first thing I do is see if I can set up some time to meet, one-on-one, with the missing player. If we can get together before the first session, great. During that one-on-one meeting, I’ll outline what’s been decided, ask them if they would have any input and/or changes to make with what has been put down. Then I’ll give them a quick run-down of the characters that already exist in the party, and work with them on making a character that they’ll enjoy but will still fit into the party and mesh well. I’ll also work with them on background information for their character to try and tie their new character to at least two other party members.

Once we finish up the meeting, I’ll reach out the rest of the players with any world/setting changes, so they won’t be surprised. Then I’ll email (on the side) the players who have had the new character’s background “attached” to their own, so they can hash out any further details via email before we sit down at the table again.

If I can’t get a meeting together with the missing player, then I resort to emails. Lots of emails. I’ll compile the same documents into PDF(s) and email those to the player and ask them to read through it before determining their character. I’ll leave the character concepts as wide open as I can, but still with the limitations that the new character fit in with the rest of the party. In other words, if the entire party is made up of rangers, paladins, and cavaliers, I wouldn’t allow the new character to be an assassin… because…. well… That’s just asking for trouble, right?

If things work out well, we’ll have everything nailed down and the player will have a character they like when they show up at the table for the first session.

Conclusion

It sounds like I’m harsh with the “intentional absence” player, but I like to set the tone of expectations early on. If I allow the player to slide early on, I’ve found through experience that they will be problematic throughout the campaign’s run. By nipping it in the bud early on, things run smoother.

I’m also completely understanding of things getting in the way of gaming. It happens. I don’t have to like it, but I get it. I won’t punish a player for missing any session because their work, children, loved ones, car troubles, or just life in general get in the way. As a matter of fact, I’ll go out of my way to work around all of that to see if we can get back on track.

How do all of you out there in the Internet gamer land handle folks who miss key or vital sessions?

Categories: Game Theory & Design

Scheduler content moderation integration

New Drupal Modules - 9 January 2019 - 1:05am

This is a submodule for the scheduler module to integrate with content moderation.

Categories: Drupal

Matt Glaman: Writing better Drupal code with static analysis using PHPStan

Planet Drupal - 8 January 2019 - 8:00pm
Writing better Drupal code with static analysis using PHPStan Published on Tuesday 8, January 2019

PHP is a loosely typed interpreted language. That means we cannot compile our scripts and find possible execution errors without doing explicit inspections of our code. It also means we need to rely on conditional type checking or using phpDoc comments to tell other devs or IDE what kind of value to expect. Really there is no way to assess the quality of the code or discover possible bugs without thorough test coverage and regular review.

Categories: Drupal

Karim Boudjema: 10 helpful Drupal 8 modules for 2019

Planet Drupal - 8 January 2019 - 3:04pm
It’s always hard to pick up the most useful Drupal 8 modules because it depends on the site you will create or manage. But there are some really helpful modules you can use in almost every situation.

In this post, I will share some modules that I use almost all the time in my Drupal 8 projects, they are not related to a particular type of site but they are always helpful, both in development or production environment.

1. Admin Toolbar

(D8) - https://www.drupal.org/project/admin_toolbar
The Admin Toolbar module will greatly save your time. By having a drop-down menu and extending the original Drupal menu, it helps to perform various admin actions faster and easier.

The module works on the top of the default toolbar core module, therefore it is a very light module and keeps all the toolbar functionalities (shortcut / media responsive).
Categories: Drupal

AdChoices Link (formerly Ghostery)

New Drupal Modules - 8 January 2019 - 1:31pm

This module provides a simple UI to add the AdChoices link to a menu.

Instructions

Install the module as you would any other Drupal module.

Categories: Drupal

mark.ie: Creating an 'Add to Calendar' Widget in Drupal

Planet Drupal - 8 January 2019 - 1:11pm
Creating an 'Add to Calendar' Widget in Drupal

A simple request: we need an 'Add to Calendar' widget to add our events to Google Calendar, iCal, and Outlook. Simple (once I had completed it!).

markconroy Tue, 01/08/2019 - 21:11

There's a module for that. There is, it's called, obviously, addtocalendar. It works very well, if you:

  • want to use the addtocalendar.com service,
  • want to pay for this service

If you don't want to use an external service for something as simple as adding an event to a calendar, then it looks like you'll need a custom solution. Their smallest plan only allows 2 events per month.

The PatternLab Part

Here's the custom solution I came up with (in the future, I'll look at creating a module for this with a settings/UI page for site builders). Note, it's a PatternLab implementation; if you don't use PatternLab and just want to work directly in your Drupal theme, it would be even easier.

Here's the code for the 'Add to Calendar' pattern in PatternLab (some classes and things are removed to make it easier to read):

  1. {%
  2. set classes = [
  3. "add-to-calendar"
  4. ]
  5. %}
  6.  
  7. {% set ical_link = 'data:text/calendar;charset=utf8,BEGIN:VCALENDAR%0AVERSION:2.0%0ABEGIN:VEVENT%0ADTSTART:' ~ atc_start_date|date("Ymd\\THi00\\Z") ~ '%0ADTEND:' ~ atc_end_date|date("Ymd\\THi00\\Z") ~ '%0ASUMMARY:' ~ atc_title ~ '%0ADESCRIPTION:' ~ atc_details|striptags ~ '%0ALOCATION:' ~ atc_location|replace({'
    ': ' ', '
    ': ' ', '

    ': ' ', '

    ': ''}) ~ '%0AEND:VEVENT%0AEND:VCALENDAR' %}
  8.  
  9. {% set google_link = 'https://www.google.com/calendar/r/eventedit?text=' ~ atc_title ~ '&dates=' ~ atc_start_date|date("Ymd\\THi00\\Z") ~ '/' ~ atc_end_date|date("Ymd\\THi00\\Z") ~ '&details=' ~ atc_details|striptags ~ '&location=' ~ atc_location|replace({'
    ': ' ', '
    ': ' ', '

    ': ' ', '

    ': ''}) %}
  10.  
  11. {{ attributes.addClass(classes) }}>
  12.  
  13. {{ google_link }}">Add to Google Calendar
  14.  
  15. {{ ical_link }}">Add to iCal
  16.  
  17. {{ ical_link }}">Add to Outlook
  18.  

What does the above code do?

  • Creates a Google Calendar variable and creates an iCal variable. Outlook will also use iCal.
  • Uses these variables as links to add the event to their respective calendars.

Within the variables, we have some more variables (start date, end date, etc), which we should probably wrap in conditional statements so that their clauses don't print unless they are present in Drupal (some fields might be optional on your event content type, such as end time).

These variables are:

  • atc_start_date: Start Date and time
  • atc_end_date: End Date and time
  • atc_title: the name of the event
  • atc_details: description for the event
  • atc_location: place of event

In our Event pattern in PatternLab, we then have a variable called 'add_to_calendar' so that events have the option to have this widget or not. In event.twig, we simply print:

  1. {% if add_to_calendar %}
  2. {% include '@site-components/add-to-calendar/add-to-calendar.twig' %}
  3. {% endif %}
The Drupal Part

In Drupal we create a boolean field on our event content type field_event_add_to_calendar, if this is ticked, we will display the Add to Calendar widget.

Here's the code from node--event--full.html.twig

  1. {# Set the Add to Calendar Variables #}
  2.  
  3. {% if node.field_add_to_calendar.value %}
  4. {% set add_to_calendar = true %}
  5. {% endif %}
  6.  
  7. {% if node.field_event_date.value %}
  8. {% set atc_start_date = node.field_event_date.value %}
  9. {% endif %}
  10.  
  11. {% if node.field_event_date.end_value %}
  12. {% set atc_end_date = node.field_event_date.end_value %}
  13. {% endif %}
  14.  
  15. {% if node.title.value %}
  16. {% set atc_title = node.title.value %}
  17. {% endif %}
  18.  
  19. {% if node.field_event_intro.value %}
  20. {% set atc_details = node.field_event_intro.value %}
  21. {% endif %}
  22.  
  23. {% if node.field_event_location.value %}
  24. {% set atc_location = node.field_event_location.value %}
  25. {% endif %}
  26.  
  27. ...
  28.  
  29. {% include "@content/event/event.twig" %}

To explain:

If the 'Add to Calendar' boolean is on, we set the add to calendar variable as true

This in turn tells patternlab to render the Add to Calendar component.

We then check if each field we might use has a value in it - such as a start date and end date

If so, we map the values from each of those fields to variables in our Add to Calendar component (such as atc_start, atc_title, etc)

Now, when you view a node, you will see your Add to Calendar widget on any nodes that the editors choose to put it. You can see a sample of the Add to Calendar widget in my PatternLab.

Simple, once I figured it out.

Got an improvement for this? The comments are open.

Categories: Drupal

Robot Entertainment closing servers for Orcs Must Die! Unchained and Hero Academy games

Social/Online Games - Gamasutra - 8 January 2019 - 1:10pm

Robot Entertainment is all at once closing down three games, saying that it's no longer sustainable to continue to keep them online and playable. ...

Categories: Game Theory & Design

A2J Viewer

New Drupal Modules - 8 January 2019 - 12:51pm

This module integrates the Center for Computer-Assisted Legal Instruction' A2J Author Viewer 6 into Drupal, allowing for the delivery of standalone A2J interviews within Drupal websites. It requires the A2J Viewer library.

Categories: Drupal

Splash Damage is cutting monetization from its free-to-play game Dirty Bomb

Social/Online Games - Gamasutra - 8 January 2019 - 12:10pm

Dirty Bomb is going free-to-play, in the most literal interpretation of the term. Following an update next week, all monetization will be patched out of the game. ...

Categories: Game Theory & Design

Img Extended

New Drupal Modules - 8 January 2019 - 11:04am

The Image Extended module allows you to add files with extensions like eps, svg, pdf or tiff on your website fully integrated into the image module.
Instead of having a form with multiple fields, an image field and a file field for pdf, eps, tiff, svg, this functionality is integrated into one field.

If you upload a file, you can have a preview in the upload section as well as an image linked to the source in a new browser tab for each format.

You can choose which format is available, the size of the file, if private or public like the core image module.

Categories: Drupal

Come to GDC 2019 and learn to help more people find (and play!) your game

Social/Online Games - Gamasutra - 8 January 2019 - 10:45am

Knowing how to get your game in front of the people who will enjoy it most has never been more important, and if you want to sharpen your skills, GDC 2019 in March is the place to be! ...

Categories: Game Theory & Design

Entity Quicklook

New Drupal Modules - 8 January 2019 - 9:55am

Render an entity in a modal using views.

Categories: Drupal

Request info

New Drupal Modules - 8 January 2019 - 9:43am

This is a tiny helper to add request information to Drupal's status report. This is helpful to verify that Drupal is configured correctly; e.g., trusted reverse proxy addresses are configured correctly and HTTP headers are followed.

Categories: Drupal

Dries Buytaert: Refreshing the Drupal administration UI

Planet Drupal - 8 January 2019 - 8:20am

Last year, I talked to nearly one hundred Drupal agency owners to understand what is preventing them from selling Drupal. One of the most common responses raised is that Drupal's administration UI looks outdated.

This critique is not wrong. Drupal's current administration UI was originally designed almost ten years ago when we were working on Drupal 7. In the last ten years, the world did not stand still; design trends changed, user interfaces became more dynamic and end-user expectations have changed with that.

To be fair, Drupal's administration UI has received numerous improvements in the past ten years; Drupal 8 shipped with a new toolbar, an updated content creation experience, more WYSIWYG functionality, and even some design updates.

A comparison of the Drupal 7 and Drupal 8 content creation screen to highlight some of the improvements in Drupal 8.

While we made important improvements between Drupal 7 and Drupal 8, the feedback from the Drupal agency owners doesn't lie: we have not done enough to keep Drupal's administration UI modern and up-to-date.

This is something we need to address.

We are introducing a new design system that defines a complete set of principles, patterns, and tools for updating Drupal's administration UI.

In the short term, we plan on updating the existing administration UI with the new design system. Longer term, we are working on creating a completely new JavaScript-based administration UI.

The content administration screen with the new design system.

As you can see on Drupal.org, community feedback on the proposal is overwhelmingly positive with comments like Wow! Such an improvement! and Well done! High contrast and modern look..

Sample space sizing guidelines from the new design system.

I also ran the new design system by a few people who spend their days selling Drupal and they described it as "clean" with "good use of space" and a design they would be confident showing to prospective customers.

Whether you are a Drupal end-user, or in the business of selling Drupal, I recommend you check out the new design system and provide your feedback on Drupal.org.

Special thanks to Cristina Chumillas, Sascha Eggenberger, Roy Scholten, Archita Arora, Dennis Cohn, Ricardo Marcelino, Balazs Kantor, Lewis Nyman,and Antonella Severo for all the work on the new design system so far!

We have started implementing the new design system as a contributed theme with the name Claro. We are aiming to release a beta version for testing in the spring of 2019 and to include it in Drupal core as an experimental theme by Drupal 8.8.0 in December 2019. With more help, we might be able to get it done faster.

Throughout the development of the refreshed administration theme, we will run usability studies to ensure that the new theme indeed is an improvement over the current experience, and we can iteratively improve it along the way.

Acquia has committed to being an early adopter of the theme through the Acquia Lightning distribution, broadening the potential base of projects that can test and provide feedback on the refresh. Hopefully other organizations and projects will do the same.

How can I help?

The team is looking for more designers and frontend developers to get involved. You can attend the weekly meetings on #javascript on Drupal Slack Mondays at 16:30 UTC and on #admin-ui on Drupal Slack Wednesdays at 14:30 UTC.

Thanks to Lauri Eskola, Gábor Hojtsy and Jeff Beeman for their help with this post.

Categories: Drupal

Pages

Subscribe to As If Productions aggregator