Newsfeeds

Group Pathfinding & Movement in RTS Style Games - by Andrew Erridge

Gamasutra.com Blogs - 22 May 2018 - 7:02am
A practical approach to problems making group movement feel good and coordinated in an RTS style game.
Categories: Game Theory & Design

How Hard is Too Hard? - by No Moss Studios

Gamasutra.com Blogs - 22 May 2018 - 7:02am
Reuben from No Moss Studios talks about how the decisions that went into balancing a game that was intentionally trying to be hard. Where is the line between hard and frustrating?
Categories: Game Theory & Design

From Steam to Switch: A Journey of an Indie Game - by Eray Uygun

Gamasutra.com Blogs - 22 May 2018 - 7:02am
Is Nintendo Switch a salvation or a trap for indies? Let's have a closer look.
Categories: Game Theory & Design

CMON Launches Arcadia Quest: Riders Kickstarter

Tabletop Gaming News - 22 May 2018 - 7:00am
The lands surrounding the city of Arcadia have long been home to massive beasts, all living happily in the lush fields and forests. However, as the city has been attacked over and over, the surrounding lands have degenerated. Forced to move, these huge creatures have done just that… right into the middle of town! They’ve […]
Categories: Game Theory & Design

Web Wash: Create Individual Registration Forms using Multiple Registration in Drupal 8

Planet Drupal - 22 May 2018 - 6:30am

If a user needs to create an account on a Drupal site, they go to the user registration page at "/user/register". This page is the registration form on a Drupal site. You can customize it by adding or removing fields. But what if you want to have multiple registration pages?

Let's say you have two different roles on your Drupal site and you need a separate form for each role. How would you build that?

You could handle all of this writing custom code but remember we're using Drupal so means there's a module that can handle this type of functionality and It's called Multiple Registration.

The Multiple Registration module allows you to create individual registration forms base off a user role in Drupal. When you register on one of the forms, you're automatically assigned the configured role.

In this tutorial, you'll learn how to use Multiple Registration to create individual registration forms.

Categories: Drupal

PaizoCon Coming This Weekend

Tabletop Gaming News - 22 May 2018 - 6:00am
You all know how much I look forward to the weekend. It’s my favorite. And, I mean, conventions are awesome, too. So, you team up a convention with a weekend (ok, so most conventions are on the weekend, but you know what I mean), and it’s just a super weekend. That’s what we’ve got this […]
Categories: Game Theory & Design

BFF – A Game About Girl Friendship

Gnome Stew - 22 May 2018 - 6:00am

Terri

I had the pleasure of interviewing Mother and Son team Terri and Ross about their new game BFF. It’s a really interesting game about friendship that is doing some really innovative stuff, and is based off the roleplaying game Fall of Magic.

What’s BFF about?

T: BFF! is about ‘tween friendship.  A great and fun opportunity to try out various personalities and enter landscapes, such as:  a day at Ghost Duck Middle School, a week at Camp Summertime, overnight in Tiffy’s bedroom or a sneak visit to Ms Wei’s garden.  And I guess you could say the game is about adventure.

R: BFF is about friendship, and how our relationships change and grow as we change and

Ross

grow.

Why did you decide to make a game about girl friendship? T: I wanted to create a game to interest ‘tween girls.  What is more important at that age than friendship?  There’s so much intensity around whether they are lasting, true, or disappointing.  They shape us and ultimately are even more influential than our families.  R: It was my mom’s idea! What role did you each play in the design and concept? T: Ross inspired me to even think about designing a game.  Once I got the bug, I drew on my experience as a children’s author and focused on an audience of 10 to 13-year old girls, a group I felt might be underserved in story game world.  I wasn’t inhibited by what was going to make it a good game; that was Ross’s territory.  He is experienced in game theory and how to put it to work. Once Ross was on board, we spent hours deliberating on which of my ideas would actually work, and adding concepts of his own.  We had a good balance and had fun bouncing our ideas off each other. R: I’m a mechanics and publishing guy. Mom is the guardian of the spirit of the game, we both worked together with Tay and Veta to generate the content along with our design consulting team. What’s it like working with your son/mom on a game? T: It’s the BEST.  I’m so lucky we like and respect each other.  We laugh a lot!  The only thing that was tricky was getting used to him calling me, “Terri.”   R: Haha, oh Terri! She also reads my mind which is creepy and useful. We get along really well. And Terri has a ton of knowledge about making media for kids. What are your biggest inspirations for this design? T: Of course, I was a ‘tween girl, and so was my daughter (Ross’s sister.) Those days are forever imprinted on me.  I’m also inspired by Ross’s passion for games and game design.  The importance of children’s stories has been a lifelong focus, from my own childhood, as well as readers of the books I write. R: The design is based on Fall of Magic, the flavor is kind of cartoon-networky / lumberjanes. What do you hope people experience with this game?

