Newsfeeds

Agiledrop.com Blog: 7 questions you're probably asking yourself when considering Open Social

Planet Drupal - 24 May 2019 - 2:49am

Open Social is a Drupal distribution that enables anyone to quickly & easily set up a platform for their own community, no matter its size or needs. In this post, we'll take a look at the platform's powerful capabilities.

READ MORE
Categories: Drupal

Elfsight Cookie Consent

New Drupal Modules - 24 May 2019 - 2:49am
Introduction

Elfsight Cookie Consent is a simple and customizable widget to let you create a cookie notification for your website users. The notification will appear as a bar or box immediately when a new user enters your site. You can choose to show a simple note or add a consent button, vary the position of the widget on the page and apply more customization managing a no-coding editor.

Categories: Drupal

Elfsight Age Verification

New Drupal Modules - 24 May 2019 - 2:43am
Introduction

Elfsight Age Verification extension will become your easiest tool to make an age-check popup for your site. The extension requests a confirmation that a visitor is old enough to view your content to open the access for fullaged visitors and divert the ones underaged. There are three verification formats, two possible scenarios after access denial, and an option to choose specific pages where to embed the widget. The interface has elements that you can paint and allows to upload your own pictures.

Categories: Drupal

Time and Time Again

Gnome Stew - 24 May 2019 - 2:00am

Keep the pressure on the players as the time loop keeps getting more dangerous…

Troy’s article on running a Ground Hog’s Day scenario reminded me of a Doctor Who one-shot I ran that put the characters in a time loop they had to solve from the inside. I thought it would be fun to follow up on Troy’s article and talk about that adventure and some of the tricks I used to get the players into the game.

A few years ago, my go-to game for convention one-shots was usually Doctor Who: Adventures in Time and Space. I adore the system and its flexibility, and while I knew not everyone was necessarily into the property, I came up with some non-canonical characters that let players easily step into a game with a modern setting and some weird, timey-wimey, wibbly-wobbliness.

All of these games were set in San Francisco. Why? Because I wanted to have a US metropolitan setting with a deep history and wildly varied terrain surrounding it. Some of the adventures I ran made better use of the setting than others, but the time loop scenario took fantastic advantage of the setting. After all, the players had to navigate the city multiple times to figure out how to solve the time loop.

I may have run this game using Doctor Who, but the concepts can be applied to almost any game where you want to work in a time loop adventure. Feel free to adapt and modify any of these concepts to your game.

Have a Strong Opening You Can Revisit Again and Again

The opening is probably one of the most crucial points in the game. Normally, I try and start one-shots with all the PCs in the same place so there’s no fuss or muss about getting everyone involved. In this scenario though, I deliberately started them in different locations so part of the adventure was figuring out how to coordinate together. I announced that it was a beautiful Wednesday in October at 2 pm and then asked, “What is your character doing right now?”

Going around the table, I played out a quick scene with each player, setting up what their character was doing. I kept notes on each one and focused on interesting and distinctive details in each scene. Here are some examples:

    • The Intern was at Starbucks in line behind an annoying young corporate type in a power suit ordering the most obnoxious soy latte drink you can imagine.
    • The Veterinarian was volunteering at the local shelter and trying to give one of the new intakes, a dirty but affectionate pit bull, a bath.
    • The Artist was trying to concentrate on a painting, but was distracted by the sound of a truck backing up outside their open windows.
    • The Historian was trying to read the newspaper, but was interrupted by a needy student that was again trying to convince them to give a better grade on a paper.
    • The Ex-Cop was in session for their court-mandated therapy and being annoyed by the touchy-feely therapist trying to get them to embrace their emotions.

The key is to find some distinctive moment in each of these scenes that you can call back on to signal that the time loop has reset. The sound of a truck backing up, the obnoxious coffee order from an arrogant businessman, the exuberant shaking of a wet dog happy to getting attention, the whiny wheedling plea of a student that couldn’t handle having gotten only a B, or the irritating calm of a therapist using the wrong tactics to reach their patient. Each of these became a signal to the players that the time loop had started over.

