Tidelift raises $25 million series B

Dries Buytaert - 7 January 2019 - 8:30am

Tidelift, which provides organizations with commercial-grade support for Open Source software and pays part of the proceeds to software maintainers, raises a $25 million Series B. I hadn't heard about Tidelift before, but it turns out their office is 300 meters from Acquia's. I reached out and we're going to grab a coffee soon.

Categories: Drupal

Spatiality in Game Design - by Fabian Fischer Blogs - 7 January 2019 - 8:13am
A strong focus on spatiality can lead to a large variety of interesting situations, incentivize intuitive decision-making and foster depth and emergence. This article describes a few outstanding examples of spatial gameplay design.
Categories: Game Theory & Design

Acro Media: Online Cannabis Sales: Open Source vs. SaaS

Planet Drupal - 7 January 2019 - 7:45am
What we can learn from day one of legal online cannabis sales in Canada

On October 17, 2018, Canada took a progressive step forward as the sale of recreational cannabis became legal for the entire country. It was the end of a prohibition, sparking a wave of new business opportunity. It’s hard to find official numbers for Canada as a whole, but it’s estimated that there were about 212,000 first-day sales across the country worth approximately $28 million! We thought it would be a good opportunity to show some of the benefits of open source vs. SaaS solutions for online cannabis.

First off, It’s hard to say exactly how many transactions occurred online for Canada as a whole. It’s up to each province and territory to decide how they want sales to proceed and stats are quite limited at this point. We do, however, have solid information for a couple smaller provinces that we can start with. Then we can expand with speculation after that.

What we know Cannabis Yukon

Cannabis Yukon, the Yukon government run retail outlet, had a combined online and in-store sales totalling about $59,900 (source). About 25% of that number, roughly $15,000, was transacted online. The online retail outlet uses the open source platform Drupal.

PEI Cannabis

PEI Cannabis, the Prince Edward Island government run retail outlet, had a combined online and in-store sales totalling about $152,000 (source). About 7% of that number, roughly $21,000, was transacted online. The online retail outlet uses the SaaS platform Shopify. It’s interesting to note that Shopify also runs the provincial online pot shops for Ontario, British Columbia and Newfoundland.

Functionality is the same

All ecommerce cannabis outlets in Canada, government or private, are going to have the same features. They need to block access to minors, they need to sell products based on weight and they need to restrict the maximum amount of cannabis an individual can purchase at one time. All other functionality required is standard ecommerce. Functionality-wise, Cannabis Yukon and PEI Cannabis do the same thing. Whether it’s open source or SaaS, there isn’t an edge either way there.

Where open source has the advantage

Where it gets interesting, and where the Yukon Government is in a great position to succeed, is commerce architecture and service fees. These are a couple of big reasons why open source is really catching fire in the ecommerce marketplace.

Commerce architecture

Yukon Cannabis is built on the Drupal platform. It’s open source software meaning there are no service fees to use and anyone who uses it can customize and innovate the software however they like. Development can be done in-house or with any 3rd party development agency familiar with the underlying code, mainly PHP.

An advantage to using a platform like Drupal is that it can integrate and talk to other services your operation may use for accounting, marketing, inventory, customer management, etc. Integrations and automation eliminate swivel chair processes that restrict business growth.

PEI Cannabis, on the other hand, is somewhat vendor locked using the Shopify platform. Shopify does have a rich ecosystem of integrations, but if there’s ever a need to develop a new integration, PEI Cannabis is restricted to dealing with only Shopify or their small group of partners. That usually means high cost.

Service fees

When a sale is made using a SaaS platform, a certain percentage of the sale is lost to taxes and additional platform specific transaction fees. In the case of Shopify Plus, the enterprise fee structure is $2,000 per month + 0.25% per transaction, capping at a maximum of $42,000 per month (source). You can optionally use ‘Shopify Payments’ instead which carries a transaction fee of 1.6% + 30 cents per transaction. This would be a better way to go only if you don’t require any other payment gateways, but in our experience that isn’t the case. Finally, in addition to Shopify’s fees, the platform has an extension library to extend the functionality to your store. Most of these extensions carry their own monthly fee and there’s a very good chance you would need some of them.