T: This game works as well for ‘tween girls as it does for others wanting to reinvent their middle school experience.  There’s opportunity to create characters like you or quite different.  And we’ve provided lots of prompts to allow your own creativity to blossom.  I hope players have fun, surprises, and maybe even experience thought-provoking moments.  

Terri Cohlene grew up in a suburb of Seattle, Washington where she competed with her two brothers in polliwog-hatching, berry-fighting and slug-wrangling. She is the author of nine books for children including, Witch’s Brew~Wicked, Wacky Poems for a Dark, Dark Night.  A former art director and editor of her own imprint, Terri currently serves on the board of Olympia Poetry Network and is a writer, freelance editor, and game designer in Olympia, Washington. You can catch up with her at: www.terricohlene.com.

Ross Cowman is the owner of Heart Of The Deernicorn, a studio and workshop in downtown Olympia. They make beautiful games to inspire creativity, build community, and expand our sense of possibility. Check out their games at www.heartofthedeernicorn.com

BFF! – The rpg of girlhood, friendship, and adventure! ! May 1st-June 1st

 

Categories: Game Theory & Design

GovUK Pay

New Drupal Modules - 22 May 2018 - 2:21am

This Drupal 8 module provides an integration with GOV.UK Pay, a secure payment service that is easy to integrate with and designed to meet the Digital Service Standard. Give your users a trusted GOV.UK-branded payment experience.

Categories: Drupal

The RPGnet Interview: Cognitive Merchant, Game Aids

RPGNet - 22 May 2018 - 12:00am
A maker of gorgeous game items.
Categories: Game Theory & Design

Web Omelette: How to render entity field widgets inside a custom form

Planet Drupal - 21 May 2018 - 11:43pm

In an older article we looked at how to render an entity form programatically using custom form display modes. Fair enough. But did you ever need to combine this form with a few form elements of yours which do not have to be stored with the corresponding entity? In other words, you need to be working in a custom form…

What I used to do in this case was write my own clean form elements in a custom form and on submit, deal with saving them to the entity. This is not a big deal if I am dealing with simple form elements, and of course, only a few of them. If my form is big or complex, using multivalue fields, image uploads and stuff like this, it becomes quite a hassle. And who needs that?

Instead, in our custom form, we can load up and add the field widgets of our entity form. And I know what you are thinking: can we just build an entity form using the EntityFormBuilder service, as we saw in the previous article, and just copy over the form element definitions? Nope. That won’t work. Instead, we need to mimic what it does. So how do we do that?

We start by creating a nice form display in the UI where we can configure all our widgets (the ones we want to show and in the way we want them to show up). If the default form display is good enough, we don’t even need to create this. Then, inside the buildForm() method of our custom form we need to do a few things.

We create an empty entity of the type that concerns us (for example Node) and store that on the form state (for the submission handling that happens later):

$entity = $this->entityTypeManager->getStorage(‘node’)->create([ 'type' => ‘article’ ]); $form_state->set(‘node’, $node);

Next, we load our newly created form display and store that also on the form state:

/** @var \Drupal\Core\Entity\Display\EntityFormDisplayInterface $form_display */ $form_display = $this->entityTypeManager->getStorage('entity_form_display')->load('node.article.custom_form_display'); $form_state->set('form_display', $form_display);