After the first play through of the opening scenes, I had the players make the equivalent of a willpower check to determine who figures out they’re stuck in a loop first.

Be Aware of Geographic Issues, But Stay Flexible

In this scenario, the Mission Blue Butterfly was a very important clue.

When I started the game off, I also took careful note of where each character was in the city. For this game, the players would need to reach a specific location to stop the device causing the time loop. For this scenario, the location was the Sutro Radio Tower, which is fairly close to the geographic center of the San Francisco peninsula, but that doesn’t mean it would be easy to reach.

I’m not into super tactical, realistic games, but I wanted to have enough verisimilitude in the way I ran the game to make sure players took into account how long it would take them to reach certain locations. Part of the scenario is having the players try different things each time to try and get to specific locations and slowly shaving their time down. At the same time, you don’t want to get caught up in being too pedantic about time and distance.

If someone gets stuck in a traffic jam during one iteration of the loop, assume they can easily avoid that issue the next time around. Each iteration of the time loop should let them get better at navigating from point A to point B. Take that into account as you reset the loop.

Have Fun With the Consequences

With a time loop scenario, the consequences of the PCs actions get reset every time the time loop resets. Have fun with this! For this scenario, the loop was set to exactly an hour, so the characters were often caught in the middle of the action as the time loop reset.

    • While recklessly driving through the city, one of the characters gets into a car accident. BOOM, time reset.
    • A character gets rude with an NPC that’s getting in the way and the situation escalates into a fight. BOOM, time reset.
    • While sneaking into a place they’re not supposed to be, one character comes face to face with a bad guy that has a gun. Literal BOOM as they get shot and time resets.

Of course, another fun aspect is when the time loop is finally resolved, you can remind the players of the short-cuts they took that might make the current timeline a little more interesting. As a little epilogue, point out that the Gambler now needs to deal with the fact that they stole a car from their attractive one-night stand they quickly ditched an hour ago.

I really enjoyed running this scenario and I highly recommend giving the concept a shot. It works really well for modern or futuristic games where characters have the means of communicating quickly and easily with one another, but you can make it work in a wide variety of settings.

Troy’s article on running a Ground Hog’s Day scenario reminded me of a Doctor Who one shot I ran that put the characters in a time-loop they had to solve from the inside. Hopefully this article helps a little when you run your own time loop scenario.

Categories: Game Theory & Design

OPTASY: Cache API in Drupal 8: How Is It Any Different from Drupal 7 Cache System?

Planet Drupal - 24 May 2019 - 1:19am
Cache API in Drupal 8: How Is It Any Different from Drupal 7 Cache System? radu.simileanu Fri, 05/24/2019 - 08:19

What makes the Cache API in Drupal 8 any better than Drupal 7's cache system? What's so revolutionary about it? Which of the old limitations does it remove? What are those new concepts and terminology that you should learn about?

And, most of all: how complex is it to set up a cache in Drupal 8 for a specific use case?

You might have already bumped into terms like “max-age”, "context cache" or "cache tags".
 

Categories: Drupal

Virtual reality can spot navigation problems in early Alzheimer's disease

Virtual Reality - Science Daily - 23 May 2019 - 5:26pm
Virtual reality (VR) can identify early Alzheimer's disease more accurately than 'gold standard' cognitive tests currently in use, new research suggests.
Categories: Virtual Reality

Red Route: There isn't a module for that already?

Planet Drupal - 23 May 2019 - 4:00pm

This article was originally posted on the Capgemini Engineering blog

Sometimes clients ask for the wrong thing. Sometimes developers build the wrong thing, because they didn't ask the right questions. If you're solving the wrong problem, it doesn't matter how elegant your solution is.

One of the most important services that we as developers and consultants can provide is being able to help guide our clients to what they need, rather than simply giving them what they want. Sometimes those two things are aligned, but more often than not, figuring out the right thing to build takes some discovering.