With SaaS ecommerce platforms like Shopify, year after year the cost of ownership increases. At minimum, the yearly fees paid to Shopify amount to $24,000 and can rise as high as $480,000. That doesn’t include any additional extensions that you use or any payment gateway fees. PEI Cannabis must pay these fees (and so do the governments of BC, Ontario and Newfoundland who also use Shopify).

Open source ecommerce platforms, on the other hand, don’t necessarily have any of these additional fees. Aside from the standard payment gateway fees and hosting fees, Yukon Cannabis pays no additional monthly or yearly licensing fee to use their ecommerce platform. Whether they sell $15,000 or $15 million, the investment that they’ve made into the development of their website should pay for itself quite quickly, potentially within a year.

Furthermore, provincial government cannabis retailers are essentially public companies. A large portion of the profit made is to be distributed at the provincial and federal levels to support various public services and initiatives. By utilizing open source technology and therefore avoiding platform-specific fees, the Yukon government will have more capital available for their public services and initiatives. Yukon constituents should be quite happy about that!

By utilizing open source technology and therefore avoiding platform-specific fees, the Yukon government will have more capital available for their public services and initiatives. Yukon constituents should be quite happy about that!

Service fee breakdown

Here’s a rough breakdown of potential monthly and annual platform service fees based on some of the numbers we know. We know the combined (online and in-store) sales from day one were elevated due to the hype of legalization, and we know that BC sales dropped by 70% on day two. For our fee breakdown, we’ll take the 70% reduced amount from the combined total numbers we know and use that to calculate a 30 day monthly sales estimate. We’ll use the combined total because most ecommerce platforms also support an official in-store point of sale component. This is all speculation of course, but it still shows realistic ecommerce sales numbers and how service fees accumulate based on them.

While the numbers shown below may appear to be quite large at first, Statistics Canada, the national statistics government agency, predicted back in September that legal cannabis sales for the first 3 months will be between $816 million and $1 billion nationwide. If that ends up being true, the numbers below would actually be grossly underestimated!

Est. Monthly Sales
Based on 30% of day one total x 30 days (XX/100 x 30) x 30 Open source
Annual and Monthly Fee: 0% Shopify Plus
Monthly including transaction fee
(calculator) Shopify Plus
(monthly x 12) Yukon Cannabis
30 day est: $539,100
Day one: $59,900 $0 $2,994.31 $35,931.72 PEI Cannabis
30 day est: $1,368,000
Day one: $152,000 $0 $4523.13 $54,277.56 Nova Scotia
30 day est: $5,940,000
Day one: $660,000 $0 $12,955.69 $155,468.28 Alberta
30 day est: $6,870,000
Day one: $730,000 $0 $14,670.97 $176,051.64 All of Canada *
30 day est: $252,000,000
Day one: $28,000,000 $0 $40,000 (cap)  $480,000 (cap)

* The government agency Statistics Canada predicts that legal cannabis sales in Canada will be between $816 million and $1 billion (source).

Where SaaS has the advantage

The biggest advantage that SaaS such as Shopify has over open source is the speed at which you can get your product to market and the simplicity of use.

If you’re just starting out and need to get an ecommerce site up and running quick, these services are turn-key and can get your product to market fast. The website management interface is clean and easy to use, and most people can do what they need to do with little to no training.

There is a reason why companies like Shopify are quite dominant and it’s largely because of the simplicity. While we strongly believe that you shouldn’t choose your platform based on features, many people are willing to pay extra to be able to do it all themselves.


Watching a new industry unfold in Canada has been fun. It’s interesting to see that both open source and SaaS has found its way into the legal cannabis marketplace. Clearly both open source and SaaS work for this industry, it’s more about what you’re willing to pay and what ecommerce ecosystem you think is best for your business and its future growth.

If you’re thinking about online cannabis retail (or any other online retail for that matter), Acro Media has the expertise and processes in place to help guide you to online commerce success. Try our Digital Commerce Assessment Tool to uncover problematic areas within your digital commerce operations.

Categories: Drupal

Designing Sausage Sports Club - by Chris Wade Blogs - 7 January 2019 - 7:30am
Lessons learned designing Sausage Sports Club, including a few deep dives into specific features.
Categories: Game Theory & Design