You’ll notice that the form display is actually a configuration entity whose ID is made up of the concatenation of the entity type and bundle it’s used on, and its unique machine name.

Then, we loop over all the components of this form display (essentially the field widgets that we configure in the UI or inside the base field definitions) and build their widgets onto the form:

foreach ($form_display->getComponents() as $name => $component) { $widget = $form_display->getRenderer($name); if (!$widget) { continue; } $items = $entity->get($name); $items->filterEmptyItems(); $form[$name] = $widget->form($items, $form, $form_state); $form[$name]['#access'] = $items->access('edit'); }

This happens by loading the renderer for each widget type and asking it for its respective form elements. And in order for it to do this, it needs an instance of the FieldItemListInterface for that field (which at this stage is empty) in order to set any default values. This we just get from our entity.

And we also check the access on that field to make sure the current user can access it.

Finally, we need to also specify a #parents key on our form definition because that is something the widgets themselves expect. It can stay empty:

$form['#parents'] = [];

Now we can load our form in the browser and all the configured field widgets should show up nicely. And we can add our own complementary elements as we need. Let’s turn to the submit handler to see how we can easily extract the submitted values and populate the entity. It’s actually very simple:

/** @var \Drupal\Core\Entity\Display\EntityFormDisplayInterface $form_display */ $form_display = $form_state->get('form_display'); $entity = $form_state->get('entity'); $extracted = $form_display->extractFormValues($entity, $form, $form_state);

First, we get our hands on the same form display config and the entity object we passed on from the form definition. Then we use the former to “extract” the values that actually belong to the latter, from the form state, into the entity. The $extracted variable simply contains an array of field names which have been submitted and whose values have been added to the entity.

That’s it. We can continue processing our other values and save the entity: basically whatever we want. But we benefited from using the complex field widgets defined on the form display, in our custom form.

Ain't that grand?

Categories: Drupal

Gizra.com: A Simple Decoupled Site with Drupal 8 and Elm

Planet Drupal - 21 May 2018 - 10:00pm

This is going to be a simple exercise to create a decoupled site using Drupal 8 as the backend and an Elm app in the frontend. I pursue two goals with this:

  • Evaluate how easy it will be to use Drupal 8 to create a restful backend.
  • Show a little bit how to set up a simple project with Elm.

We will implement a very simple functionality. On the backend, just a feed of blog posts with no authentication. On the frontend, we will have a list of blog posts and a page to visualize each post.

Our first step will be the backend.

Before we start, you can find all the code I wrote for this post in this GitHub repository.

Drupal 8 Backend

For the backend, we will use Drupal 8 and the JSON API module to create the API that we will use to feed the frontend. The JSON API module follows the JSON API specification and currently can be found in a contrib project. But as has been announced in the last DrupalCon “Dries”-note, the goal is to move it to an experimental module in core in the Drupal 8.6.x release.

But even before that, we need to set up Drupal in a way that is easy to version and to deploy. For that, I have chosen to go with the Drupal Project composer template. This template has become one of the standards for site development with Drupal 8 and it is quite simple to set up. If Composer is already installed, then it is as easy as this:

composer create-project drupal-composer/drupal-project:8.x-dev server --stability dev --no-interaction

This will create a folder called server with our code structure for the backend. Inside this folder, we have now a web folder, where we have to point our webserver. And is also inside this folder where we have to put all of our custom code. For this case, we will try to keep the custom code as minimal as possible. Drupal Project also comes with the two best friends for Drupal 8 development: drush and drupal console. If you don’t know them, Google it to find more out about what they can do.

After installing our site, we need to install our first dependency, the JSON API module. Again, this is quite easy, inside the server folder, we run the next command:

composer require drupal/jsonapi:2.x

This will accomplish two things: it will download the module and it will add it to the composer files. If we are versioning our site on git, we will see that the module does not appear on the repo, as all vendors are excluded using the gitignore provided by default. But we will see that it has been added to the composer files. That is what we have to commit.

With the JSON API module downloaded, we can move back to our site and start with site building.

Configuring Our Backend