Why don't wants and needs match? It might be because the client hasn't spent enough time thinking about the question, or because they haven't approached it from the right angle. If that's the case, we can help them to do that, either by asking the right questions or by acting as their rubber duck, providing a sounding board for their ideas. Alternatively, it might be because, as a marketing or content specialist, they lack sufficient awareness of the potential technological solutions to the question, and we can offer that.

Once you've properly understood the problem, you can start to look for a solution. In this article, I'll talk about some examples of problems like this that we've recently helped clients to solve, and how those solutions led us to contribute two new Drupal modules.

There must be a module for that

Sometimes the problems are specific to the client, and the solutions need to be bespoke. Other times the problems are more general, and there's already a solution. One of the great things about open source is that somebody out there has probably faced the same problem before, and if you're lucky, they've shared their solution.

In general, I'd prefer to avoid writing custom code, for the same reasons that we aren't rolling our own CMS. There are currently over 43,000 contributed modules available for Drupal, some of which solve similar problems, so sometimes the difficult part is deciding which of the alternatives to choose.

Sometimes there isn't already a solution, or the solution isn't quite right for your needs. Whenever that's the case, and the problem is a generic one, we aim to open source the solutions that we build. Sometimes it's surprising that there isn't already a module available. Recently on my current project we came across two problems that felt like they should have been solved a long time ago, very generic issues for people editing content for the web - exactly the sort of thing that you'd expect someone in the Drupal community to have already built.

How hard could it be?

One area that sometimes causes friction between clients and vendors is around estimates. Unless you understand the underlying technology, it isn't always obvious why some things are easy and others are hard.

XKCD -tasks

Even experienced developers sometimes fail to grasp this - here's a recent example where I did exactly that.

We're building a site in Drupal 8, making heavy use of the Paragraphs module. When adding a webform to a paragraph field, there's a select list with all forms on the site, sorted alphabetically. To improve usability for the content editors, the client was asking for the list to be sorted by date, most recently created first. Still thinking in Drupal 6 and 7 mode, I thought it would be easy. Use a view for selection, order the view by date created, job done - probably no more than half an hour's work. Except that in Drupal 8, webforms are no longer nodes - they're configuration entities, so there is no creation date to order by. What I'd assumed would be trivial would in fact require major custom development, the cost of which wouldn't be justified by the business value of the feature. But there's almost always another way to do things, which won't be as time-consuming, and while it might not be what the client asked for, it's often close enough for what they need.

What's the real requirement?

In the example above, what the content editors really wanted was an easy way to find the relevant piece of content. The creation date seemed like the most obvious way to find it. If you jump to a solution before considering the problem, you can waste it going down blind alleys. I spent a while digging around in the code and the database before I realised sorting the list wouldn't be feasible. By enabling the Chosen module, we made the list searchable - not what the client had asked for, but it gave them what they needed, and provided a more general solution to help with other long select lists. As is so often the case, it was five minutes of development work, once I'd spent hours going down a blind alley.

This is a really good example of why it's so important to validate your assumptions before committing to anything, and why we should value customer collaboration over contract negotiation - for developers and end users to be able to have open conversations is enormously valuable to a smooth relationship, and it enables the team to deliver a more usable system.

Do you really need square pegs?

One area where junior developers sometimes struggle is in gauging the appropriate level of specificity to use in solving a problem. Appropriate specificity is particularly relevant when working with CSS, but also in terms of development work more generally. Should we be building something bespoke to solve this particular problem, or should we be thinking about it as one instance of a more generic problem? As I mentioned earlier, unless your problem is specific to your client's business, somebody has probably already solved it.

With a little careful thought, a problem that originally seemed specific may actually be general. For example, try to avoid building CMS components for one-off pieces of a design. If we make our CMS components more flexible, it makes the system more useful for content editors, and may even mean that the next requirement can be addressed without any extra development effort.