Side Hustling Advice from Full time Game Devs - by Larry&Brandon GDU Blogs - 7 January 2019 - 7:26am
Su and Peter both have full time jobs and have had illustrious careers spanning across gaming, film, and tech companies. Their partnership started over four years ago and currently their company, Ugo3D, has a potential valuation of $200 million dollars. T
Categories: Game Theory & Design

Squeaky Wheel's 2018 Year in Review - by Ryan Sumo Blogs - 7 January 2019 - 7:22am
I reflect on Squeaky Wheel's 2018, opining on conventions, keeping up motivation, and how the Steam algorithm changes affected us.
Categories: Game Theory & Design

Tomb of the Mask: Enemy Analysis - by Olin Olmstead Blogs - 7 January 2019 - 7:20am
A detailed look at the design of each enemy in Tomb of the Mask. A Pac-Man collect the dots in a maze style game for iOS and Android. The ghosts ain't got nothing on these bats, snakes, and flying monkeys.
Categories: Game Theory & Design

Kliuless #17: Bandersnatch, a Black Mirror on the Fourth Wall - by Kenneth Liu Blogs - 7 January 2019 - 7:19am
Each week I compile a gaming industry insights newsletter that I share with other Rioters, including Riot’s senior leadership. This edition is the public version that I publish broadly every week as well. Opinions are mine.
Categories: Game Theory & Design

Social Advocacy in Game Reviews - by Michael Heron Blogs - 7 January 2019 - 7:19am
What are the limits of social advocacy in game reviews? What should we be doing, what shouldn't we be doing, and what do we hope to gain by including our agendas in our game coverage.
Categories: Game Theory & Design

Unity Audio Import Optimisation - getting more BAM for your RAM - by Zander Hulme Blogs - 7 January 2019 - 7:17am
A guide to using Unity's audio import settings to help improve game performance.
Categories: Game Theory & Design

The evolution of video games as a storytelling medium, and the role of narrative in modern games - by Chris Stone Blogs - 7 January 2019 - 7:12am
This essay aims to investigate the topic of narrative in video games. Specifically, the evolution of narratives in games, and the role of narrative in today’s story-based games. Narrative is all around us; we can interpret all events as stories with plo
Categories: Game Theory & Design

Lullabot: JSON:API 2.0 Has Been Released

Planet Drupal - 7 January 2019 - 6:08am

Note: This article is a re-post from Mateu's personal blog.

I have been very vocal about the JSON:API module. I wrote articles, recorded videos, spoke at conferences, wrote extending software, and at some point, I proposed to add JSON:API into Drupal core. Then Wim and Gabe joined the JSON:API team as part of their daily job. That meant that while they took care of most of the issues in the JSON:API queue, I could attend the other API-First projects more successfully. I have not left the JSON:API project by any means, on the contrary, I'm more involved than before. However, I have just transitioned my involvement to feature design and feature sign-off, sprinkled with the occasional development. Wim and Gabe have not only been very empathic and supportive with my situation, but they have also been taking a lot of ownership of the project. JSON:API is not my baby anymore, instead we now have joint custody of our JSON:API baby.

As a result of this collaboration Gabe, Wim and I have tagged a stable release of the second version of the JSON:API module. This took a humongous amount of work, but we are very pleased with the result. This has been a long journey, and we are finally there. The JSON:API maintainers are very excited about it.

I know that switching to a new major version is always a little bit scary. You update the module and hope for the best. With major version upgrades, there is no guarantee that your use of the module is still going to work. This is unfortunate as a site owner, but including breaking changes is often the best solution for the module's maintenance and to add new features. The JSON:API maintainers are aware of this. I have gone through the process myself and I have been frustrated by it. This is why we have tried to make the upgrade process as smooth as possible.

What Changed?

If you are a long-time Drupal developer you have probably wondered how do I do this D7 thing in D8? When that happens, the best solution is to search a change record for Drupal core to see if it change since Drupal 7. The change records are a fantastic tool to track the things changed in each release. Change records allow you to only consider the issues that have user-facing changes, avoiding lots of noise of internal changes and bug fixes. In summary, they let users understand how to migrate from one version to another.

Very few contributed modules use change records. This may be because module maintainers are unaware of this feature for contrib. It could also be because maintaining a module is a big burden and manually writing change records is yet another time-consuming task. The JSON:API module has comprehensive change records on all the things you need to pay attention when upgrading to JSON:API 2.0.


