Those who dance are considered insane by those who can't hear the music.
Gamemastering is built on hope. We write our session notes, draw our maps, and paint our minis hoping for a great game. And sometimes things don’t work out. It’s happened to all of us. In this article, we’ll look at three tough situations, and how (maybe) to make something good out of them.
It Doesn’t Run
This happens to all of us. You’re all ready to run, and you don’t get enough players to have a session. Often it’s unavoidable, people are busy and sometimes real life has to take priority. But it’s still tough in the moment. You were hoping for a great session, and it didn’t happen. So what’s good about that?
First of all, you are now ahead in your preparations. If this session is all done, you can focus on the session after that and get ahead. Second, you can refine the session that didn’t run. If you are like me, you sometimes have sessions that are almost ready to run, and you fake the rest on the fly. If we have a canceled session, maybe we can prepare a little more and make it even more memorable for next time. Lastly, sometimes we need a break. No shows can be life’s way of helping prevent GM burnout.
It Runs, But With “Issues”
Sometimes things seem to be chugging along just fine, and then “it” happens. It can be rules-lawyering, egos, or player to player snarkiness. Also, to be truthful, sometimes even GM’s say things they shouldn’t during a session. If you haven’t had “it” happen in some form or another I’d be shocked. So what do we do?
Sometimes bad situations can be a chance for personal growth. Not all problems are unsolvable, and often an “I’m sorry” or a quick do-over can smooth things over. Sometimes you can handle it right then, sometimes you may be better to wait and send the person an email the next day. There’s no quick formula for every situation.
The bad situation may also give us some insight into where our scenarios can be improved. Maybe we can avoid these kinds of issues in the future by knowing some of the rules better or how to handle certain player choices better. Or maybe we can look at how we react to some of our players and how to better temper our own responses.
If issues cause a player to leave a group, that’s not the end of the world either. While it can be difficult, in the long run it might be the best thing. If there are personality mismatches or differing game expectations, a split might be necessary. (Now, if all of your players leave, that’s another column entirely).
It Runs, and “Meh.”
Sometimes this is worse than not running at all. You’ve put your heart, soul, and creativity into a particular situation, and the players aren’t really into it. You may get a “thank you” afterwards, but you are left with the sense that the session was below average. You can hear the inner “Meh.” (Maybe you’re thinking that about this column right about now.)
Don’t despair. Perhaps you can go home and tweak the scenario to make it a little less “Meh.” Add some variety to the combat situations, sprinkle in some more physical or mental challenges, flesh out your NPC’s to add a little sparkle to the roleplaying opportunities. Then try to find a chance to run it with a different group to see if these changes work.
It’s also a chance to consider our GM techniques. How well were we able to involve everyone at the table, even the quiet players? Did we give the players enough detail about the situations and possible choices? Did we manage the pacing of the game properly, or did it drag or race along when it shouldn’t have?
Let’s leave this topic with one word of caution: it may not have been you. Perhaps some of the players were tired or going through a rough patch. Also, there may have been a mismatch between your playing style and their expectations. You can’t please everyone, and nothing can please some people. That’s true in life and in gaming. Sometimes you have to ignore people and their “Meh’s” and move on.
Don’t let this article discourage you from considering gamemastering. While it’s not all roses, it’s not all thorns either. There are times when things won’t go the way we want or expect. Our hard work doesn’t always come to fruition, and is sometimes unappreciated. But those situations aren’t the norm. Most folks want to play and are grateful when you present them with the opportunity. Together we build something that’s more fun and creative than we could on our own.
How about you? Any tough situations or lessons learned from them? Share it below, folks.
In this week’s REST Easy tutorial, we tackle the process of adding entity references to your API endpoints. Entity references create relationships between two separate data structures in Drupal. Exposing that link within your API is critical to providing a comprehensive content model.
It is fitting that in football-crazed Barcelona, although we will have a plethora of tech talks, that we have at least one talk that highlights the sport! Whether you’re a fan of FC Barcelona or any football team for that matter, it is pretty impressive what a team can accomplish together. And although we aren’t goalies and midfielders, Adam Onishi's (onishiweb) talk will highlight how front-enders and Drupalers can go for the gold together.
It's not easy to build an Open Source software company.
Canonical recently has made a change to its intellectual property policy. The new policy prevents developers from distributing altered binary versions of Ubuntu. Users are still allowed to distribute unaltered Ubuntu freely, but if they make changes to Ubuntu, Canonical wants developers to either go through a review process or remove all references to Canonical trademarks, Canonical logos, and proprietary software and recompile the Ubuntu archive without any of those.
This change has caused friction with the Open Source community; many are not happy with these restrictions as it goes against the culture of Open Source sharing and collaboration. After all, Ubuntu itself is built on top of the work of hundreds of thousands of Open Source developers, and now Ubuntu is making it difficult for others to do the same.
Canonical's stated intention is to protect its trademarks and reputation; they don't want anyone to call something "Ubuntu" when it's not actually "Ubuntu". I understand that. That aside, many understand that the unstated goal is to make money from licensing deals. The changes affect organizations that base their custom distributions on Ubuntu; it's easier to buy a license from Canonical than to figure how to remove all the trademarks, proprietary software, logos, etc.
Jono Bacon, Canonical's former community manager, wrote a great, balanced post about the situation.
My thoughts? I understand Canonical has to find ways to make money. Most companies are downright greedy, but not Canonical or Mark Shuttleworth. I find the Open Source community "penny wise and pound foolish" about the situation.
I can relate because Canonical, like Acquia, is among a small group of Open Source companies that try to do good, and do well at scale. We invest millions of dollars each year contributing to Open Source: from engineering, to marketing, to sponsoring community events and initiatives. It is not easy to build a software company on Open Source, and we all struggle to find the right balance between giving back and making money. This is further complicated when competitors choose to give back less or don't give back at all. Companies like Canonical and Acquia are good for Open Source, and helping them find that balance is key. Don't forget to support those that give back.
This week, our partnership with game criticism site Critical Distance brings us picks from Kris Ligman on topics ranging from philosophy in Pillars of Eternity to a new series aimed at demystifying MOBAs and eSports. ...
The monthly Drupal core bug fix/feature release window is scheduled for this Wednesday. However, there have not been enough changes to the development version since the last bug fix/feature release to warrant a new release, so there will be no Drupal core release on that date. (I had hoped to get a release done, but scheduling issues plus the work involved in putting out a large security release in August made it impossible.) A Drupal 7 bug fix/feature release during the October window is likely instead.
Upcoming release windows include:
- Wednesday, September 16 (security release window)
- Wednesday, October 7 (bug fix/feature release window)
We recently teamed up with Drupalize.me to produce a brand new (free!) video tutorial: "Introduction to RedHen CRM."
In this introductory video, you'll tour RedHen CRM's central features, get a detailed walkthrough of the setup process, and learn a few of RedHen's cool tricks, like duplicate management (a pet feature of mine). This is a great resource for anyone who is looking for a step-by-step guide to setting up and configuring RedHen, or just wants to learn more about it!
Continuing in our series of integrating CRMs with Drupal, we're now going to take a look at CiviCRM, an open-source, web-based CRM aimed at charities and non-profits which integrates closely with Drupal, Joomla and WordPress.
Have you ever wondered how Drupal does what it does? Good, me too. In this series of posts, I'm going to explain what Drupal is doing behind the scenes to perform its magic.
In Part 1, we'll keep it fairly high level and walk through the path a request takes as it moves through Drupal. In later parts, we'll take deeper dives into individual pieces of this process.Step 0: Some background information
For this example, let's pretend that George, a user of your site, wants to visit your About Us page, which lives at http://oursite/about-us.
Let's also pretend that this page is a node (specifically, the node with nid of 1) with a URL alias of about-us.
And to keep things simple, we'll say that we're using Apache as our webserver, and there's nothing fancy sitting in front of Drupal, such as a caching layer or the like.
So basically, we're talking about a plain old Drupal site on a plain old webserver.Step 1: The request hits the server
There's some pretty hot action that happens before Drupal even sees the request. George's browser sends a request to http://oursite.com/about-us, and this thing we call the internet figures out that that should go to our server. If you're not well versed on how that part happens, you may benefit from reading this infographic on how the internet works.
Once our server has received the request, that's when the fun begins. This request will land on port 80, and Apache just so happens to be listening on that port, so Apache will immediately see the request and decide what to do with it.
Since the request is going to oursite.com then Apache can look into its configuration files to see what the root directory is for oursite.com (along with lots of other info about it which is out of scope for this post). We'll say that the root directory for our site is /var/www/oursite, which is where Drupal lives. So Apache is going to send the request there.Step 2: The .htaccess file
But Drupal hasn't taken over just yet. Drupal ships with a .htaccess file which is a way of telling Apache some things. In fact, Drupal's .htaccess tells Apache a whole lot of things. The most important things it does are:
- Protects files that could contain source code from being viewable, such as .module files or .inc files, both of which contain PHP.
- Allows requests that point directly to files in the filesystem to pass through without touching Drupal.
- Redirects all other requests to Drupal's index.php file.
It also does some other fancy things such as disabling directory indexes and allowing Drupal to serve gzipped CSS and JS, but those are the biggies.
So, in our case, Apache will see that we're looking for /about-us, and will say:
- Is this request trying to access a file that it shouldn't? No.
- Is this request directly pointing to a file in the filesystem? No.
- Then this request should be sent to index.php!
And away we go...Step 3: Drupal's index.php file
Finally, we have reached Drupal, and we're looking at PHP. Drupal's index.php is super clean, and in fact only has 4 lines of code, each of which are easy to understand.Line 1: Define DRUPAL_ROOT
php define('DRUPAL_ROOT', getcwd());
This just sets a constant called DRUPAL_ROOT to be the value of the current directory that index.php is in. This constant is used all over the place in the Drupal core codebase.
In our case, this means that DRUPAL_ROOT gets set to /var/www/oursite.Lines 2 and 3: Bootstrap Drupal
php require_once DRUPAL_ROOT . '/includes/bootstrap.inc'; drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
These lines run a full Drupal bootstrap, which basically means that they tell Drupal "Hey, grab all of the stuff you're going to need before we can get to actually handling this request."
For more information about the bootstrap process, see Part 2 of this series.Line 4: Do everything else
This simple looking function is where the heart and soul of Drupal lives. For more information about what happens in this ball of wax, visit the Menu Router chapter.
Time has almost come! The yearly Europe DrupalCon will start on September 21nth 2015 in Barcelona. It will be my fist time on a DrupaCon even if I am working with Drupal for 7 years now. Don't ask me why, there are no excuses.
As a frontend developer and a freelancer it was too hard for me to select the sessions to attend. DrupalCon hosts the best of the best talks for Drupal out there and the benefits for Drupal *ers is enormous. Sessions will be recorded but live sessions are these that matter.
So, after a deep review on each session I decided to attend sessions that are dealing with the keywords below (notice that order matters):
- CI (Continuous Integration) and CD (Continuous Development)
- Drupal 8 plug system
- Headless Drupal
I am sure that with some sessions (eg these related with Docker or AngularJS) there will be a "crowding". Remember that. It happens everywhere, from local meetups to large events. Docker, Headless and Devops are here to stay and will bother us for years. Thankfully Drupal with the new 8.x version is "up to date" with the new technologies and methods and the DrupalCon shows that movement clearly.
Here is My Schedule (I know that there are duplicates or even triplicates but I will decide last minute. Maybe after asking other attendees...)
09/22/2015 - 11:00-09/22/2015 - 12:00 Session Speaker(s) Experience level Room Symfony for Drupal developers Crell Intermediate 115
09/22/2015 - 13:00-09/22/2015 - 14:00 Session Speaker(s) Experience level Room Drupal development with Vagrant 128 Fundamentals of Front-End Ops prestonso Intermediate 111: Adyax Docker powered team and deployment daven Intermediate 118-119: Platform.sh
09/22/2015 - 14:15-09/22/2015 - 15:15 Session Speaker(s) Experience level Room Drupal 8 Plugin Deep Dive EclipseGc Advanced 116: Pantheon Headful Drupal nod_ Intermediate 122-123: Interoute
09/22/2015 - 15:45-09/22/2015 - 16:45 Session Speaker(s) Experience level Room Composer and Drupal 8 webflo, tstoeckler Intermediate 122-123: Interoute Dependency Injection, what, why, how and when mr_r_miller Intermediate 115
09/22/2015 - 17:00-09/22/2015 - 18:00 Session Speaker(s) Experience level Room Expose Drupal with RESTful e0ipso Intermediate 112: Exove Caching at the Edge: CDNs for everyone Wim Leers, Fabianx Advanced 117: Acquia
09/23/2015 - 10:45-09/23/2015 - 11:45 Session Speaker(s) Experience level Room Local vs. Remote Development: Do Both by Syncing Your Site From Kitchen to Cloud With Jenkins SolomonGifford Beginner 116: Pantheon Prototypes and Drupal: from designing in-browser to implementing custom templates ygerasimov, mortenc Intermediate 111: Adyax
09/23/2015 - 13:00-09/23/2015 - 14:00 Session Speaker(s) Experience level Room Docker and DevOps – Building platforms globally William Morrish - Interoute Intermediate 120-121 Linked Data 101: The Non-Terrifying Intro to Semantic Content nozurbina Intermediate 115
09/23/2015 - 14:15-09/23/2015 - 15:15 Session Speaker(s) Experience level Room Drupal and Security: what you need to know scor, klausi Intermediate 111: Adyax
09/23/2015 - 15:45-09/23/2015 - 16:45 Session Speaker(s) Experience level Room Hassle-free Hosting and Testing with DevShop & Behat. Jon Pugh Intermediate 112: Exove Decoupling Drupal modules into PHP libraries bojanz Advanced 111: Adyax
09/23/2015 - 17:00-09/23/2015 - 18:00 Session Speaker(s) Experience level Room What's your type? Andreu Balius Intermediate 113: Amazee Labs Perfecting Drupal IA: Harmonious Menus, Paths, and Breadcrumbs Jody Lynn Intermediate 118-119: Platform.sh
09/24/2015 - 10:45-09/24/2015 - 11:45 Session Speaker(s) Experience level Room Making Drupal a better out-of-the-box product: Report on usability testing results and how we can make 8.1.x+ shine webchick, Bojhan, LewisNyman Beginner 122-123: Interoute Building the Front End with Angular.js ceng Intermediate 112: Exove
09/24/2015 - 13:00-09/24/2015 - 14:00 Session Speaker(s) Experience level Room CIBox - full stack open source Continuous Integration flow for Drupal/Symfony teams podarok, ygerasimov Intermediate 113: Amazee Labs
09/24/2015 - 14:15-09/24/2015 - 15:15 Session Speaker(s) Experience level Room The wonderland of HTTP in PHP dawehner Intermediate 115 Introducing Probo.CI tizzo Intermediate 118-119: Platform.sh
Manage Gitlab accounts inside the Drupal.
This module is a good helper module for those modules which builds extra functionalities over the Gitlab module in Drupal (ex.: Gitlab File Field). With this module the administrators could store Gitlab accounts in the Drupal and the developers could work with these accounts in their modules.
This module provides a hidden field widget for an entity reference field.
It is dependent upon the following modules:
This field gets values populated to it through query parameters on the entity edit forms.
This summer, I went to two high school reunions. My own, dinner and drinks at a local tavern, and my wife’s, a picnic held at an old country barn. (1)
I was reminded that the occasion of a reunion can serve as solid backstory to explain how an adventuring party comes together.
While in real life, I don’t think any of my classmates would have jumped at a suggestion to form up ranks, designate one of us a cleric, and go then plunder the nearby coal mines.
But still, in a fantasy setting, it is plausible enough. Especially since no one in a fantasy setting would be forced to choose adventure or leaving behind a family-style serving of tavern fried chicken and mostaccioli (2).
I am reminded that the first Dragonlance adventuring party was formed in a reunion of sorts. The companions had gone out into Krynn singly, seeking a sign of the old gods. Not finding any (3), the old crew, except for the black-hearted Kitiara, reformed at the Inn of the Last Home, ate some of Tika’s fried potatoes, and set off to foil the scheme of the dark dragon queen.
Menu selections aside, a reunion gathering gives built-in reasons why the PCs would be familiar with one another, but not necessarily a close-knit group. Yes, they grew up together, or trained together, or once served a common cause together — but had since gone their separate ways.
This works even with first-level characters, because there’s nothing to say that as individuals the PCs accomplished any adventuring goals in the interim. The real adventure begins at this point.
Reunion backstories are also good chances to play the “how do I know the person on my left” style of character creation. A chain of connections is what draws the PCs to one another, but doesn’t guarantee that EVERY member is friends with every other one.
If you’re inclined that first session can be done over a shared meal. That way, the players around the table will be invested in the same memory. Good food. Old friends.
And evil to vanquish.
- Yes, we both attended small high schools – in rural areas.
- A central Illinois flavor favorite, if ever there was one.
- I’ve always wondered at the companions’ collective failure at that, considering the Dragonlance gods proved to be the most meddlesome of any fantasy world that I can recall. It was hard not bumping into one of their avatars, as I recall. Fizbin, anyone?