Sometimes there can be a sense that requirements are immutable, handed down from on high, carved into stone tablets. Because a client has asked for something, it becomes a commandment, rather than an item on a wish list. Requirements should always be questioned The further the distance between clients and developers, the harder it can be to ask questions. Distance isn't necessarily geographical - with good remote collaboration, and open lines of communication, developers in different time zones can build a healthy client relationship. Building that relationship enables developers to ask more questions and find out what the client really needs, and it also helps them to be able to push back and say no.

Work with the grain

It can be tempting to imagine that the digital is infinitely malleable; that because we're working with the virtual, anything is possible. When clients ask “can we do X?, I usually answer that it's possible, but the more relevant question is whether it's feasible.

Just as the web has a grain, most technologies have a certain way of working, and it's better to work with your framework rather than against it. Developers, designers and clients should work together to understand what's simple and what's complicated within the constraints. Is the extra complexity worth it, or would it be better to simplify things and deliver value quicker?

Sometimes that can feel like good cop, bad cop, where the designers offer the world, and developers say no. But the point isn't that I don't want to do the work, or that I want to charge clients more money. It's that I would much rather deliver quick wins by using existing solutions, rather than having developers spend time on tasks that don't bring business value, like banging their heads against the wall trying to bend a framework to match a "requirement" that nobody actually needs. It's better for everyone if developers are able to work on more interesting things.

Time is on my side

As an example of an issue where a little technical knowledge went a long way, we were looking at enabling client-side sorting of tables. Sometimes those tables would include dates. We found an appropriate module, and helped to get the Drupal 8 version working, but date formats can be tricky. What is readable to a human in one cultural context isn't necessarily easy for another, or for a computer, so it's useful to add some semantic markup to provide the relevant machine-readable data.

Drupal has pretty good facilities for managing date and time formats, so surely there must be a module already that allows editors to insert dates into body text? Apparently not, so I built CKEditor Datetime.

With some helpful tips from the community on Drupal Slack, I found some CKEditor examples, and then started plumbing it in to Drupal. Once I'd got that side of things sorted, I got some help from the plugin maintainer to get the actual sorting sorted. A really nice example of open source communities in action.

Every picture tells a story

Another challenge that was troubling our client's content team was knowing what their images would look like when they're rendered. Drupal helpfully generates image derivatives at different sizes, but when the different styles have different aspect ratios, it's important to be able to see what an image will look like in different contexts. This is especially important if you're using responsive images, where the same source image might be presented at multiple sizes depending on the size of the browser window.

To help content editors preview the different versions of an image, we built the Image Styles Display module. It alters the media entity page to show a preview of every image style in the site, along with a summary of the effects of that image style. If there are a lot of image styles, that might be overwhelming, and if the aspect ratio is the same as the original, there isn't much value in seeing the preview, so each preview is collapsible, using the summary/details element, and a configuration form controls which styles are expanded by default. A fairly simple idea, and a fairly simple module to build, so I was surprised that it didn't already exist.

I hope that these modules will be useful for you in your projects - please give them a try:

If you have any suggestions for improvement, please let me know using the issue queues.

Tags:  Capgemini Drupal open source development All tags
Categories: Drupal

Capgemini Engineering: There isn't a module for that already?

Planet Drupal - 23 May 2019 - 4:00pm

Sometimes clients ask for the wrong thing. Sometimes developers build the wrong thing, because they didn’t ask the right questions. If you’re solving the wrong problem, it doesn’t matter how elegant your solution is.

One of the most important services that we as developers and consultants can provide is being able to help guide our clients to what they need, rather than simply giving them what they want. Sometimes those two things are aligned, but more often than not, figuring out the right thing to build takes some discovering.

Why don’t wants and needs match? It might be because the client hasn’t spent enough time thinking about the question, or because they haven’t approached it from the right angle. If that’s the case, we can help them to do that, either by asking the right questions or by acting as their rubber duck, providing a sounding board for their ideas. Alternatively, it might be because, as a marketing or content specialist, they lack sufficient awareness of the potential technological solutions to the question, and we can offer that.

