 Hi, welcome to Powering an Interactive SVG and JavaScript game engine with Drupal. It's a little bit of a mouthful to say. This is meant to be a case study of a project that we worked on that used Drupal to power a game engine that our client was able to use to develop our testing platform for students. I'm Peter Weber. I'm a friend and engineer at Design Group. We're based in Denver, Colorado. On D.I.O. and Twitter, I'm Zerpener. And you can email me at peter at addon.io. I built my first Drupal site in 2008, and it is still out there screaming for security updates right now. My first Drupal account was in 2012, and so it's a real honor for me to be speaking here today. Addon Design Group is a digital strategy, design, and development agency. We're based out of Denver, Colorado. We use Drupal and other open-source technologies. We do user-centered design, agile development, and collaboration to help organizations tell their story and connect with their users. We partner with a lot of amazing clients like Human Rights Watch, the University of Denver, Goobmacher, and many other nonprofits, educational institutions, museums. We try to work with organizations that are doing work that matters. So this case study is about a project we did for the Marsco Institute for Early Learning and Literacy. They're based out of the University of Denver, and they focus on early childhood education. So most of the kids that they teach are three to four years old, and they focus a lot on developing curriculums that help these kids learn concepts like math and counting, recognizing numbers, doing basic arithmetic. So we've done a number of projects for them, and they came to us asking for sort of an assessment platform. So what this would be is an assessment would contain a number of sort of word problems. It meant it should be flexible, reusable, and most importantly, there are hundreds of test items. These test items are actually generated by grad students at DU who are trying to develop little word problems and then create these into an assessment. The idea is that a teacher in the classroom will take an iPad or a laptop and present it to one of these children and then begin an assessment. So remember, too, that since these are three and four year olds, these assessments need to be very visual. A lot of them can't read yet, so the teacher will sit down and walk them through this assessment. They'll choose a student from their classroom and then begin the typo test that they want to do. So this platform is built entirely in Drupal. It keeps track of all the students. It allows the teachers to log in and see just their students and just their classes. Later, there's a reporting feature, so they can go back and look at the data and see how each student is doing on all these different attributes. So in the background it's pretty complex because it's a series of test items, as they're called. And then the path through this assessment is determined by their own proprietary setup. So whether the student gets an answer right or wrong leads them to the next question. Decision tree, they call it. And so each student is meant to get the exercises that they've determined they need to help them do better at a given exercise. So potentially each student's path through this decision tree could be entirely different. So what we need to do in Drupal, we need to take their database, which is all just a set of zeros and ones based on wrong or right answers, that then score them and navigate them to the appropriate test item. So what they provided us was a series of enormous spreadsheets, like hundreds of rows of all these little graphics that their grad students had designed themselves, and then a script that was meant to be read aloud. So it would tell the student what they're seeing, what they should be paying attention to, and then the challenge that they're meant to solve. So out of this spreadsheet, we had to kind of parse through it and figure out what needed to happen. The graphic assets themselves were created by their department, so we didn't have any control over these, which was another challenge. They're required to be interactive as well. And so they would include animations, reveals, highlighting. As the script was read, some parts of these graphics would need to be perhaps highlighted, but not need to be traced to show what they were supposed to be paying attention to. So we needed to find a way to build a system that would allow them to create their own games, to take these graphics that their department produces, and then make them clickable, make them animated. Now, we'd done games before, but we'd done them differently because we built them ourselves. So they would give us a goal for each game and pretty specific criteria. But then we were free to create our own graphics, and we created our own animations and our own interactions, and we had total control over the logic. We used a platform called Phaser, which is a JavaScript library for building games using the canvas. So these games, we had a ton of control over, but we'd learned a few lessons about them. So, for example, the games had things in common, like there would be a similar goal, like you'd have to do some sort of counting, but then the graphics themselves needed to be swapped out. A few lessons about how to separate some of the config from the gameplay and the content and how to easily or more easily replace assets and graphics so that when the game levels changed or when the client came back to us with different feedback, we were able to respond to that and modify them. But again, with this project, we were going to be giving up all of this. We wouldn't have any sort of control over the graphics. We wouldn't have any control of the animations so that we had to figure out a system that would allow them to sort of generate their own games. So some of the games that we'd made did communicate to Drupal already, but they were standalone apps, like they were built in Phaser using Canvas and everything was sort of self-contained. So since we had control over the assets, we were using things that Phaser did, like sprite animations. So like in this concentration game, that card flip animation is actually done with a sprite sheet. And so if you're not familiar with sprite sheets, it's basically just a large graphic that has all the frames of animation in it. And then you only show a small part of it at a time, but you really sort of move the background around. And you can do the same kind of thing with CSS and background position, just moving a graphic in order to quickly sort of cycle through these frames of animation. The catch was, though, that for this game, there's a ton of these different cards. And so for us to create these, it was a bit time-consuming, even though we kind of got used to it when we figured out ways to make it a little bit quicker. It's not the kind of thing you could ask someone to do if they weren't sort of briefed on it. So this type of animation, this kind of sprite animation, was far too precise and too fiddly to ask a grad student who maybe had very basic limited experience of the W Illustrator or something to be able to jump in and create something that was this specific and this repetitive and this consistent. So lessons that we learned from Phaser, we learned to focus on performance. So Phaser, it does pretty well with things, but if you had too many sprites on screen at once, things would sort of bog down and slow down. It's also a little bit monolithic, and so it had a lot of features that we didn't necessarily need for these games. We also did learn, though, that config needed to be separate. So when we make a game, we do a bunch of variations on it. There'd be a bunch of levels of the concentration game or of the counting game or of the math games. And so we learned to keep all those options in sort of separate JSON objects so that they were easy to swap out. If we wanted to do something like change a color, change a hover effect, that was just a matter of changing a single config line. So we learned a few things from this, and mostly it was to make everything configurable, make everything as reusable as possible, and then control that animation as dynamically as possible. So again, in Phaser, we were using things like the sprite animations, which were not dynamic at all. If you wanted to change the pace of it or change the way something happened, it took a lot of rework, especially when you were using that same pattern over and over. So we were actually saved by SVG, and this was something that we fell into almost by accident, because knowing that the client had this requirement of drawing everything in a W Illustrator kind of put us in the mindset of vector art in the first place. So with Illustrator, you're able to export your assets as SVG. I'm not going to go too much into detail about SVG, but just some main advantages are that it's very lightweight. So compared to bigger graphics, PNGs, JPEGs, it's a much smaller file, so it means it loads faster. It's obviously scalable, that's what the S stands for in SVG, and then it's selectable, which is key for us, because an SVG element is like XML, and so it has things you're used to from HTML with IDs and attributes, and that means you can grab things in JavaScript and change their properties much more easily. If you are interested in learning more about SVG animation, I recommend this book by Sarah Drousner. It's excellent, and it just came out a couple weeks ago, I think, in March, and I really wish I would have had this six months ago when I was working on this, because there's a ton of gems in this book that I didn't know about at the time and had to figure out for myself. So our client was using Illustrator, Sketch, it's super nice. I've been using Illustrator for a long time and I feel like the things that I've not liked about it have never gotten better, but Sketch sort of jumps in and handles a lot of things in a way that I appreciate more as a front-end developer. We had to train some other GRAs on some very basic things, but the concept here is super simple, you draw a shape, and as long as you name that layer, I don't know if you can see that, it'll put that ID right in there. And so you can see the SVG is super simple. It's just got the SVG tag, and then because those are rectangles, it's just a rectangle element. They have their position, their dimensions, and then in this case just the fill as attributes, and those things are all adjustable either manually if you open them up in a text editor or with JavaScript if you grab this object with a document and get element by ID. If you are going to use either Illustrator or Sketch for producing your SVGs, I really recommend using SVG-O. This is a node library, and you can just run it from the command line, but there's also a plugin for Sketch and another one for Illustrator. So what this does, if you especially Illustrator, but Sketch as well will add a lot of comments and sort of crux to your code, and you can configure your SVG-O to trim a lot of that out and give you a much cleaner, very succinct little snippet like that. One thing to keep in mind though is if you are optimizing, you're not going to be doing our interactivity. So as far as interactivity goes, we used Green Sock for this project and I'm probably dating myself a little bit to admit this, but I used Green Sock back when it was an action script library, and back then it blew my mind, it was incredible, you could do all these things just with a few lines of action script that would have been a real hassle in the timeline. I'm not going to talk too much about that because it makes me feel super old, but I had forgotten about this and realized that this project's been going on this entire time, and then they completely rewrote it for JavaScript, so it's a very robust, fast, and effective JavaScript library. It's got a ton of tools, there's a free version, the paid version we used for this because we had to do a few extra features like with Bezier paths, but the free version on its own is excellent and you can get a lot done with it. It also does some interactivity, you can do drag and drop, it'll fire off events, and then you can go back into your applications. So back to Drupal, we had already built this site in Drupal, and the idea was that every single one of these test items would be a node. So first of all, I wanted to make sure that we were managing all of our content and all of our configuration in Drupal as well, since all those scores needed to be saved back in there. So we needed a way to upload the assets to define the actual sort of gameplay rules and patterns and interactivity, and then to generate the audio because again, all of these lessons had to be read out loud for the students who hadn't yet learned to read. So being Drupal at Multilingual was super easy, it was very simple for us to just add in node translation and allow any of these tests to be translated into another language, and the advantage here again is like, even if your graphic needs to look different and be sort of culturally adapted, or if you needed to change actual text that was in a certain language in the graphic or anything for whatever reason that needs to be different, those are all separate files, separate uploads. And so creating another language of this node is very simple. For uploading SVGs, we just used a file field. So when you upload an SVG, the way that we set it up is that the SVG itself could be how the game appears, but it could also be used as sort of a sprite sheet. You could create elements and have them hidden by default, so that you could use them later, or you could use the use attribute. We didn't want to get too fancy with the SVG, but we did it by outside people that we didn't have any way to train and we couldn't count on them knowing sort of advanced features. So we tried to make everything very, very simple, like just basic shapes, just IDs, and then everything else needed to be handled by the JavaScript. So we parsed through our requirements and we looked at how that original spreadsheet defined these different levels. So every game or every level needed to have a correct answer, a prompt to use, or a timer, and those are the basics. And so from the Drupal side, we just made a custom form. So each node had the ability to set some of its values by this custom form that you would see when you viewed it. And this was handy for our developers because they were able to go through a test before we actually even built the JavaScript side of it. They could go through a test, that decision tree, and make sure that everything was routing the way they expected it to you, that when they got something correct or incorrect, that those values were being saved and that they were being sent to the next correct and everything was functioning. So then once we came in and finished the JavaScript part of it, this form was hidden and all these values were entered by the student's interaction. Some of the graphics needed to be interactive, so we needed to actually target some shapes and say that these should be draggable, rotatable, very different things. In this case, the only two things we had to worry about were draggable and dragon rotation. So what we did is we created an entity reference on the Tesla node itself, so all this did was just have a text field that you could put in the ID and then a dropdown where we could define the type of interaction. So just by choosing that dropdown and identifying that ID, we could target that shape and make it something that you could click and drag on. And likewise, since this is a multi-value text field, we could just add more options. So if we wanted to make it rotatable, in this case, 30-degree increments, but if later we needed 90-degree increments or we needed to do something else, we could add more options there and then write the code to respond to that. So it made it a little bit more future-proof. Then the last thing, or not the last thing, but one of the important things was the highlight types. So when the lessons are read, it would say something like, which of these squares is bigger or which of these areas is greater. And while it said that, it needed to be able to highlight this square or this square or this distance. So those things needed to be visually identified. There should be sort of a fill change. There should be a way of making a shape appear, making another shape disappear. They had some examples where they would say, look at this for three seconds, and then everything would disappear and you'd say, how many apples were on the screen? So we had to build in these interactions. And again, it was just as simple as creating a drop-down and adding the IDs that you could target each of these shapes for different behavior. The audio was a little bit of a different story. Just like interactions, we used entity references. We also used an entity that had all the fields we needed. In this case, again, we had a text field, which is just a plain old text area. You could type in the words that you wanted the game to speak. And then the audio field was just a file field, but you'd leave that blank. Then, again, you could highlight. So you could choose your drop-down and your type of highlight, whether it was the color overlay, if there was a line that needed to be traced, etc. For the audio, we used the Watson API. This is a super robust platform, and if you're at all interested in it, check it out. Watson was the AI that defeated Ken Jennings at Jeopardy. IBM has made this open to the public. You can just register for an account. It's super cheap. Doing text-to-speech is practically free. It's free for the first million characters, and after that, it's pennies. So what we did is our director of engineering, Joel Stidle, created a small custom module, called Watson API for Drupal. What this lets you do is define a text field, like I showed you in the last slide, and you type in your text, and it looks at the language that you've set, so in this case, English. It grabs the text, and then it fires that off to the Watson API. What it gets back as a response is just a WAV file. And what Joel's Watson API will do is attach that returned WAV file to the audio file field. So now that script entity we've created has the text that you wrote, but then the audio that you need it to be read is generated for you. And again, when we switch this node to Spanish, you just send that language request off to Watson, and it has a Spanish voice that pronounces things more or less correctly. But yeah, definitely check this out. If you get a chance, it's just on our GitHub. It's not an official Drupal module yet. But if you have any need for this, or you just want to check out how text-to-speech works, definitely download this module and give Joel a tweet if you like it, or let us know. So then the last thing was the actual interface for the student. So most of these were just math problems. You know, how many apples are there? How long is this ruler? Things like that. And so they could accomplish that with just a keypad. And we designed sort of a calculator interface so that it was nice and touchable. It worked out for us because we hadn't originally planned to do an iPad app. But once we converted this to be more mobile-friendly, we didn't have to do anything here except tweak some of the responsive styles. For example, if you have a computer, it has a clear button, just like a calculator. And when you submit, all it does is sets the answer value to that number. This works exactly the same way as some of the other things I showed you. So that input method is just a drop-down with just a multi-value text field so you can add other things. Like in this case, we did a multiple-choice answer. This one is a little bit more complicated because you had to have an entity reference. Each one of these answers had to have a name. It has an optional audio file as well. The audio file and actually speak the word. And so we had a few other options. The third one that I didn't have an example for was just being able to click an object in the graphic itself to select it. So the nice thing about doing this in Drupal is that everything is available for the Drupal settings object. So it isn't truly decoupled in that all the data is stored in Drupal and it's sending off to a completely separate front-end. But what it was was more of an enhanced node page. So you take the page that has all of this data on it and you parse through all these entity references and you grab all the information you need. So in this case, this is the multiple-choice answer entity reference that I mentioned just a minute ago. So this is a fairly complicated entity reference but we were able to parse through and grab all the things we cared about which is just that it is a multiple-choice answer of that type. And then of the options we have an ID which is the shape ID which isn't necessary refers to another field where you'd actually type in RG or RO. And then you just type the text that needs to be displayed and then in this case it's a reference to the audio file that would be played when you click on it. And so we used this kind of format this sort of JSON object just like we've done with our own custom games before where everything was just written in JavaScript by putting all these config options into Drupal we were able to export the JavaScript that we needed. So going through the entire game this way we were able to see the SVG file itself which was grabbed and then actually embedded inline onto the page and then the correct answer what the prompt would be and then any sort of shape interaction so the IDs and then whether it's rotatable or draggable etc. So here's just a quick little single item in action what this does is it opens up and you click the start button because with iPads if you don't touch the screen it doesn't autoplay audio so we did this as sort of a way of tricking them into tapping the screen right before they began the game but then it also has the advantage of starting the timer so we know exactly how long they took to solve this problem and if they needed to take a break or go to the bathroom or something they can just set it down and not have to worry about the next exercise running too long. So in this case we used the trace animation so all those paths that the grad students drew with the pen tool and illustrator are converted to Bezier's and then the green sock library will trace the shape along it and then by making one of them clickable you can have the student choose the correct answer. So what was fun about this is that I came back to this project a few months later to do some debugging and some QA and there were hundreds of exercises of all different kinds, things I hadn't even thought about and so it was a super treat to see when things did work and when they needed a little bit more tweaking and seeing this game kind of take on a life of its own was a real treat. So just a quick recap. What we did is we just exposed the config for our game to authors. We built some reusable patterns so they could pick from a list of things that we knew were fairly predictable and then we layered new features on top of existing Drupal structures. So I hope that was helpful. I know there's a lot to cover and it was kind of high level. I'll blog post about more technical sides of this soon but I'm definitely happy to talk to you about it. I'll post these slides up later today. It was pretty complicated. Yeah, it was a fun thing to work with. Look at this. I can see your SPGs were just they weren't modified at all or built for Drupal products. They weren't actually made out of the nodes so they definitely didn't use any elements or something like that. Like it was a map and we had a reservation and if it was going then I'm going to pull the so you use a template to put any different elements to make SPGs so dynamic SPGs based on like why in my world I don't have any reason to do it but it's kind of cool to see somebody that has been doing it for a while. Yeah, you're right. Sorry. Yeah, buddy. Yeah. Yeah. So maybe this is a little bit of a joke. Sorry about that. And then you put the dots and you put the parts to this and it's like, okay, I know that I do red and I swear it's the diagonal and it's mounted in this line and that's what I'm going to add. Yeah, so I'll just put the on the board. Oh, my goodness. I didn't even see you there. I didn't see you there. Then I looked for those and I started looking down and I was like, ummm. Yeah. Okay. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.