Let’s try to keep it as simple as possible. For now, we will use a single content type that we will call blog and it will contain as little configuration as possible. As we will not use Drupal to display the content, we do not have to worry about the display configuration. We will only have the title and the body fields on the content type, as Drupal already holds the creation and author fields.

By default, the JSON API module already generates the endpoints for the Drupal entities and that includes our newly created blog content type. We can check all the available resources: if we access the /jsonapi path, we will see all the endpoints. This path is configurable, but it defaults to jsonapi and we will leave it as is. So, with a clean installation, these are all the endpoints we can see:

JSON API default endpoints

But, for our little experiment, we do not need all those endpoints. I prefer to only expose what is necessary, no more and no less. The JSON API module provides zero configurable options on the UI out of the box, but there is a contrib module that allows us to customize our API. This module is JSON API Extras:

composer require drupal/jsonapi_extras:2.x

JSONAPI Extras offer us a lot of options, from disabling the endpoint to changing the path used to access it, or renaming the exposed fields or even the resource. Quite handy! After some tweaking, I disabled all the unnecessary resources and most of the fields from the blog content type, reducing it just to the few we will use:

JSONAPI blog resource

Feel free to play with the different options. You will see that you are able to leave the API exactly as you need.

Moving Our Configuration to Version Control

If you have experience with Drupal 7, you probably used the Features module to export configuration to code. But one of the biggest improvements of Drupal 8 is the Configuration Management Interface (CMI). This system provides a generic engine to export all configuration to YAML files. But even if this system works great, is still not the most intuitive or easy way to export the config. But using it as a base, there are now several options that expand the functionality of CMI and provide an improved developer experience. The two bigger players on this game are (Config Split)[https://www.drupal.org/project/config_split] and the good old (Features)[https://www.drupal.org/project/features].

Both options are great, but I decided to go with my old friend Features (maybe because I’m used to it’s UI). The first step, is to download the module:

composer require drupal/features:3.x

One of the really cool functionalities that the Drupal 8 version of the Features module brings is that can instantly create an installation profile with all our custom configuration. Just with a few clicks we have exported all the configuration we did in previous steps; but not only that, we have also created an installation profile that will allow us to replicate the site easily. You can read more of Features in the (official documentation on drupal.org)[https://www.drupal.org/docs/8/modules/features/building-a-distribution-with-features-3x].

Now, we have the basic functionality of the backend. There are some things we should still do, such as restricting the access to the backend interface, to prevent login or registration to the site, but we will not cover it in this post. Now we can move to the next step: the Elm frontend.

Sidenote

I used Features in this project to give it a try and play a bit. If you are trying to create a real project, you might want to consider other options. Even the creators of the Features module suggest not to use it for this kind of situations, as you can read here.

The Frontend

As mentioned, we will use Elm to write this app. If you do not know what it is, Elm is a pure functional language that compiles into Javascript and it is used to create reliable webapps.

Installing Elm is easy. You can build it from the source, but the easiest and recommended way is just use npm. So let’s do it:

npm install -g elm

Once we install Elm, we get four different commands:

  • elm-repl: an interactive Elm shell, that allows us to play with the language.
  • elm-reactor: an interactive development tool that automatically compiles our code and serves it on the browser.
  • elm-make: to compile our code and build the app we will upload to the server.
  • elm-package: the package manager to download or publish elm packages.

For this little project, we will mostly use elm-reactor to test our app. We can begin by starting the reactor and accessing it on the browser. Once we do that, we can start coding.

elm-reactor Elm Reactor Our First Elm Program

If you wish to make apple pie from scratch, you must create first the universe. Carl Sagan

We start creating a src folder that will contain all our Elm code and here, we start the reactor with elm reactor. If we go to our browser and access http://localhost:8000, we will see our empty folder. Time to create a Main.elm file in it. This file will be the root of our codebase and everything will grow from here. We can start with the simplest of all the Elm programs:

module Main exposing main import Html exposing (text) main = text "Hello world"

This might seem simple, but when we access the Main.elm file in the reactor, there will be some magic going on. The first thing we will notice, is that we now have a page working. It is simple, but it is an HTML page generated with Elm. But that’s not the only thing that happened. On the background, elm reactor noticed we imported a Html package, created a elm-packages.json file, added it as dependency and downloaded it.

This might be a good moment to do our first commit of our app. We do not want to include the vendor packages from elm, so we create a .gitignore file and add the elm-stuff folder there. Our first commit will include only three things, the Mail.elm file, the .gitignore and the elm-packages.json file.

The Elm Architecture

Elm is a language that follows a strict pattern, it is called (The Elm Architecture)[https://guide.elm-lang.org/architecture/]. We can summarize it in this three simple components:

  • Model, which represents the state of the application.
  • Update, how we update our application.
  • View, how we represent our state.

Given our small app, let’s try to represent our code with this pattern. Right now, our app is static and has no functionality at all, so there are not a lot of things to do. But, for example, we could start moving the text we show on the screen to the model. The view will be the content we have on our main function, and as our page has no functionality, the update will do nothing at this stage.

type alias Model = String model : Model model = "Hello world" view : Model -> Html Msg view model = text model main = view model

Now, for our blog, we need two different pages. The first one will be the listing of blog posts and the second one, a page for the individual post. To simplify, let’s keep the blog entries as just a string for now. Our model will evolve into a list of Posts. In our state, we also need to store which page we are located. Let’s create a variable to store that information and add it to our model:

type alias Model = { posts : List Post , activePage : Page } type alias Post = String type Page = List | Blog model : Model model = { posts = ["First blog", "Second blog"] , activePage = List }

And we need to update or view too:

view Model : Model -> Html Msg view model = div [] [ List.map viewPost model.posts ] viewPost : Post -> Html Msg viewPost post = div [] [ text post ]

We now have the possibility to create multiple pages! We can create our update function that will modify the model based on the different actions we do on the page. Right now, our only action will be navigating the app, so let’s start there:

type Msg = NavigateTo Page

And now, our update will update the activePage of our model, based on this message:

update : Msg -> Model -> (Model, Cmd Msg) update msg model = case msg of NavigateTo page -> ( {model | activePage = page}, Cmd.none )

Our view should be different now depending on the active page we are viewing:

view : Model -> Html Msg view model = case model.activePage of BlogList -> viewBlogList model.posts Blog -> div [] [ text "This is a single blog post" ] viewBlogList : List Post -> Html Msg viewBlogList posts = div [] [ List.map viewPost model.posts ]

Next, let’s wire the update with the rest of the code. First, we fire the message to change the page to the views:

viewPost post = div [ onClick <| NavigateTo Blog ] [ text post ]

And as a last step, we replace the main function with a more complex function from the Html package (but still a beginner program):

main : Program Never Model Msg main = beginnerProgram { model = model , view = view , update = update }

But we still have not properly represented the single blogs on their individual pages. We will have to update our model once again along with our definition of Page:

type alias Model = { posts : Dict PostId Post , activePage : Page } type alias PostId = Int type Page = List | Blog PostId model : Model model = { posts = Dict.fromList [(1, "First blog"), (2, "Second blog")] , activePage = List }

And with some minor changes, we have the views working again:

view : Model -> Html Msg view model = case model.activePage of BlogList -> viewBlogList model.posts Blog postId -> div [ onClick <| NavigateTo BlogList ] [ text "This is a single blog post" ] viewBlogList : Dict PostId Post -> Html Msg viewBlogList posts = div [] (Dict.map viewPost model.posts |> Dict.values) viewPost : PostId -> Post -> Html Msg viewPost postId post = div [ onClick <| NavigateTo <| Blog postId ] [ text post ]

We do not see yet any change on our site, but we are ready to replace the placeholder text of the individual pages with the content from the real Post. And here comes one of the cool functionalities of Elm, and one of the reasons of why Elm has no Runtime exceptions. We have a postId and we can get the Post from the list of posts we have on our model. But, when getting an item from a Dict, we always risk the possibility of trying to get an non-existing item. If we call a function over this non-existing item, it usually causes errors, like the infamous undefined is not a function. On Elm, if a function has a chance of return the value or not, it returns a special variable type called Maybe.

view : Model -> Html Msg view model = case model.activePage of BlogList -> viewBlogList model.posts Blog postId -> let -- This is our Maybe variable. It could be annotated as `Maybe Post` or a full definition as: -- type Maybe a -- = Just a -- | Nothing post = Dict.get postId model.posts in case post of Just aPost -> div [ onClick <| NavigateTo BlogList ] [ text aPost ] Nothing -> div [ onClick <| NavigateTo BlogList ] [ text "Blog post not found" ] Loading the Data from the Backend

We have all the functionality ready, but we have to do something else before loading the data from the backend. We have to update our Post definition to match the structure of the backend. On the Drupal side, we left a simple blog data structure:

  • ID
  • Title
  • Body
  • Creation date

Let’s update the Post, replacing it with a record to contain those fields. After the change, the compiler will tell us where else we need to adapt our code. For now, we will not care about dates and we will just take the created field as a string.

type alias Post = { id : PostId , title : String , body : String , created : String } model : Model model = { posts = Dict.fromList [ ( 1, firstPost ), ( 2, secondPost ) ] , activePage = BlogList } firstPost : Post firstPost = { id = 1 , title = "First blog" , body = "This is the body of the first blog post" , created = "2018-04-18 19:00" }

Then, the compiler shows us where we have to change the code to make it work again:

Elm compiler helps us find the errors -- In the view function: case post of Just aPost -> div [] [ h2 [] [ text aPost.title ] , div [] [ text aPost.created ] , div [] [ text aPost.body ] , a [ onClick <| NavigateTo BlogList ] [ text "Go back" ] ] -- And improve a bit the `viewPost`, becoming `viewPostTeaser`: viewBlogList : Dict PostId Post -> Html Msg viewBlogList posts = div [] (Dict.map viewPostTeaser model.posts |> Dict.values) viewPostTeaser : PostId -> Post -> Html Msg viewPostTeaser postId post = div [ onClick <| NavigateTo <| Blog postId ] [ text post.title ]

As our data structure now reflects the data model we have on the backend, we are ready to import the information from the web service. For that, Elm offers us a system called Decoders. We will also add a contrib package to simplify our decoders:

elm package install NoRedInk/elm-decode-pipeline

And now, we add our Decoder:

postListDecoder : Decoder PostList postListDecoder = dict postDecoder postDecoder : Decoder Post postDecoder = decode Post |> required "id" string |> required "title" string |> required "body" string |> required "created" string

As now our data will come from a request, we need to update again our Model to represent the different states a request can have:

type alias Model = { posts : WebData PostList , activePage : Page } type WebData data = NotAsked | Loading | Error | Success data

In this way, the Elm language will protect us, as we always have to consider all the different cases that the data request can fail. We have to update now our view to work based on this new state:

view : Model -> Html Msg view model = case model.posts of NotAsked -> div [] [ text "Loading..." ] Loading -> div [] [ text "Loading..." ] Success posts -> case model.activePage of BlogList -> viewBlogList posts Blog postId -> let post = Dict.get postId posts in case post of Just aPost -> div [] [ h2 [] [ text aPost.title ] , div [] [ text aPost.created ] , div [] [ text aPost.body ] , a [ onClick <| NavigateTo BlogList ] [ text "Go back" ] ] Nothing -> div [ onClick <| NavigateTo BlogList ] [ text "Blog post not found" ] Error -> div [] [ text "Error loading the data" ]

We are ready to decode the data, the only thing left is to do the request. Most of the requests done on a site are when clicking a link (usually a GET) or when submitting a form (POST / GET), then, when using AJAX, we do requests in the background to fetch data that was not needed when the page was first loaded, but is needed afterwards. In our case, we want to fetch the data at the very beginning as soon as the page is loaded. We can do that with a command or as it appears in the code, a Cmd:

fetchPosts : Cmd Msg fetchPosts = let url = "http://drelm.local/jsonapi/blog" in Http.send FetchPosts (Http.get url postListDecoder)

But we have to use a new program function to pass the initial commands:

main : Program Never Model Msg main = program { init = init , view = view , update = update , subscriptions = subscriptions }

Let’s forget about the subscriptions, as we are not using them:

subscriptions : Model -> Sub Msg subscriptions model = Sub.none

Now, we just need to update our initial data; our init variable:

model : Model model = { posts = NotAsked , activePage = BlogList } init : ( Model, Cmd Msg ) init = ( model , fetchPosts )

And this is it! When the page is loaded, the program will use the command we defined to fetch all our blog posts! Check it out in the screencast:

Screencast of our sample app

If at some point, that request is too heavy, we could change it to just fetch titles plus summaries or just a small amount of posts. We could add another fetch when we scroll down or we can fetch the full posts when we invoke the update function. Did you notice that the signature of the update ends with ( Model, Cmd Msg )? That means we can put commands there to fetch data instead of just Cmd.none. For example:

update : Msg -> Model -> ( Model, Cmd Msg ) update msg model = case msg of NavigateTo page -> let command = case page of Blog postId -> fetchPost postId BlogList -> Cmd.none ( { model | activePage = page }, command )

But let’s leave all of this implementation for a different occasion.

And that’s all for now. I might have missed something, as the frontend part grew a bit more than I expected, but check the repository as the code there has been tested and is working fine. If yuo have any question, feel free to add a comment and I will try to reply as soon as I can!

End Notes

I did not dwell too much on the syntax of elm, as there is already plenty of documentation on the official page. The goal of this post is to understand how a simple app is created from the very start and see a simple example of the Elm Architecture.

If you try to follow this tutorial step by step, you will may find an issue when trying to fetch the data from the backend while using elm-reactor. I had that issue too and it is a browser defense against (Cross-site request forgery)[https://es.wikipedia.org/wiki/Cross-site_request_forgery]. If you check the repo, you will see that I replaced the default function for get requests Http.get with a custom function to prevent this.

I also didn’t add any CSS styling because the post would be too long, but you can find plenty of information on that elsewhere.

Continue reading…

Categories: Drupal

Mark Shropshire: CharDUG Presents Drupal 8 Training Series

Planet Drupal - 21 May 2018 - 8:09pm

During the past few CharDUG (Charlotte Drupal User Group) meetings, I realized that we have a real need to help our existing Charlotte area Drupalers using Drupal 7 to move on to Drupal 8. There is also a huge opportunity to train those completely new to web development and Drupall. Out of some recent conversations, I have put together a training series that will span the next 6 months and become the focus for each of our monthly meetings on the 2nd Wednesday of each month.

The CharDUG Drupal 8 Training Series is a comprehensive set of training workshops to get attendees up to speed with all aspects of Drupal 8. Whether you are brand new to Drupal, focused on content management, a frontend or backend developer, or devops engineer, this series contains what you will need to utilize Drupal 8 to its potential. Attendees should bring friends, laptops, and questions. There is no need to attend all sessions, though recommended for those new to Drupal. An outline of what to expect is provided below. If you have questions or suggestions, don’t hesitate to reach out on meetup.com or @chardug.

Drupal 8: Installation and Features
  • June 2018
    • What is Drupal?
      • Community
      • Open Source
      • Contributing to Drupal
    • How to install Drupal 8
    • Important features of note
    • Changes since Drupal 7
    • Drupal release schedule
Drupal 8: Site Building
  • Julu 2018
    • Installing Drupal 8
    • Using Composer with Drupal
    • How to build a site without any development
      • Installing modules and themes
    • Top Drupal 8 contributed modules
    • Users, roles, and permissions
    • Configuring Drupal
Drupal 8: Managing Content
  • August 2018
    • Content management concepts
      • Content types
      • Content authoring experience
      • Content moderations
      • Permissions and roles
      • Content scheduling
    • Creating and editing content
    • Blocks
    • Layout Builder
    • Paragraphs
Drupal 8: Layout and Theming
  • September 2018
    • Layout options
    • Responsive design
    • Images and media
    • Developing a Drupal theme
    • Drupal and responsive layouts
    • Decoupled Drupal frontends
Drupal 8: Module Development
  • October 2018
    • Developing a module
      • Menus and routes
      • Permissions
      • Creating pages and admin forms
      • Event subscribers
    • Writing and running tests
Drupal 8: Deployment and Next Steps
  • November 2018
    • Deploying to production
      • Development workflows
      • Security
        • Guardr
      • SEO
    • Next steps for Drupal
      • Drupal 9
      • New initiatives
      • Decoupled Drupal
Blog Category: 
Categories: Drupal

Wyrd Posts Monday Preview

Tabletop Gaming News - 21 May 2018 - 3:00pm
One of the things that makes Mondays better is that Wyrd’s consistent with posting new previews… even if they don’t tell us what it is they’re showing us. This week, we’ve got another of those Mystery Monday previews. From the post: Happy Monday! We continue with a look at some mysterious upcoming projects. Head over […]
Categories: Game Theory & Design

Thief&#8217;s Hoard Card Game Up On Kickstarter

Tabletop Gaming News - 21 May 2018 - 2:00pm
There’s money to be made in thievery. However, those that pick pockets might also have their own pockets picked. In Thief’s Hoard, the goal is to create a horde worth $10,000. But you’re not the only thief on the block, and what you steal might not remain yours forever. The card game is up on […]
Categories: Game Theory & Design

Loopit

New Drupal Modules - 21 May 2018 - 1:38pm
Introduction
  • Unified and centralised helper to recursively traverse an aggregate. Have a nested array of the traversal output as a transformation of the root level aggregate.
  • Each aggregate is responsible how it exposes his elements. There are traversal events that are fired from the recursive aggregate iterator trait (for use in the extended SPL recursive iterators).
  • Filter to match for « array parents » based subset with wild card capability like « starts with », « ends with », « contains » and « all »
  • Implementation for « object to array » transformation with unlimited depth. Sub module for display it that uses the Krumo library and has a copy of the javascript code from the Drupal 7 Search Krumo module.
Categories: Drupal

Crusader Kings Board Game Up On Kickstarter

Tabletop Gaming News - 21 May 2018 - 1:00pm
While nowadays, it seems like everything is moving from the analog world to the digital, there’s still items headed the other direction. For example, take Crusader Kings. This computer strategy game is now coming to your gaming tabletops as Crusader Kings The Board Game. Free League Publishing and Paradox Interactive have teamed up to bring […]
Categories: Game Theory & Design

Corvus Belli Previews Infinity&#8217;s June Releases

Tabletop Gaming News - 21 May 2018 - 12:00pm
We’re about a week and a half away from June. Hard to believe the months are flying by so fast. Soon, it’ll be summer (for us in the Northern Hemisphere, anyway). Sun, heat, beaches, all that stuff. It’ll also be a new set of releases for Infinity. Check out the preview by Corvus Belli. Source
Categories: Game Theory & Design

Soft machines: Fast, low-voltage actuator for soft and wearable robotics

Virtual Reality - Science Daily - 21 May 2018 - 11:38am
In the world of robotics, soft robots are the new kids on the block. The unique capabilities of these automata are to bend, deform, stretch, twist or squeeze in all the ways that conventional rigid robots cannot. Today, it is easy to envision a world in which humans and robots collaborate -- in close proximity -- in many realms. Emerging soft robots may help to ensure that this can be done safely, and in a way that syncs to human environments or even interfaces with humans themselves.
Categories: Virtual Reality

Monday Terrain Corner

Tabletop Gaming News - 21 May 2018 - 11:00am
It’s Monday. We all knew it was going to happen. Not that we had to like it, of course. That’s not to say I’m mad about it being the start of the work week, but when you’ve had a great weekend, it’s always a bit of an, “… aw” to wake up Monday morning with […]
Categories: Game Theory & Design

Epic Games puts up $100M for Fortnite esports prize pool

Social/Online Games - Gamasutra - 21 May 2018 - 10:14am

The studio shared the brief announcement on its company blog, noting that it is looking to get "behind competitive play in a big way" for the game's inaugural 2018-2019 season. ...

Categories: Game Theory & Design

Pages

Subscribe to As If Productions aggregator