Once you’ve properly understood the problem, you can start to look for a solution. In this article, I’ll talk about some examples of problems like this that we’ve recently helped clients to solve, and how those solutions led us to contribute two new Drupal modules.

There must be a module for that

Sometimes the problems are specific to the client, and the solutions need to be bespoke. Other times the problems are more general, and there’s already a solution. One of the great things about open source is that somebody out there has probably faced the same problem before, and if you’re lucky, they’ve shared their solution.

In general, I’d prefer to avoid writing custom code, for the same reasons that we aren’t rolling our own CMS. There are currently over 43,000 contributed modules available for Drupal, some of which solve similar problems, so sometimes the difficult part is deciding which of the alternatives to choose.

Sometimes there isn’t already a solution, or the solution isn’t quite right for your needs. Whenever that’s the case, and the problem is a generic one, we aim to open source the solutions that we build. Sometimes it’s surprising that there isn’t already a module available. Recently on my current project we came across two problems that felt like they should have been solved a long time ago, very generic issues for people editing content for the web - exactly the sort of thing that you’d expect someone in the Drupal community to have already built.

How hard could it be?

One area that sometimes causes friction between clients and vendors is around estimates. Unless you understand the underlying technology, it isn’t always obvious why some things are easy and others are hard.

XKCD -tasks

Even experienced developers sometimes fail to grasp this - here’s a recent example where I did exactly that.

We’re building a site in Drupal 8, making heavy use of the Paragraphs module. When adding a webform to a paragraph field, there’s a select list with all forms on the site, sorted alphabetically. To improve usability for the content editors, the client was asking for the list to be sorted by date, most recently created first. Still thinking in Drupal 6 and 7 mode, I thought it would be easy. Use a view for selection, order the view by date created, job done - probably no more than half an hour’s work. Except that in Drupal 8, webforms are no longer nodes - they’re configuration entities, so there is no creation date to order by. What I’d assumed would be trivial would in fact require major custom development, the cost of which wouldn’t be justified by the business value of the feature. But there’s almost always another way to do things, which won’t be as time-consuming, and while it might not be what the client asked for, it’s often close enough for what they need.

What’s the real requirement?

In the example above, what the content editors really wanted was an easy way to find the relevant piece of content. The creation date seemed like the most obvious way to find it. If you jump to a solution before considering the problem, you can waste it going down blind alleys. I spent a while digging around in the code and the database before I realised sorting the list wouldn’t be feasible. By enabling the Chosen module, we made the list searchable - not what the client had asked for, but it gave them what they needed, and provided a more general solution to help with other long select lists. As is so often the case, it was five minutes of development work, once I’d spent hours going down a blind alley.

This is a really good example of why it’s so important to validate your assumptions before committing to anything, and why we should value customer collaboration over contract negotiation - for developers and end users to be able to have open conversations is enormously valuable to a smooth relationship, and it enables the team to deliver a more usable system.

Do you really need square pegs?

One area where junior developers sometimes struggle is in gauging the appropriate level of specificity to use in solving a problem. Appropriate specificity is particularly relevant when working with CSS, but also in terms of development work more generally. Should we be building something bespoke to solve this particular problem, or should we be thinking about it as one instance of a more generic problem? As I mentioned earlier, unless your problem is specific to your client’s business, somebody has probably already solved it.

With a little careful thought, a problem that originally seemed specific may actually be general. For example, try to avoid building CMS components for one-off pieces of a design. If we make our CMS components more flexible, it makes the system more useful for content editors, and may even mean that the next requirement can be addressed without any extra development effort.

Sometimes there can be a sense that requirements are immutable, handed down from on high, carved into stone tablets. Because a client has asked for something, it becomes a commandment, rather than an item on a wish list. Requirements should always be questioned The further the distance between clients and developers, the harder it can be to ask questions. Distance isn’t necessarily geographical - with good remote collaboration, and open lines of communication, developers in different time zones can build a healthy client relationship. Building that relationship enables developers to ask more questions and find out what the client really needs, and it also helps them to be able to push back and say no.