As I mentioned above, if you want to understand what has changed since JSON:API 8.x-1.24 you only need to visit the change records page for JSON:API. However, I want to highlight some important changes.

Config Entity Mutation is now in JSON:API Extras

This is no longer possible only using JSON:API. This feature was removed because Entity API does a great job ensuring that access rules are respected, but the Configuration Entity API does not support validation of configuration entities yet. That means the responsibility of validation falls on the client, which has security and data integrity implications. We felt we ought to move this feature to JSON:API Extras, given that JSON:API 2.x will be added into Drupal core.

No More Custom Field Type Normalizers

This is by far the most controversial change. Even though custom normalizers for JSON:API have been strongly discouraged for a while, JSON:API 2.x will enforce that. Sites that have been in violation of the recommendation will now need to refactor to supported patterns. This was driven by the limitations of the serialization component in Symfony. In particular, we aim to make it possible to derive a consistent schema per resource type. I explained why this is important in this article.

Supported patterns are:

  • Create a computed field. Note that a true computed field will be calculated on every entity load, which may be a good or a bad thing depending on the use case. You can also create stored fields that are calculated on entity presave. The linked documentation has examples for both methods.
  • Write a normalizer at the Data Type level, instead of field or entity level. As a benefit, this normalizer will also work in core REST!
  • Create a Field Enhancer plugin like these, using JSON:API Extras. This is the most similar pattern, it enforces you to define the schema of the enhancer.
File URLs

JSON:API pioneered the idea of having a computed url field for file entities that an external application can use without modifications. Ever since this feature has made it into core, with some minor modifications. Now the url is no longer a computed field, but a computed property on the uri field.

Special Properties

The official JSON:API specification reserves the type and id keys. These keys cannot exist inside of the attributes or relationships sections of a resource object. That's why we are now prepending {entity_type}_ to the key name when those are found. In addition to that, internal fields like the entity ID (nid, tid, etc.) will have drupal_internal__ prepended to them. Finally, we have decided to omit the uuid field given that it already is the resource ID.

Final Goodbye to _format

JSON:API 1.x dropped the need to have the unpopular _format parameter in the URL. Instead, it allowed the more standard Accept: application/vnd.api+json to be used for format negotiation. JSON:API 2.x continues this pattern. This header is now required to have cacheable 4XX error responses, which is an important performance improvement.

Benefits of Upgrading

You have seen that these changes are not very disruptive, and even when they are, it is very simple to upgrade to the new patterns. This will allow you to upgrade to the new version with relative ease. Once you've done that you will notice some immediate benefits:

  • Performance improvements. Performance improved overall, but especially when using filtering, includes and sparse fieldsets. Some of those with the help of early adopters during the RC period!
  • Better compatibility with JSON:API clients. That's because JSON:API 2.x also fixes several spec compliance edge case issues.
  • We pledge that you'll be able to transition cleanly to JSON:API in core. This is especially important for future-proofing your sites today.
Benefits of Starting a New Project with the Old JSON:API 1.x

There are truly none. Version 2.x builds on top of 1.x so it carries all the goodness of 1.x plus all the improvements.

If you are starting a new project, you should use JSON:API 2.x.

JSON:API 2.x is what new installs of Contenta CMS will get, and remember that Contenta CMS ships with the most up-to-date recommendations in decoupled Drupal. Star the project in GitHub and keep an eye on it here, if you want.

What Comes Next?

Our highest priority at this point is the inclusion of JSON:API in Drupal core. That means that most of our efforts will be focused on responding to feedback to the core patch and making sure that it does not get stalled.

In addition to that we will likely tag JSON:API 2.1 very shortly after JSON:API 2.0. That will include:

  1. Binary file uploads using JSON:API.
  2. Support for version negotiation. Allows latest or default revision to be retrieved. Supports the Content Moderation module in core. This will be instrumental in decoupled preview systems.

Our roadmap includes:

  1. Full support for revisions, including accessing a history of revisions. Mutating revisions is blocked on Drupal core providing a revision access API.
  2. Full support for translations. That means that you will be able to create and update translations using JSON:API. That adds on top of the current ability to GET translated entities.
  3. Improvements in hypermedia support. In particular, we aim to include extension points so Drupal sites can include useful related links like add-to-cart, view-on-web, track-purchase, etc.
  4. Self-sufficient schema generation. Right now we rely on the Schemata module in order to generate schemas for the JSON:API resources. That schema is used by OpenAPI to generate documentation and the Admin UI initiative to auto-generate forms. We aim to have more reliable schemas without external dependencies.
  5. More performance improvements. Because JSON:API only provides an HTTP API, implementation details are free to change. This already enabled major performance improvements, but we believe it can still be significantly improved. An example is caching partial serializations.
