Part 1 of a series on creating a basic platformer in Phaser (http://phaser.io/). In this video, I cover creating a Phaser.Game object, enabling the Arcade physics system on a sprite, and moving that sprite using its velocity.x and velocity.y.
Phaser: http://phaser.io/
Source Code: http://bit.ly/phaserFriday15_01
[Yesterday, I was part of a workshop organized around the ideas of ‘insistent design’ (Ruggill & McAllister 2011) and R.A.F.T. (Bean, 97 – 100) to help instructors craft assignments and engage students in their classes. As part of the workshop, two person teams ran micro-sessions designed around showing certain games and helping to highlight how their mechanics could be used later as part of applying the themes of games-based learning to their classrooms and syllabi. I was part of the group presenting Proteus; others showed Diablo 3, Plants Vs Zombies, and Portal.]
Background
As part of their essay on “Aimlessness” in Gaming Matters: Art, Science, Magic and the Computer Game Medium, Ruggill and McAllister state that “computer game designers deploy an array of techniques that insist players forget about the tedious medium they are engaged with and perceive it as quite the opposite: as addictive, thrilling, and fun” (40). Since computer games are often composed of a series of monotonous actions, they write, their designers compose ways of ‘insisting’ various information to players. Using the design insistences of “‘go here’ and ‘do this'” (41), for example, games direct players to take on missions, quests, and other impositions that are the “price of admission for playing” (42). Because computer games encode these themes so frequently, most players internalize the structures and look for the objectives of a particular session to be presented in such a way; they look for the game to tell them what to do next.
Using this as a basis, we paired it with what Bean presents in Engaging Ideas: The Professor’s Guide to Integrating Writing, Critical Thinking, and Active Learning in the Classroom on the best design practices of designing assignments: the acronyms of R.A.F.T. and T.I.P. These acronyms, presents Bean, arose out of a response to trying to create “meaning-constructing tasks” as part of a section on the best practices for designing assignments. These are tasks that serve to “bring . . . critical thinking to bear on problems that matter to both the writer and the intended audience” (97). The acronyms of R.A.F.T. and T.I.P. are a way to present problems to students along with mnemonics to guide them in solving them in the process.
Role (or purpose)
Audience
Format (or genre)
Task
Task as
Intriguing
Problem
At the start of the workshop, we divided the participants into four groups based around the themes of play we were presenting in each game and how they intersected with Ruggill and McAllister’s ‘insistent design’: Builders, Explorers, Collectors, and Detectives. Rotating each group through roughly 10 minute sessions with each game, they were to look at how each game did (or did not) match up to their theme by writing things down on a worksheets given to each group. At the end, once they had experienced or at least seen someone else play each game, we set aside time to reflect on each and then apply them to a scenario created by each group of how to change the R.A.F.T. to shift the perceived context of an assignment.
Playing Proteus
I didn’t suggest Proteus. I know that seems odd to read for those who know me and my love of that game, but I wasn’t the one who initially thought to add it. It became part of a number of suggested indie games we might let people play (among them Brothers – A Tale of Two Sons and Thomas Was Alone as well) and it just happened to win out. Something, of course, I was happy about, but about which I didn’t necessarily direct myself.
One of the main reasons I didn’t suggest it at first, and is maybe obvious from the inclusion of the phase ‘insistent design’ several times so far in this post, is that it doesn’t do that. If Proteus is definitively something, it’s that it isn’t insistent about anything. You can, and many people have, never progressed to another season in the game or ever seen any other plant or animal life but those present at first. Since Proteus doesn’t ‘insist’ you progress, or ever do anything at all really, many people are confused about their objectives in the game. They are used to games being explicit in their instructions, but Proteus purposely does very little to point the player in any direction or suggest a course of action.
That was the most common question, too: “What do I do?” It was followed in a close second by “Where do I go?” The other three games explicitly told people what to do next. They should go search some area. Attack these enemies. All matching up to the design insistences of “‘go here’ and ‘do this’.” All things, if you know Proteus, it doesn’t do at all.
This became an interesting teaching moment for many of the participants too. Since a player of Proteus isn’t being yelled at, attacked by zombies, or at the risk of having their lawn invaded, they got to take in the game at its own pace. And since people showing up to the workshop were generally teachers, instructors, or staff in some capacity or another, they also got a chance to learn (hopefully) that not all games are about violence and conflict by being shown Proteus. (There was a very nice moment for me personally where one participant actually said those words to me, “Oh. Not all games are violent in some way.”)
However, since Proteus isn’t explicit in its conflict, both in the literal and metaphorical sense, we also had to explain what was going on and that, yes, one of the aspects to the game is in producing your own ‘language’ for the objects within its world. Since it doesn’t tell you about things, you end up, as every group did, in fact, deciding upon your own labels for things on the island and what they are doing. The lower resolution of game assets forces people, in the same way the lack of text does, to constantly deconstruct what they are viewing and interacting with in the process of building their own narrative of the experience. Much of the player’s experience is in discovery this island’s world and exploring various interactions and their effects.
Reflecting and Applying
While my opinion of Proteus‘ usefulness for this workshop changed once I started to talk with groups and had to instruct them in how to play, it still didn’t work as well during the reflection part of the workshop at the end. Since the player is given so very little information about their avatar, it becomes hard to make out what exactly the ‘role’ of the player is. And since the audience for the game is, to some degree, those already familiar with its controls and systems (Proteus is very much a response to its contemporaries and corollaries in the FPS genre), it doesn’t work as a great example of making explicit demands and ‘insisting’ players do certain things.
However, since the workshop was about games-based learning (or, if you prefer, “gameful design”) in general, most of the reflections of the group I ended up working with were connected to creating ways to integrate assignment scaffolding into their preexisting processes. Using the ideas they had seen, they were able to make up a more fantastical version of investigating a system and assigning different people missions as part of a larger quest into the body to check for illness. Each ‘station’ would have a task and the information would be shared and reported back to a ‘mission control’ person. By pretending their were really inside a body, they could imagine what synonyms might look like up close and try to diagnose things from the inside out.
As a round-up of what we presented through the different games they saw or played, we tried not to use the games themselves as what participants should take away from the workshop, but more the themes they presented and how the mechanics of ‘insistent design’ could be leveraged to change what are sometimes often potentially boring tasks of researching or cataloging information as part of an assignment. Even the writing of different papers and reports are not necessarily the exciting parts. It’s the discovery of new ideas and connections and then the sharing of those discoveries, often not the containers of the information themselves. By using games-based learning techniques, it was hoped instructors help create assignments that would benefit the student and help them to see material from a different perspective.
Bean, J. (2011). Engaging ideas : the professor’s guide to integrating writing, critical thinking, and active learning in the classroom. San Francisco: Jossey-Bass.
Ruggill, J.E., & McAllister, K.S. (2011) “Aimlessness” in Gaming Matters: Art, Science, Magic and the Computer Game Medium, Tuscaloosa: University of Alabama Press. pp. 32-49
You may have seen on Twitter and Google+ last night that I have officially published my first game of 2014! It’s one of many I hope to publish on itch.io and expand out to the Android and even Ouya marketplaces this year. It’s also the start of a new commitment to helping others with their games through code examples and game assets too. But more on that a little later in the post.
Slow Progress
I began the project with two goals:
Starting in early February, I created various prototypes and even envisioned releasing it on the Ouya first. Unfortunately, as I’ve detailed in posts dating over a month ago, that failed in many ways. I ended up spending weeks patching Phaser, Pixi.js, and recording issues for others. In fact, releasing it on Ouya was the plan up until learning CocoonJS doesn’t support IAP on the Ouya anyway and, oh yeah, images are often broken with CocoonJS as of Phaser 2.0 (!).
Having spent many days in e-mail communication with several different people about the image issue starting about two weeks ago, I finally gave up late last week. I couldn’t sell on the Ouya until the promised ‘choice‘ materialized. And I was tired of politicking for patches that might not even be needed once CocoonJS updates anyway. It was time I scaled back and tried to actually put something out.
And that’s what Pale became. It was an execution of my goals in a smaller, compact way.
Weeks worth of effort went into trying to create platformer physics that ‘felt okay’ and could be believable in a black and white setting. Many, many days were spent trying out different patterns of the two colors and in a configuration that wouldn’t make me dizzy trying to play it. (This was, believe it or not, a serious concern. One of the early builds that had flashing parts gave me a headache after playtesting it several times.)
I even spent a couple days just trying to get the elevator working the way I want. Something, it turns out, that is non-trivial using Phaser’s ‘Arcade’ physics and tweening system at the same time.
Commitment
Throughout this whole journey, I have had a whiteboard next to my desk. It keep track of various upcoming events and my personal TODO lists. It has things, looking at it now, that include ‘Work on The Lost Bits’, ‘Finish the Flash RPG guide’, and ‘Make Phaser autorunner guide.’ It also has, in the upper right-hand corner, a note I wrote to myself months ago to ‘Release game art on OGA.’ It’s something, since I haven’t publicly released a game in months, I haven’t been able to act on much. That is, until now.
Within minutes of Pale going live, I posted the tiles I made on Open Game Art too. Like my GameBoy-styled art from months ago, it is CC-BY 3.0 licensed. You are free to use or remix them, just give me credit somewhere.
And I also plan to put out an updated version of “Create a basic platformer game in Phaser using NetBeans and Tiled” at some point soon too. The internal APIs of Phaser have changed quite a great deal even in the last few months and that, for all of its screenshots, is out of date when it comes to the code itself. Now that I’ve had time with the ‘arcade’ physics system Phaser uses, I have a much great feel for gravity and velocity values for a platformer I hope to incorporate.
Ever since Gianfranco Berardi started blogging again a few posts ago, I have been in general agreement with what was written about each time. We’ve had a back-and-forth on a few things covering narrative and stories in games in the comments, and I was even a part of the on-going conversations about backlogs and sales of game collections. All general, of-the-moment dialogues about important concerns within the greater games community and industry.
Of course, we each come at topics from different angles. I have a decade of academia behind me and, what with being a graduate student, I tend to think of things in terms of students and teaching. I’ve personally spent a great deal of time trying to bridge the humanities with the sciences. To me, then, declaring something not creative is paramount to dismissing its importance. Creativity is at the root of our humanity. It is what allows us to pierce the wonderful and concoct the seemingly bizarre from our individual weird.
The Necessity of Failure
If there is one thing I can impart to my own students, it is this: you will fail. When you first try to take on some new topic, be it writing or even coding, you will fail. However, just because something doesn’t work the first time doesn’t mean to give up. We all fall down the first time. It’s the next step, trying again and revising, that matters most. Writing is, to paraphrase a quote, 99% revising after all. It’s the same with coding. They are, in my mind, the same.
So, to question if coding can be creative is, to me, the same as question if writing can be creative. Of course programming is creative! All language writing is the act of creation. To record thoughts and set down logic to a madness of symbols is to mold them, to construct some sense into them. That code is then parsed, compiled, or read does not change this. It is, at its base, all encoded language. It is all creativity.
The Difference between Using and Mastering
However, what Gianfranco is getting at, I feel, is not that creativity doesn’t have a place in programming, but more that code is frequently graded on efficiency and simplicity. Often, in workplace settings, elegance is not as important as code that follows the standards or protocols in place. There are set goals that influence behavior and restrict the urge to deviant too far from them. We might, to put on my teacher hat on for a moment, call this a normalizing pattern. The incentive to write “creative” code is highly reduced.
To write code that solves a more generalized problem isn’t as important as the problem in front of you at any one time. Much of the work done in what is considered a professional setting is solving problems one after another. It is about knowing your tools and applying them in what Gianfranco labels, quoting someone else, “engineering, not creativity.” Knowing how long it might take to solve the problem, what is involved, and what tools to apply is more important than writing beautiful code. The goal is functionality, not perfectly constructed code. It’s the speed–accuracy trade-off, or, put another way in some circles, “worse is better.”
There is a worry that comes from this too. As people become accustomed to certain knowledge domains, they specialize. With this often comes a loss in other areas. It’s a form of min-maxing. By becoming very good at solving certain problems, people sometimes forget other domains or lose interest in them. The creativity that manifests in being really good at “engineering” is seen as years of experience, as it is in part, but it is also a specialization too. All investment comes at a cost.
Experimentation before Solutions
I think creativity in code is just another way of saying, “I’m guessing that this might work. Let’s see what happens.” It’s like throwing things into a fire and observing the results. It’s not creativity so much as experimentation.
When I learned about design patterns, entire concepts were made clearer to me, and my programming capability improved. I didn’t have to be as creative to write code to solve a problem or accomplish a task. If I’m ever trying to be creative while writing code, I think it says more about my lack of knowledge in the area than with the nature of programming.
I feel as if the sentiment behind this is of lazy coding. Instead of coming up with a solution, carefully testing it, revising as needed, and then finally releasing it, we all risk this. It’s the same, to compare this to writing again, of trying to put something together the night before it is due. This can sometimes force creativity through the application of stress, but it isn’t the best way. It never is. Throwing ideas together, be it in code or writing, isn’t solving the problem, it is hoping no one will see through your hastily thrown together illusion of work.
Revision in writing, as well as in programming, is the key. Creativity drives this process. However, its purpose is experimentation itself. Trying, failing, and trying again.
It is very rare to hit upon a solution on the first try and even rarer still for it to occur a second or more time. Creating and testing writing or code is the process itself. Thinking up something that might work, seeing if it does, and then running it through all the normal tests is the normal procedural. This is creativity. This is experimentation.
This is also learning. We fail. We try again. Maybe we fail again. But we keep going, applying the lessons of our failure to better ourselves through each iteration.
[Previously, I covered how to draw many of the things I’m going to combine together in this post. Things like bricks, doors, floors, ground, and plant tiles.]
When I first started making games a couple of years ago, I didn’t know about many of the tools I use now. Instead of relying on integrated development environments and game libraries, I was trying to do everything through basic text editors and creating maps using Excel. As you might imagine, anything but the simplest of mechanics quickly grows out of the scope. It is just too complicated and time-consuming to make games that way.
That’s why there are tools like Tiled to help with specific tasks. In this case, making maps quickly from spritesheets.
(Definition: A spritesheet is a portmanteau of “sprite” and “sheet”. It’s a set of images — sprites — collected under a theme or for the purpose of quickly loading resources. Usually, individual images are referenced either by index, where they are positioned relative to the other images around them, or by the specific position within a coordinate system of the larger spritesheet itself like its x and y from the upper- or bottom-left corners.
Tiled uses the nomenclature of tiles, sprites created for the purpose of being drawn with others to create a larger image by arranging them in patterns. A tileset, then, is just a spritesheet of tiles for the use of making a map or other composite image object.)
Within Tiled, there are two main categories: tilesets and layers. For a single map, there can be multiple of either, so they are further subdivided into each named tileset and different layers describing what exists within them. Depending on usage, there can be Tile Layers, Object Layers, or even Image Layers.
For this example, I’m going to use the following four tilesets:
To start, install Tiled for your operating system. It works on Windows, Mac OS X, and even most popular Linux distributions. (Once ready, make sure you have download the example tilesets too.)
To make a new map, it’s as simple as clicking on the first icon on the menu or going to File->New.
Once you do that, you will be presented with options of what type of map orientation, layer format, and what map or default tile size to use.
For this example, we will be using “Orthogonal” Orientation and the Layer Format of “Base64 (zlib compressed)”.
(The orientation of orthogonal means that the viewing angle of the user to the map is either a right angle or close to it. In other words, we are “looking down” at a flat map from straight above it.)
(Layer format is how the data of the map itself will be saved. Since maps can be very big and potentially have hundreds if not thousands of individual tiles, this data can be compressed and then encoded to save space when output to a file.)
And since each tile within our tilesets are 16 x 16, we do not need to change the tile size options.
However, a 32 x 32 map size is rather large to start with, so we will reduce that down to a smaller 16 x 16 size.
Clicking “OK” will then produce an empty 16 x 16 map.
It will also create for us a new Tile Layer called, naturally, “Tile Layer 1”.
To add a new tileset to this layer, we need to go to Map->New Tileset…
From here, we can name this new tileset, pick the spritesheet (Image) we want to use, and change different drawing options such as its margins and offsets.
For now, we will only click on “Browse” and select the “groundTiles.png” file downloaded eariler.
This will create a name based on the file’s name and list the path to the file in the Image field.
Clicking “OK” will add this tileset to our collection.
Before we start to draw with these tiles, however, I recommend zooming in on both this individual tileset and the overall map using the drop-down menu in the lower right-hand corner. (For my screen resolution, moving from 100% to 300% works best.)
Tiled gives us several different ways to draw tiles. We can Stamp Brush, Terrain Brush, Bucket Fill, or Eraser.
To begin to draw this map, we will use the Bucket Fill Tool.
Selecting the middle (grass) tile from the first tileset and the bringing the cursor over the map will show a preview of what will be drawn. To commit the change, we need only click once.
With the map now filled with the grass tile, we can begin to draw the edges of our map.
To do that, we can select the Stamp Brush and then the tree tile.
For each click on the map, we can draw a single tree.
And, to add some water tiles, we need only click on that tile and on the map where we want them.
Then, to add another tileset to our collection, we go back to Map->New Tileset… and select another file, allowing the default values to be set.
In fact, we can load the rest of the tilesets now too.
(In order to see all tileset names, you may need to change the size of the layer frame within Tiled. To do that, find the edge between the map and layer frame. The cursor will change from its default to the resize icon. Clicking-and-dragging allows you to change the widths of the frames.)
Now that all the tilesets are loaded, drawing the rest of the map is a matter of selecting each individual tile from each set and, using the Stamp Brush, drawing them in place.
The roof tiles (part of the buildingTiles set) go above the window and door tiles. The left and right sides of the greyBlockTiles go on their respective sides.
If any mistakes happen, or you don’t like the placement of a particular tile, you can use the Eraser tool to, well, erase that tile.
Once we have a map the way we want, it is time to output the file.
By default, Tiled uses its own TMX file format created as a derivative of XML. With its own set of tags attributes, it can be read using any XML parsing library or function. However, whatever options were set during the initial creation of the map (the Layer Format) will be what the internal data of the map data is either compressed in, encoded, or both. In order to retrieve such data, it might need to be decoded or uncompressed using a separate library such as AS3-Tiled-Reader for those projects written in ActionScript 3.
To bypass this issue, or even use a preferred file format, use the File->Save As.. option and pick a format from the file dialog’s drop down menu.
You can even File->Export As… the map information in a few more formats or create your own file extension if needed.
Or even, if you prefer to merely see the map as a single image at the current zoom level and with or without the grid lines, you can File->Save As Image… as I did at the beginning of this post.
Previously:
(I use Paint.Net to make these examples, but two open source programs, GIMP and Pinta, work just as well.)
(I also turn on the pixel grid. In Paint.Net and Pinta, it’s under View->Pixel Grid.)
Personally, I find drawing anything organic to be the most difficult. I’ve gotten decent at drawing science-y tiles like metal floors and even computer consoles, but actually drawing things that grow always takes me extra time to make sure it looks the way I want. I have to play with the colors and often re-draw parts to my liking.
However, the one exception to this is plants.
And the reason for that was something that was right in front of my face when I was young but I was completely blind to at the time. No, it wasn’t until I started studying the art of Super Mario Bros that I noticed the (now) completely obvious fact that the bushes in the background and the clouds in the sky are the same sprites. The only difference is in color. “The plants are the clouds!”
The trick, then, is to realize that if you can draw a cloud, you can also draw a tree or bush too. It’s all a matter of switching colors.
Starting from a new 16 x 16 image, we can fill it with green (#00A800).
Next, in black, we draw the outline of a cloud by drawing straight lines on the first and fourteenth columns seven pixels long starting from the third row. Then, another two lines along the first and eleventh rows eight pixels long. Finally, connecting them with four two-pixel-long lines inside the other four lines.
Now, we are going to draw the trunk of the tree in a dark brown (#503000) starting from the sixth row and twelfth column. It will be a 4 x 4 rectangle.
Admittedly, this looks like a pretty basic, almost childish looking tree.
So, in order to make it more professional, we are going to add some “rough edges” to the tree by adding black pixels to its outline in random places. This way, the tree will look as if its branches grew into a more organic looking pattern.
And then we can add some shadow to the trunk as well by filling its brown sides with black.
By adding white pixels to the upper-left corner of the tree’s inside oval, we can create the visual effect of light bouncing off the tree.
Since the light source for the tree is now somewhere off to the upper-left (to create the reflection off the leaves of the tree), we now need to add more shadow to the truck bottom-right of the tree.
To do that, we simply add extra black pixels to the trunk (two columns) and along the bottom-right of the tree itself.
Our first tree is done.
But what about other types of trees? What we have looks like it might be a dark wood tree. Can we make a lighter shade?
Sure. We can even use other shades of green for the tree too.
In fact, by experimenting with other colors, we might make something like a cherry blossom.
But what about bushes? This post started with comparing trees and bushes to clouds. How to bushes fit in then?
Well, now that we have a tree as an example, bushes are really easy. To transform a tree into a bush, we merely remove the trunk.
By selecting the upper part of the tree (everything but the truck), we can move it over top of the truck, thus creating a small bush.
And, by stretching the selection to fill the image, we can create a large bush.
Of course, this new, larger bush is rather boring. By drawing over the white pixels and then adding a pattern inside the bush, we can change that.
And then, by changing the colors inside the bush, we can create different types. Like, maybe a blue berry bush?
Or even something much more mysterious looking.
Previously:
(I use Paint.Net to make these examples, but two open source programs, GIMP and Pinta, work just as well.)
(I also turn on the pixel grid. In Paint.Net and Pinta, it’s under View->Pixel Grid.)
Between ground, building, door, and wall (brick) tiles, we have enough to make most of the outside tiles we would ever need. By mixing up the patterns and colors, we can cover different locations and their associated styles pretty easily. However, the one thing not covered yet is floor tiles. For those, we combine some of the techniques brought up in the other posts. Notably, tessellations and repeating patterns.
Making a new 16 x 16 image, we can fill it with black.
Selecting a 8 x 8 rectangle starting from the top-left corner, we can create the first instance of a new tessellation pattern by drawing a grey (#7C7C7C) 7 x 7 square inside that.
By adding an outline to the top- and left-most sides of the grey square in a lighter shade (#BCBCBC), we can finish this first instance.
Now, we copy and paste the 8 x 8 pattern three times so that there are two rows of two instances each with a single row or column of black between them.
Ta-da! A tiled, well, tile for the inside of buildings.
Using the template of a 8 x 8 pattern tessellated, we can build other variations too.
For example, to make a more science-y looking tile of a grated floor, we can draw a grey checkered 7 x 7 pattern within a 8 x 8 (with the bottom- and right-most side left black) square.
And then fill the image with the pattern.
We can even create a marble looking floor tile the same way.
First, with a new 16 x 16 image, we fill it with grey (#7C7C7C) this time.
Then, with a 8 x 8 selected rectangle, we can draw random pixels of black and the lighter grey (#BCBCBC), making sure to have at least one pixel on each side of the selected space.
And then, we repeat this new pattern to fill the image to create the effect of “noise” within the image the way marble might form naturally.
Of course, not all floors have marble or simple grey blocks either. Some have large, ornate patterns.
Or even simply one color.
However, all buildings of the same general style or within the same geographical region generally have same the color scheme. So, varying the colors dramatically from one building to another within the same village, for example, can often be distracting to the player.
This doesn’t each house within that same example village can’t have slight variations though. Maybe the direction of the inner tiles points another way from house to house. Or the floor tiles could be upside down or reversed too.