Work with the grain

It can be tempting to imagine that the digital is infinitely malleable; that because we’re working with the virtual, anything is possible. When clients ask “can we do X?, I usually answer that it’s possible, but the more relevant question is whether it’s feasible.

Just as the web has a grain, most technologies have a certain way of working, and it’s better to work with your framework rather than against it. Developers, designers and clients should work together to understand what’s simple and what’s complicated within the constraints. Is the extra complexity worth it, or would it be better to simplify things and deliver value quicker?

Sometimes that can feel like good cop, bad cop, where the designers offer the world, and developers say no. But the point isn’t that I don’t want to do the work, or that I want to charge clients more money. It’s that I would much rather deliver quick wins by using existing solutions, rather than having developers spend time on tasks that don’t bring business value, like banging their heads against the wall trying to bend a framework to match a “requirement” that nobody actually needs. It’s better for everyone if developers are able to work on more interesting things.

Time is on my side

As an example of an issue where a little technical knowledge went a long way, we were looking at enabling client-side sorting of tables. Sometimes those tables would include dates. We found an appropriate module, and helped to get the Drupal 8 version working, but date formats can be tricky. What is readable to a human in one cultural context isn’t necessarily easy for another, or for a computer, so it’s useful to add some semantic markup to provide the relevant machine-readable data.

Drupal has pretty good facilities for managing date and time formats, so surely there must be a module already that allows editors to insert dates into body text? Apparently not, so I built CKEditor Datetime.

With some helpful tips from the community on Drupal Slack, I found some CKEditor examples, and then started plumbing it in to Drupal. Once I’d got that side of things sorted, I got some help from the plugin maintainer to get the actual sorting sorted. A really nice example of open source communities in action.

Every picture tells a story

Another challenge that was troubling our client’s content team was knowing what their images would look like when they’re rendered. Drupal helpfully generates image derivatives at different sizes, but when the different styles have different aspect ratios, it’s important to be able to see what an image will look like in different contexts. This is especially important if you’re using responsive images, where the same source image might be presented at multiple sizes depending on the size of the browser window.

To help content editors preview the different versions of an image, we built the Image Styles Display module. It alters the media entity page to show a preview of every image style in the site, along with a summary of the effects of that image style. If there are a lot of image styles, that might be overwhelming, and if the aspect ratio is the same as the original, there isn’t much value in seeing the preview, so each preview is collapsible, using the summary/details element, and a configuration form controls which styles are expanded by default. A fairly simple idea, and a fairly simple module to build, so I was surprised that it didn’t already exist.

I hope that these modules will be useful for you in your projects - please give them a try:

If you have any suggestions for improvement, please let me know using the issue queues.

There isn't a module for that already? was originally published by Capgemini at Capgemini Engineering on May 24, 2019.

Categories: Drupal

Telltale Games titles are being delisted from GOG

Social/Online Games - Gamasutra - 23 May 2019 - 2:09pm

PC games storefront GOG has announced that Telltale Games' entire library will be delisted on May 27 as a result of the studio†™s closure last year. ...

Categories: Game Theory & Design

Lullabot: Lullabot Podcast: Layouts Revisited with Tim Plunkett

Planet Drupal - 23 May 2019 - 1:00pm

Mike and Matt invite Layout Initiative lead Tim Plunkett on the podcast to talk everything about Drupal's new Layout Builder, its use-cases, issues, and what's new in Drupal 8.7, and what's coming next!

Categories: Drupal

Acquia delivers during Mueller report traffic surge

Dries Buytaert - 23 May 2019 - 10:41am

Last month, Special Counsel Robert Mueller's long-awaited report on Russian interference in the U.S. election was released on the Justice.gov website.

With the help of Acquia and Drupal, the report was successfully delivered without interruption, despite a 7,000% increase in traffic on its release date, according to the Ottawa Business Journal.