How Can You Help?

The JSON:API project page has a list of ways you can help, but here are several specific things you can do if you would like to contribute right away:

  1. Write an experience report. This is a issue in the JSON:API queue that summarizes the things that you've done with JSON:API, what you liked, and what we can improve. You can see examples of those here. We have improved the module greatly thanks to these in the past. Help us help you!
  2. Help us spread the word. Tweet about this article, blog about the module, promote the JSON:API tooling in JavaScript, etc.
  3. Review the core patch.
  4. Jump into the issue queue to write documentation, propose features, author patches, review code, etc.

Photo by Sagar Patil on Unsplash.

Categories: Drupal

Wim Leers: JSON:API module version two

Planet Drupal - 7 January 2019 - 6:08am

Mateu, Gabe and I just released JSON:API 2.0!

Read more about it on Mateu’s blog.

I’m proud of what we’ve achieved. I’m excited to see more projects use it. And I’m confident that we’ll be able to add lots of features in the coming years, without breaking backwards compatibility. I was blown away just now while generating release notes: apparently 63 people contributed. I never realized it was that many. Thanks to all of you :)

I had a bottle of Catalan Ratafia (which has a fascinating history) waiting to celebrate the occasion. Why Ratafia? Mateu is the founder of this module and lives in Mallorca, in Catalunya. Txin txin!

If you want to read more about how it reached this point, see the July, October, November and December blog posts I did about our progress.

Categories: Drupal

Welcome Message

New Drupal Modules - 7 January 2019 - 5:32am
Categories: Drupal

Specbee: Drupal 8 Now or Drupal 9 later? What’s the right thing to do?

Planet Drupal - 7 January 2019 - 5:02am

Did you know, on an average an adult makes about 35000 decisions each day?! And suddenly, life feels more difficult. Most are mundane but taking the right step towards an important decision can turn you into a winner. Since the release of Drupal 8 in November 2015, Drupal website owners have been in a dilemma. To upgrade or not to upgrade. To migrate to Drupal 8 now or simply wait till Drupal 9 releases and completely skip 8. And to make things more knotty, there are PHP, Symfony and other version upgrades to keep track of too.

At this point, you might wonder why choose or stick with Drupal at all when everything seems so complex and tedious. Why shouldn’t I just switch to a rather simpler CMS where I can sit back and just let my content work its magic, you ask? Here’s the thing – Drupal is an open-source content management framework that is best known for the security, robustness and flexibility it offers. Without constant and consistent updates and patches, Drupal wouldn’t have been the relevant, dependable and trusted CMS that it is today. This continuous innovation approach has helped Drupal in offering new Drupal features, advanced functionalities and security patches with every minor release.

Categories: Drupal

Seasonal Product Recommendations

New Drupal Modules - 7 January 2019 - 2:57am

This module allows you to deliver a more personalized experience to your customers by sending product recommendations on the basis of the prevalent season to them. This will take the customer experience on your eCommerce website to the next level. Customers from different locations have different needs. Then why not customize the recommendations for them, accordingly.

Categories: Drupal


New Drupal Modules - 7 January 2019 - 2:23am

This is testing and i will delete it.

Categories: Drupal

Troy’s Crockpot: Character Background Generators

Gnome Stew - 7 January 2019 - 12:01am

When a GM is plotting a campaign, one of the things she or he wants to do is identify points of conflict that will directly affect the player characters.

Published adventures will have all sorts of thrilling moments and engaging encounters. But making the story personal can often be what makes it memorable — what brings it home.

You want to hit them where it hurts.

When the authors of Gnome Stew created Eureka: 501 Adventure Plots To Inspire Game Masters in 2010, we used Georges Polti’s list of 36 dramatic situations as a guide. Thirteen of the dramatic situations involve family or loved ones. Who the character loves and is loved by is essential to establishing those dramatic beats.

It’s Your Life

