Tuesday, February 25, 2014

The Validity of the CS222 Final Project

Grant Wiggins most recent blog post shares a practical test of validity for assignments. When he was asked whether a given assignment was valid, he posed two questions in response:
  • Could the students do a great job on the task, but not meet the goal of the assessment?
  • Could the students do a poor job on the task but still provide lots of evidence that they can otherwise meet the goal of the assessment?
If the answer to either is "yes," then the assessment is likely invalid for its goal.

This made me think about the final project in CS222. (I used to call it "the six-week project," but since expanding it to nine weeks, I have not found a catchy name for it. "The nine-week project" doesn't have the same ring to it.) Briefly, work in teams of three or four to pitch an original software development project, and this project becomes their focus for most of the semester. In theory, this project is supposed to serve as a context for students to explore course content, such as refactoring, Clean Code, design patterns, and human-centered design. These elements are emphasized in the rubric by which the three project milestones are evaluated. However, despite the rubric's being public, most of the teams inevitably miss points across all elements of the project—in all three milestones! Having the project delivered in three milestones is, in part, scaffolding: the feedback on the first two milestones is primarily formative. Could the problem be that the project is not valid for my goals?

Let's look at this semester. My course description is public, and the department's syllabus specifies the following student learning outcomes for the course:
Upon completion of this course, a student will be able to:

  1. Explain and apply pair programming
  2. Explain and apply test-driven development
  3. Use the interactive debugger in an integrated development environment
  4. Apply code review techniques to identify design and implementation defects
  5. Apply principles of object-oriented design to create and analyze domain models
  6. Explain and apply model-view separation
  7. Apply user-centered philosophy to design simple graphical user interfaces, justify usability considerations, and implement the user-interface in a high-level programming language.
  8. Planmanagepresent, and evaluate multi-week programming projects—including software feature estimation and milestone reporting—created by small teams
  9. Demonstrate reflective practice for professional improvement
The final project is designed to permit students to demonstrate mastery in all of these outcomes. However, since Pair Programming is required in a two-week warm-up project, it is not mandated in the final project, and so outcome #1 can be dropped from discussion. The final project description shows the rubric for milestone presentations, and the milestone evaluation rubric—which is available to the students via Blackboard—breaks down as follows:
  • Clean Code, structural principles: 6 points
  • Clean Code, process principles: 6 points
  • Version control: 3 points
  • Project configuration: 3 points
The Clean Code principles address objectives #2, #5, and #6. I use in-class activities to enforce #3 and #4, and the milestone presentations have to address #7. Clean Code together with version control and project configuration address #8, and if students haven't hit #9 through reflective essays, they certainly encounter this in the final exam. 

With the facts established, we return to Wiggins' Socratic questions.

Could the students do a great job on the task, but not meet the goal of the assessment?

Answering this requires consideration of what "the task" is. I have discovered that teams will frequently focus only on the functional correctness of the application: given their first for-credit opportunity to make anything, they want to invest energy into making that thing work! Students seem to perceive the task to be "make this thing work," despite my explicit and repeated admonition to follow the requirements. It frustrates me that students don't perceive the relationship between the two: they don't see the "content" of CS222 as being something that can help them make their projects work, but rather as isolated knowledge. That is, their collective action belies devaluation of these ideas.

It seems that teams try to do a great job on the task they have defined, and some indeed do, but this comes at the cost of doing a poor job on the task I have defined—which, of course, is the task that is evaluated by the rubric. Hence, students cannot do a great job on the task without meeting the goal of the assessment as measured by the rubric.

Could the students do a poor job on the task but still provide lots of evidence that they can otherwise meet the goal of the assessment?
I have no existence proof that this can happen. In about three years of teaching this course, I have never had a team show me well-factored, well-designed code that did not also meet their own functional requirements. Could it happen? I suspect not. All the tools and techniques that we discuss in CS222 are included specifically because they help people make software, and teams that have used these techniques also make good software. If such a team ever encountered a case where they could not meet the self-imposed functional requirements, they could simply modify these requirements as part of a milestone presentation re-estimation.


This analysis shows that the project is valid for its objectives, but student actions are not aligned with the explicit goals of the project. This leads to two questions: Why do students—who are normally grade-driven—reject the framing of the project? How do I encourage them to move in more fruitful paths?

I received useful feedback through course evaluations about an earlier, structural course problem: I used to talk about requirements analysis tools while the teams were in their first iterations. Since switching to the achievements-based approach last Fall, I have been more careful to introduce CRC cards, risk matrices, and user stories before the first iteration. Now, I can lean on teams to use these tools to drive their early efforts. Unfortunately, there is still little evidence that they do: when left to their own devices, the teams devolve into undisciplined ad hoc development. That is, they use hope-driven development, a term I have coined for the process where you write a bunch of code, turn it in, and hope you get points. I have tried explaining to teams that this is foolish when the rubric is published before the assignment is even given, but somewhere, there's a breakdown.

I will note here that  I don't require one particular approach in any iteration. That is, I don't force teams to use CRC cards, risk matrices, or user stories. If they do, they earn an achievement, which helps earn a high grade in the class, but I intentionally give them the option to fail. I just wish fewer students took that option. I have considered moving back to a model where I institute formal assignments and require students to try these tools, but I would rather do something more studio-based. Take CRC cards for example: right now, we spend a day on them, each team building up CRC cards for the two-week project, and then we talk about similarities and differences among these. This is a good use of a class period, but few students ever touch the CRC cards again. We could spend another class period having each team do a CRC analysis of their final projects and share these. I won't know if this helps until I try it, and at this point, that means next Fall.

Monday, February 24, 2014

Painting Drizzt, Part 1: Technical Experiments

In this rather lengthy post, I tell the tale of how I continue to enjoy learning how to paint miniatures. Here's the TL;DR version: I painted some figures and learned a few things about painting, miniatures, and myself.

Following up on my painting the Mice and Mystics miniatures, I began painting the miniatures from The Legend of Drizzt. A student had told me he enjoyed it, and so when I saw it on a post-holiday sale last year for about 75% off MSRP, I picked it up. My oldest son and I enjoy playing this cooperative adventure game. Although the systems are relatively simple, we have had some fun emergent story, such as the time that Bruenor Battlehammer defeated a swarm of spiders by headbutting them, or when Wulfgar popped a feral troll with a killer bear hug.

The game comes with 42 unpainted plastic miniatures in a variety of shapes and sizes, and so I decided that this would be a good place to continue experimenting with painting techniques. As I mentioned in my previous painting-related post, I relied heavily on Jerry Hawthorne's Painting Guide to get through the Mice and Mystics figures. Since then, I have spent a lot of time reading and watching videos to learn more about the fundamental techniques of miniature painting. I have particularly enjoyed Dr. Faust's Painting Clinic's Web site and Basics video series as well as the articles at how-to-paint-miniatures.com. I browsed the Web for some ideas on how to approach the Drizzt figures, and I was particularly impressed by the images in a thread at WOTC; the picture at the top is nice, but it badocter's replies that I found most inspirational.

My son and I have played the game about a dozen times, and I had remembered the figures' being fairly nice. In fact, when you look at them with an eye toward painting, they cut a lot of corners... or rather, did not cut the corners. Check out Artemis Entreri's leg, for example:

This is not a significant impediment to my painting, of course, since I still very much feel that I'm learning the basics. These aren't supposed to be show-quality pieces. What is interesting about this, however, is that I didn't notice modeling shortcuts like this until I looked at them from a painter's perspective: I'm still learning how to see what's really there rather than what my brain assumes is there.

I started with the spider swarms, considering them to be the roach-equivalent figures of this game. My intention was to make them shiny, glossy red on a black field. I started by priming them in white, which turned out to be a bit of a waste of time: the first thing I had to do was to wash heavily them in black to get all the crevices to be shaded.

Next, I tried getting some red on top, using a glaze... or with drybrushing... or just glomming it on... No matter what I tried, I got grimy purple. This was humbling: my first simple figure, moving forward without a painting guide, and I couldn't even get red paint on a black spider. I took a series of pictures of the various attempts, the intention being to note which turned out best, but at this point, all I had was an album of frustration. Here is a selection:

I was pretty worn out, but I decided to put on one more coat of flat red before throwing in the towel on these spiders... and finally, I was getting somewhere. It was kind of like magic: this time, this coat, I was seeing results. A few days later, I read about how red is notoriously hard to paint, and unless it's put onto a white base coat, it takes many layers to bring it out. The more you know. Here's the final result (sans basing and varnish), which I think is decent—simple yet passable, calling out for a headbutt.

Next up were the goblins—those ubiquitous subterranean low-level minions evil, higher only than rats and kobolds on the villainous food chain. When I was painting Mice and Mystics, I pre-shaded the figures according to the painting guide, but it was hard for me to see the effect it had on the final figures. Having three identical goblin cutters, I thought it would be fun to pre-shade them differently, but then paint them the same.

For these and the next several models, my explicit goal was to practice the combination of basecoats, using washes for shades, and using drybrushing for highlights. Here are the goblin cutters with their flesh basecoat:

When I mixed this basecoat under my working lamp, I was confident that it was a good brightness. Looking at it later, I thought it might be too dark. I kept this flesh tone through all my goblins, though, so they are all a bit dark, but at least they are consistent. Also, the flat yellow highlight on top of the head really helps. The goblin cutters were the first minis on which I painted the eyes. I used the "The Easy Way" from The Painting Clinic tutorial: shading the socket, painting the whole eye black, then dropping in grey dots on either side.

At this point, I cannot tell the difference between the three minis with respect to the pre-shading. A careful reader will notice that I marked the base of the most heavily pre-shaded one. In bright natural light, I still see no difference. This doesn't mean the technique is worthless, of course—it just means it's not worth it for me to worry about at this point in my practice.

I followed the goblin cutters with the three goblin archers and the goblin champion. Here they are as part of the continued pre-shading experiment.

And here they are finished. Champion's a bit out of focus, but that's because he's coming to get you.

I was doing a lot of reading and watching video tutorials throughout the goblin-painting process, and it was around this time that I decided it would be fun to base my figures—that is, to do something with the bases besides just painting them. Indeed, one of my impediments in understanding some articles earlier was that it wasn't clear to me what "basing" was, as a verb, since it looks like a synonym for "basecoating." Also, I'm not confident that "basecoat" is a verb, but I suppose I can wordify it.

I made a trip to the downtown hobby shop and picked up some model train ballast in three sizes: coarse, medium, and fine. I got three different colors, knowing that I would be painting over them, so that I could see how they behave when mixed together. Based on some unexpected advice, I also added some ground cumin for a very fine texture. My friend Barb put it best when she said that cumin is "the only thing that smells both like a food and a locker room." My blend used even proportions of each, and I affixed it to the base using thinned white glue, dipping the figures into a small plastic container.

The next step was the paint the bases. At this point, I wouldn't be able to distinguish my different pre-shaded figures, but this was no longer important to me.

Finally, a black wash and grey drybrushing to bring out the shadows and highlights. The camera doesn't do justice to the difference between the pictures above and below: the highlights you see above are all from the light, while the ones below are painted on and, in person, much richer.

All the goblins were done in the same way, then hit with a layer of dullcote to take off the shine. Here's the happy goblin family.

The goblin champion's chainmail armor was painted using the technique described at how-to-paint-miniatures.com: black wash to get into the cracks, then successively lighter and brighter drybrushed mixes of black and silver. That was my first chainmail, and I think it turned out quite nice.

If you search long enough, you will find someone advocating for every sequential combination of base, prime, and paint. I found it awkward and stressful to do the basing last: drybrushing the rocks around the goblins' legs, using a crummy brush, I had to be very careful not to dust boots or feet. For the three hunting drakes, I primed first, then did all the basing work. The little bits of grey that landed on the drakes' legs were easily covered later in their basecoat. I followed this sequence for the rest of the figures in this post.

The texture of these drakes made them a good candidate for practicing basecoats, washing, and drybrushing. I decided to give them a yellow-green basecoat, and I used multiple layers of drybrushing on the scales. The washing proceeded in a few phases: dark green was used to emphasize the scales, while black was used on the undersides and for pin shading the spines, frill, and limb joints.

Legend of Drizzt comes with six translucent blue figures—the only like this I have ever seen. Three are hypnotic spirits and three are water elementals. I decided to copy the style from the thread I mentioned above, painting the models without priming them to keep them looking otherworldly.

It wasn't clear to me how to achieve the effect I wanted with the water elementals. The middle one was the first I painted, where I used dark blue paint on the edges, followed by light blue, followed by almost-white. It turned out OK, but the lines are a bit too chunky, too stark. On the two flanking elementals, I used drybrushing on those areas, again in successively lighter colors. This looks less stark, but the effect is almost too subtle: without a before-painting shot, it can be hard to see where I've spent any effort. In the end, I decided to leave these as-is, in part because it's such a bizarre corner case for painting.

These hypnotic spirits were done in three slightly different ways. I did the middle one first, with a purple wash followed by grey drybrush. The wash beaded up on the model; in retrospect, I realize this was a problem of surface tension, likely exacerbated by the lack of primer. I used the brush to push it around, but it still dried splotchy. It took significant, heavy drybrushing to cover or hide the splotchiness, and that figure is much darker than I would have liked. The one on the left was next, and it's a grey drybrush followed by a purple wash. It turned out much nicer, though perhaps too light. Finally, the one on the far right is the baby bear: it turned out just right. For that one, I used a wash again, but where my previous mix was about 4:1 water to Future polish—yup, floor polish—this one was closer to 1:1. It sunk into the cracks perfectly, and I was able to drybrush exactly how much I wanted to on top, rather than having to cover my tracks.

Next, I decided to tackle the drow duelists and wizard. The purple figures that came with my box were quite badly warped. I understand this to be an artifact of hasty casting, wherein releasing them from the mold too early causes shock to the plastic. The publisher was expedient and friendly in replacing the purple set, but unfortunately, the new set was also warped, although less so. They were good enough to play with, and so that is what we had been using. To paint them, however, I wanted to get them straightened out. A thread on BoardGameGeek has a good overview of the problem and potential solutions, so I moved forward with a mug of almost-boiling water and an adjacent mug of ice water. Here are the minis before intervention:

I held the bent part of each in the hot water, and sure enough, it straightens out as if by magic. Only one required a bit of manual shifting. Moving them into the ice water hardens the plastic again, yielding a much nicer result:

The duelists are wearing full-body armor, and again, I directly followed the tips at how-to-paint-miniatures.com, although I read several other articles on painting armor as well. In my first pass, I painted metallic armor all around the duelists, but upon closer inspection, the backs of their legs looked like they might be intended as leather, with the metal plates strapped to the front. I went back over the metal with near-black leather, and although this darkened the figure considerably, I decided I liked it. What good have drow of bright colors in the Underdark, after all? I got frustrated with the very small eyes on the duelists and decided to leave them without pupils. I used P3 Armor Wash on the plates, and I was happy with the results—as a random stranger at Wizard's Keep assured me I would be when I bought it.

The wizard was my first experiment in a split-complementary color scheme. My wife handed me a pocket color wheel that we had in the kids' craft area, and this was great for imagining different color combinations. I decided to do a purple robe with orange highlights and a green cloak. The green inspired me to match the wizard's cloak to the hunting drakes—my drow are eco-friendly and use all the parts of their animals. I was quite happy with the result, until I posted this picture on Facebook and an alumnus commented on the wizard's "bubble-gum wand."

Aw nuts, it does look like bubble gum. I have been mixing purple without trouble, but I find orange very difficult to concoct. I ordered a bottle of each secondary color since then, in hopes that I can save some time and get more consistent hues. I went back to the wizard and re-painted his wand, taking the opportunity to brighten up the talismans on his chest as well. The wand is a bit out of focus in the picture: only the tip is pure white, with the rest blending yellow.

The keen reader will notice that I followed an orthodox description of the drow, giving them jet black skin. This experience helped me to understand why D&D artists have interpreted them as greys or browns instead. Once you have black, you cannot go down from there: there's just no shading jet black.

I did Dinin about the same time, and he is also very black. There's grey drybrushing on his back, and the armor offers some metallic shine, but he's mostly dark grey. Way deep down, he has white primer, which was tedious to cover entirely in black—black primer would have been appropriate here for sure. If I could do it again, I would brighten up the whole model a little, but I'm satisfied with the result here. There is a purple spider emblazoned on his chest that, in retrospect, perhaps I should have given another coat, since it gets lost with low contrast.

At this point, I decided I wanted to move on to one more new technique: layering. From the videos I watched and tutorials I read, my favorite was a somewhat lengthy one from Dr. Faust's Painting Clinic. He starts with a black-primed figure and builds it up, layer upon layer. Others, such as BrushThralls, recommend starting with a basecoat and adding shade and highlights, but I decided to try Dr. Faust's method. How can you not listen to a guy who uses the MST3K Love Theme to introduce his videos?

I started with Jarlaxle, a figure we have only used once. I know very little of the Forgotten Realms fiction, and so I assumed he would be wearing dark colors, as the other drow. Reading up on the character, it seems that he favors the flashy and gaudy, which made this a good opportunity to get away from all that black. His blue shirt is the first layering I did, using two shades, a basecoat of flat blue, and two highlights. I was a bit perplexed by some of the ruffles and creases in his right arm, but I think it turned out well for a first timer.

Next, I painted the cape yellow, starting at light brown and going up to near-white, and after this, the green pants. The metal bits were done using the same technique as the drow duelists: black-silver base, silver highlight, and a touch of armor wash.

His belt, boots, bracers, eyepatch, and hat were done in leather brown. I thought the red sash, purple feather, and brass hilts add a nice visual flourish. I used a little pin shading to highlight the shadows in the sabre's basket hilt. Here's the finished model, front and back. The shadows on the back of the cloak could probably be brought out more, as it looks a bit washed out. Still, I'm rather proud of it.

Right after doing Jarlaxle's shirt, I did Yvonnel Baenre's skirt. This makes it my second layering project, and my work on these two figures continued in an interleaved fashion.

At first, I was quite happy with this, but then I read a commentary on contrast: how the details on tabletop minis need to stand out from a few feet away, not just up close. Despite the nice layering on the skirt, it wasn't as crisp as I wanted—not enough contrast. I used a black wash in the creases to darken the shadows, and the result was a bit tighter. Here's the finished version.

The purple spider on her armor has more pop than the drider's, although still a bit low contrast. The hair was layered in very light grey. I was afraid to use too much contrast here, for fear of taking away the starkness of the white against the dark armor and skirt. I contemplated mixing in a little blue or purple for a "cool white" feel, but I was unwilling to take such a risk after spending so long on the rest of her.

As I was finishing these two, I continued practicing layering with a figure that has never hit the table: Methil El-Viddenvelp. I envisioned a triadic color scheme of purple-grey flesh, orange robe, brown cape, and blue robe, and I started with the robe. I built it up from dark blue, meticulously painting each little square on the front panel. As I started putting on a light blue highlight, I panicked: it looked much too bright! I gritted my teeth and continued painting, but when I was done, I was convinced I had wrecked it.

It wasn't until the next day that I realized the real problem: I am afraid of bright colors. When I showed the figure to my wife, her first reaction was, "It's all one color," which I interpret as a complement to the layering. She looked more critically as I explained that I had been worried about the brightness of the highlight, and she asserted it could have even been brighter. I think she was right, and this was an important realization for me.

Although I had spent significant effort layering each of the squares on the front panel, I ended up repainting that portion in metallics. Working the layers of tan onto the cloak took a long time, and I am quite happy with the result. The cloak's stitching is done in two layers of brown, only highlighted in those areas where the cloak itself is highlighted. The skin was the penultimate step, but after my first pass, I didn't like it: I had imagined a purple-grey, but what I ended up with was too close to the robe's color—not enough contrast.

The highlights on the head and hands help give the illusion of wetness, but I figured if I did it once, I could do it again. I mixed the shade of grey I wanted, then tinted that with purple, and the result was just what I wanted. I used the usual armor wash on the plates of his upper body, and a localized black wash accented the junctions of the hands and robe, cloak and robe, and head and cloak; the rest was done exclusively with layering. Here is the final result.

As I moved into my layering project, I switched from using a small ceramic tile as a palette to a 10-well plastic palette, and this keeps my paint wet and in one place. This was extremely useful when layering, as I was able to keep my desired basecoat wet while I mixed shades and highlights. I started using some slightly nicer brushes, which do perform better, as well as brush-on acrylic primer, which does not stink. Also, I will share a picture of the cup I use for water, because it is inspirational.

That's it for this installment of my painting stories. These figures provided an excellent opportunity for me to try some different techniques, work on my technical chops, and explore new color schemes. I imagine I will post again when the rest of the set is done, though likely with less detail as I spend more time on refinement and less on discovery. Still, it's fun to share some pictures here and reflect on what I learned through the process, so time will tell. Here's a sneak preview: the battle of the primer colors!

Thanks for reading!

[[Jump to Part 2]]

Sunday, February 9, 2014

Starting the Spring 2014 Studio

This semester, I am again privileged to offer a Video Game Design & Development Studio, through Ball State University's Immersive Learning program. I have eleven students working with me this semester: seven from Computer Science, two from Animation, one from Philosophy and Religious Studies, and one from Digital Storytelling. Our community partner is The Children's Museum of Indianapolis, who I worked with two years ago when I was at the Virginia B. Ball Center for Creative Inquiry.

We spent the first week of the semester going over some basics of game design theory. The team read several sections from Ian Schreiber's Game Design Concepts blog. I don't know if anyone is still actively following the exercises, but even without this community aspect, the blog makes an excellent free textbook on game design. I also assigned a few other readings, including How to Prototype a Game in Under 7 Days and the MDA paper. Each student conducted two critical analyses—the first, a game of their choice, then one that is explicitly educational. Conveniently, Raph Koster posted an excellent essay on critical analysis that same week, and I pointed my students there for some ideas on how—and why—to do the analysis.

During the second week, each student was asked to make a concept document, in Tim Ryan's format, based on any of the given themes from the community partner. The strong majority of these were based on the "Bone Wars"—the feud between rival 19th-century paleontologists Othniel C. Marsh and Edward D. Cope. The team agreed that this represented shared interest, and so then each was asked to create a playable prototype based on this theme.

The story of Marsh and Cope is fascinating, and I highly recommend the American Experience documentary about them. I find the topic rife with possibilities, two of which stand out to me. First, the historic activities of these two men clearly represent a competition for fame: that is, it already had the critical properties of a game. Second, their story is tied to the origins of modern paleontology, which involves significant procedural knowledge—the type of which can be encapsulated in the process of the game.

I wrote a concept document of a variable-phase Bone Wars game and shared that with the team, mostly so that I could model for them how to approach the problem. Every time I deploy Tim Ryan's format with students, a significant portion of thm miss the important point that the description should be in the second-person present tense. This makes for a good lesson when we review the documents, and I can demonstrate the rhetorical difference between this and comparatively dry and "academic" third-person.

The next step was for everyone to develop a playable prototype. My own design evolved into a worker-placement game emphasizing the paleontological process in a competition for fame. About half the students and I put our prototypes forward for consideration, but in the ensuing discussion, we realized that mine was the only one that was actually a playable prototype: the rest ranged from sketches to storyboards, but none were playable. Given the options, the team decided to move forward into production with my prototype rather than spend more time iterating on designs.

There was an awkward moment of professorial decision-making involved in the selection of the prototype. I pointed out to the team that none of their artifacts were actually playable prototypes. A student suggested that we do yet another round of prototyping, because, as the student claimed, now they knew how to do them, and they could work together on it. Both parts of this stung me. The assigned reading clearly explains how the prototyping process works and proclaims the importance of playable prototypes. Actually making a prototype is harder than reading about it, of course, but the matter of what constitutes "playable" is purely theoretical: one who did an honest reading of the material should have been able to identify whether a prototype is playable or not. Also, the team had already been encouraged to work with each other, together in the studio, to develop, test, and tune these prototypes. I made mine in the studio so that I could model my own idiosyncratic techniques, but I was alone the whole time. It seems the students, at that point, had not internalized the idea that we're all in this together. It is possible that the problem here is that recognizing prototypes as playable is actually hard and I have internalized too much, in which case I should develop better interventions for future groups. On the other hand, if the problem is that some students are not taking the reading seriously, maybe I need to encourage more group discussion of the readings. In any case, the clear majority of students wanted to move forward with my prototype and get started with production, and so I did not comment on the matter.

Incidentally, about half the students chose not to propose their own prototypes for consideration by the team. I have very little data about these: I saw some laid out on the table, but I never saw them in action. It makes me wonder if these students did, in fact, create playable prototypes, and through this, realized how hard it actually is to make a good educational game. From some informal conversation, I suspect this to be true for at least a few of the students.

Now, we're two weeks into the first sprint, with plans to have a publicly-testable paper prototype as well as a digital proof-of-concept done by the end of the week. I am enjoying working with the students in these varied production tasks, including creative design work and technical software architecture.

The project blog can be found at http://bonewarsproject.blogspot.com, where you can find student essays and photographs. You can also follow us on Twitter (@bonewarsproject).