According to Federal Computer Week, by 5pm on the day of the report's release, there had already been 587 million site visits, with 247 million happening within the first hour.

During these types of high-pressure events when the world is watching, no news is good news. Keeping sites like this up and available to the public is an important part of democracy and the freedom of information. I'm proud of Acquia's and Drupal's ability to deliver when it matters most!

Categories: Drupal

Dries Buytaert: Acquia delivers during Mueller report traffic surge

Planet Drupal - 23 May 2019 - 10:41am

Last month, Special Counsel Robert Mueller's long-awaited report on Russian interference in the U.S. election was released on the Justice.gov website.

With the help of Acquia and Drupal, the report was successfully delivered without interruption, despite a 7,000% increase in traffic on its release date, according to the Ottawa Business Journal.

According to Federal Computer Week, by 5pm on the day of the report's release, there had already been 587 million site visits, with 247 million happening within the first hour.

During these types of high-pressure events when the world is watching, no news is good news. Keeping sites like this up and available to the public is an important part of democracy and the freedom of information. I'm proud of Acquia's and Drupal's ability to deliver when it matters most!

Categories: Drupal

Toolbar responsive search

New Drupal Modules - 23 May 2019 - 9:38am

Adds a site-wide search form (for now, relying on the core search module) to the toolbar. At small screens, it's a separate toolbar tab where the search form lives in the toolbar tray. At wider screens, the tab/tray disappear and the search form is directly visible in the toolbar.

Categories: Drupal

Agaric Collective: How Stewarding the Digital Commons Keeps Your Software Secure, Stable and Innovative

Planet Drupal - 23 May 2019 - 8:54am

We live amidst a Digital Commons - technology that is built with the principles of freedom and transparency baked into its code and design. It's maintained out in the open by the free software community. This commons is invisible to many of us, but the closer we are to the technology we use, the more that it comes into focus.We at Agaric are knee deep in this Digital Commons. Our name Agaric is a nod to the mycelial nature of the open web. We help create, maintain, and promote free and open-source software that make up this commons.

Read more and discuss at agaric.coop.

Categories: Drupal

Interactive quantum chemistry in virtual reality

Virtual Reality - Science Daily - 23 May 2019 - 7:49am
Scientists have used virtual reality and artificial intelligence algorithms to learn the details of chemical change.
Categories: Virtual Reality

Welcome to rabbit hell! Reliable AI locomotion with TDD - by Brendan LoBuglio

Gamasutra.com Blogs - 23 May 2019 - 7:14am
Unit testing is often thought to be inapplicable to game development due to randomness, 3D interaction, and unpredictable player input. But in ElemenTerra, we were able to utilize a TDD workflow to write stable and regression-proof AI locomotion.
Categories: Game Theory & Design

What is a game? - by Carl Ji

Gamasutra.com Blogs - 23 May 2019 - 7:11am
This we, I want to think about the definition of a game.
Categories: Game Theory & Design

Elfsight File Embed

New Drupal Modules - 23 May 2019 - 2:12am
Introduction

Elfsight File Embed is the simplest tool to display a file on the pages of your site. It allows you to place any popular format of file: PDF, Docx, Xlsx, Jpeg, and more formats - in a couple of clicks. The documents can be viewed right on the page or in a new tab and downloaded in one click. This widget includes icons for all common formats, colorable details, font size settings, and editable widget header. Embed your licenses, technological documentation, instructions, and other - maximum quickly!

Categories: Drupal

Elfsight PDF Embed

New Drupal Modules - 23 May 2019 - 2:07am
Introduction

Elfsight PDF Embed is the fastest way for you to embed a PDF file on the pages of your website. You can place any amount of PDF files on your site in several clicks. Select to show the files in full view right on your site or to open them in a new tab. Our widget has several stylish variants of a PDF icon, colorable interface elements, text font size settings, and editable widget header. Place your certificates, specialized documents, guides, and more in a few seconds!

Categories: Drupal

Pages

Subscribe to As If Productions aggregator