Over the holiday I caught up with some game-related reading, including digging into D&D’s Xanathar’s Guide to Everything (so I’m a year behind, shoot me).

Included in the book is a list of tables designed to generate a background for PCs. Tables such as this can be helpful because they provide additional material that a player might not have considered when coming up with a backstory. (Or, if the player isn’t inclined to do a backstory, at least it can provide the GM with an item or two that can be used as a personal hook).

Tables such as this should never be used slavishly. I think they work best when they serve as a menu that a player can select from.

As an exercise, I rolled up two character backgrounds using the Xanathar tables, then for comparison’s sake, did the same with two other tables I have found useful — one from the Hero Builder’s Guidebook (Wizards of the Coast, c. 2000) and the other from Pathfinder’s Ultimate Campaign (Paizo, c. 2013).


First: Dragonborn sailor/bard.

The dice produced a couple of interesting points: 1) The dragonborn came from a wealthy family that resided in a palace or castle, but whose mother is missing because she was imprisoned, enslaved or for some other reason was taken away. 2) The character is a gifted performer whose love of knowledge and stories was awakened by spending time in an old library, and who learned his craft from a master bard who was a human aristocrat, someone alive and famous.

Both of those things work well, and could even be combined together. The missing mom could be a victim of palace or imperial conflicts. She could be like Eleanor of Aquitaine, who spent close to 16 years in prison for siding with one of her sons over their claim to the crown. And perhaps this aristocrat is her keeper, by some arrangement with the father, but the PC can still visit and learn from them.

Second: Gnome fighter.

My favorite part of this random generation was the 11 siblings the chart produced. Big families produce lots of conflict, reasons to do things, reasons to NOT do things, and frankly, every time a character needs a brother or sister to this that or the other, you’ve got one. (“How many brothers and sisters do you have?”)

The other part of the conflict is built into the origin; the family lived on the frontier, on the edges of civilization, and that pop died and got eaten by monsters. Whatever that monster is — picking one is always fun — gives the gnome a built-in enmity for the rest of its career.

A life event that provides fertile ground for a revenge storyline is that the gnome was knocked out and left for dead in a feud with a rival adventurer over shares of a treasure. This adventurer is now an enemy.

Hero Builder

This generator provided me with a human from a family of refugees who established a homestead along the mountainous frontier. This character was raised in adventure territory, combat was a part of their lives.  Of her or his immediate family, only an older sister survives. However, there is a large extended family of uncles and cousins.

Why was the family on the run? Well, the generator said the family held dissident political views; they supported a rebellion. In fact, an ancestor achieved folk hero status as a failed rebel. That’s a legacy the character might wish to embrace or discard. Either approach can be interesting.

Pathfinder’s Ultimate Campaign

This generator produced a half-elf cleric who was raised among forest-dwelling elves as an only child.

Two events are pivotal for the character: 1) The PC was a convert to the faith, a decision that was heavily influenced by a current love interest. 2) The PC twice has had run-ins with the law, once imprisoned for smuggling and later for assaulting a close friend for religious reasons. Does this make the PC a zealot? Are they someone under the sway of another (the lover)? Does the newfound religion jive with the folks back in the forest home?

This character has the makings of a pariah, which is interesting. Maybe the only way they’ll find themselves is within a party of adventurers.


Obviously, different background generators do different things, emphasizing different aspects of lives. What I like about each:

Xanathar: It creates a conflict that is fresh and immediate, often familial, often involving a patron or teacher. The PC has to fill in the blanks a little bit more than in the others.  On its own, there are gaps. But if a PC pairs it up with the Backgrounds, Boons and Traits section of the character development, a more cohesive picture of their past takes shape.

Hero Builder: Family legacy is very important. Where you are from and who your parents were are key to your development. The apple does not fall far from the tree.  The ethics charts can be useful. I also found that religion and political beliefs factor in more strongly here than in the others.

Ultimate Campaign: Everything is driven by the PC’s character class, and secondarily, by their race. There is a darker tone to the background material; in all likelihood, something traumatic happened that spurred an adventuring career.


Categories: Game Theory & Design

Fuzzy Thinking: Strange Weapons

RPGNet - 7 January 2019 - 12:00am
Fuzzy games.
Categories: Game Theory & Design


Subscribe to As If Productions aggregator