Showing posts with label Design Philosophy. Show all posts
Showing posts with label Design Philosophy. Show all posts

Thursday, October 18, 2012

So What is Agon and Alea?

Agon and Alea is a game for ladies. It's about heroes and companionship. It's on the iPad and uses new technology ("Augmented Reality" to bring a small digital character 'into' the real world, so she can see it standing on her hand (A bit like the Holodeck from Star Trek). This character is a social and emotional toy one can play with, and a little like a digital child, boyfriend, and pet all wrapped into one. Agon and Alea is also an adventure game in which women coaxes this character through story obstacles and enemies to save the day.

When I started Agon and Alea, I put off starting my blog for about a month. I had no inspiration to write anything. Then one day, in the midst of frustration and uncertainty, I logged in to www.blogger.com and began vomiting my feelings and thoughts out into text. This kind of writing is really neat, really therapeutic, really enjoyable- for me. I read my own stuff, and I remember exactly how I felt- it's like a diary of my emotions, my highs, my lows, my epiphanies. Re-reading it is a real big emotional booster for me.

But then some days I just wanna get online and write down the whole cohesive narrative of what the heck I'm doing- instead of tossing around thought vomit ;)

So, what is Agon and Alea?

Graduate school is a doozy; I'm expected to change the world. I came in 'just wanting to make games.' Research sounded stupid. I wanted to make what I played, and play what I made. Strategy games. Horror games. Normal games, I now realize, but better than they had been done before.

Then my Teacher/Mentors stopped me in my tracks with a brick wall of graduate-level questions. I smashed into that wall over and over and over again, crying some days I was so confused about what I was doing wrong. Was something wrong with me? Was I just incapable? Why couldn't I figure out what he wanted me to do?

He didn't want me to do anything; he was trying to make me think about games. This wasn't to say I was adverse to thinking; quite the contrary! Actually, the issue was that we take for granted what we know, and it prevents us from exploring.

Somewhere through my first quarter here at SCAD, I began making breakthrough after breakthrough. Everything about my games changed. The gameplay became richer, more interesting. People started getting excited about what I was doing. I started getting excited about what I was doing. I started off thinking that some of the exercises I was being put through were just that, exercises.

My teacher would ask me to design a game for small children using unique input devices. Blah. That's not a horror game. That's weird edutainment stuff. I got in to this major because I liked Bioshock; not for LeapFrog.  But once I gave it a try, once I pulled out all the stops and really let my mind explore, I started coming up with some things I'd never seen or heard of before. The stuff I was coming up with? Actually meant something in the grand scheme of things.

I meant something. I had power. I could change things. I could invent a product that altered how people thought about something. Me, a game designer! I'm no surgeon, no rocket scientist, no lawyer, no judge. I'd told myself on occasion- whenever I was struck by the thought that 'video game design' and 'novelism' seemed petty in comparison to 'rocket science' (which I would probably also be capable of doing) that I would never want to be responsible for a project where one small mistake could kill a person. Holy crap! Why did I have to tell myself that!? Did I feel like I was wasting my talent? Did I feel like I needed a reassurance, or an 'out', or some explanation for my waste, and that cowardice was an acceptable excuse?

Who knows what I had been thinking. But what I know now is that my chosen career path requires greater courage- and provides for the chance to make greater cultural change- than any rocket scientist ever could. Engineers don't put their stories, their messages, their immersive interactive experiences, into the homes and hands and hearts of today's children. Not really. Not like I can do. I am in an immensely powerful position. My mentor taught me that.

Agon and Alea is an amalgamation of everything I learned about myself and my talents in Interactive Design 101 here at SCAD. And a composite of everything I've learned since. It represents who I am, what I'm good at, what I'm passionate about, where the core of my heart is. For me, games are a way to make the fantastical, real. They let us leave the real world and explore an imaginative space- a fairy world- and then return home safe and sound. To me, each game is a Where the Wild Things Are or a Slumberland. And I'm really big about getting anyone and everyone to get up and let their curiosity lead them off into these worlds, so they can play and escape and relax and wonder for a bit.

Agon and Alea is a video game for ladies. My target audience starts one or two generations my senior and stretches up through the baby boomer dames. My observation is that these are a group of women who just don't get enough play time. No one but Tide Bleach and Better Homes and Garden advertises for them. No one is encouraging them to play, wonder, escape, or relax- unless it's the time share industry (And the damsels and dames I'm aiming for are way too clever with their finances to get sucked into unnecessary time shares.) Even cruise lines prefer to target her children and husband over her and say - "Look, your family will have such a good time, so you should buy this!"

I've been conducting research on my target audience for awhile now. I'm looking both at women in this demographic who already game, as well as women who aren't drawn into gaming- and why. I'm trying to figure out how to make a video game that does something for her akin to what TV dramas do for her- but interactive instead of passive.

Now this is where the research comes in. Because anyone (and I do mean anyone) can look at what I've said about and quickly summon together an opinion about women. I often gets stuff like... let's see... "Hold on a second, you should know that women are more motivated by their families than men." Or "Women just enjoy passive media more than men." For some reason, people can snap together a gut instinct on the issue to explain away the current state of things faster than on almost any other topic.

But that's what my Mentor was telling me all that time ago when I started out my video game quest. You are taking what you 'know' for granted. My job is to stop taking all this 'common knowledge' at face value.  I am disinterested in what women are, or what we know them to be like. If women are one thing, a known constant, an unchangeable pillar, than there are no new products we can pitch to her. If she can't be altered or swayed, if she has no unmet needs, or if her needs are unmeetable, than we have nothing- as designers, developers, producers- to offer her.

But this is not the case. The minivan, tupperware, the microwave, the cellular phone, the right to vote, the dress suit, organized sports in elementary schools- these things changed what it means to be a 'woman,' a 'mother,' etc. forever. These products built on pre-existing utilitarian objects, but they opened up new channels, new forms of culture, new ways of being that previous products never had.

Designers changed culture by designing new and previously unthought of experiences for ladies.

Which means that if I stop accepting the face-value assumption that what women need is a faster can opener, and I start looking at the underlying requirements of her life, I can come upon the startling realization that she doesn't even need cans at all- she needs plastic tupperware. Alternatively, if I stop answering 'why don't women play games?' and I start looking at the underlying requirements of her life, I can find a need that only games could ever possibly meet.

My job is not only to question common knowledge, but to actually ignore facts (effects) about women all together and reach down to find out the forces that drive her. Women love collecting fashion objects? Okay. Why? What does that satisfy in her? What is she longing for? What does she lack? Who did she inherit this practice from? her mother? Her grandmother? Her friends? What need did it satisfy then? How was she first introduced to it?

Zynga asked those questions and realized that women didn't need a game about shoes. They wanted Farmville. They just didn't know it yet.

So Agon and Alea is a game about companionship, social play, emotions, moods, and heroes. It gives a woman a character she can respect- like the protagonist of a TV serial drama- but makes that hero small and slightly vulnerable to her and her alone. He (or she) needs the player's attention and care, and in exchange he is capable of great feats of intelligence, craft, acrobatics, strength, honor, and bravery. He is a character the player can take seriously, drawing in an audience that otherwise despises cartoons and mindless play. A character like Captain Kirk; or the protagonist of I am Legend; or Gregory House.

The character is unique to her, and remembers what she tells him. He has needs, wants, desires, habits (good and bad) and personality quirks. Some can be trained out of him/her; others he will convince the player to accept. The character is intelligent enough to analyze the player, and complex enough to be analyzed by the player, as both attempt to optimize their relationship while at the same time pressing their own needs. He is devoted, loyal, and while occasionally grumbly or aloof, he will always rush to the player's defense in a time of need.

Oh, and she can take pictures with him on her shoulder and send them to her friends.

Agon and Alea is a digital doll, a TV drama hero, a miniature friend, a fun toy, an escape into another world, and a facilitator of play- not necessarily for a  lonely introverted woman- but really for any woman who needs to recapture a little bit of the magic they experienced when watching a movie like Indian and the Cupboard, or from when they once believed their Dolls came alive at night, or Fairies roamed in the backyard garden.

My project with Agon and Alea has another big fundamental component: Distribution. But I'll save that for another blog post. For now, just know that while we spend a lot of time designing this game, we spend a lot more time figuring out how to A) inform ladies about our product, B) get the product to the ladies, and C) lower her guard enough that she'll be willing to give it a try.



Monday, October 15, 2012

SSH vs HTTP posting for GIT: What it means to be Artistically Technical

Acronyms, right? Do you know what SVN is? GIT? SSH? HTTP?

Tagging People


When a person in my industry self-identifies, they usually give them-self some sort of appellation  There's an adjective, a tag in there. A person may be a Business Person, an Artistic Person, a Technical Person, a Communications Person, a Managerial Person, etc. These aren't related to a person's job, or place in the company- well, not by causation, anyway.  An Artistic Person thinks with the right side of the Cerebrum. A Technical Person thinks with the left side of the Cerebrum. A Business Person thinks with the Cerebellum.

Okay, that was mean. But you get the point.

But as a Game Developer, I find that I get no part of the brain assigned to me. Depending on the phase of the moon and the disposition of the client, I am a Technical Person, an Artistic Person, or a Business Person. There really doesn't appear to be any 'Developer Person' role.

This presents a problem, because, as a Game Developer, I have a totally different purpose than someone who sits soundly within one of these predefined tags. If you just arbitrarily call me an Artistic Person because you know I can draw (a little), it seems then as if I become a FULL ARTISTIC PERSON, bound by the metrics and expectations that that post encapsulates.


Role-playing Metaphors



Let's use a DND Metaphor. This is like there are only three classes that anyone ever talks about, "Warrior," "Cleric," and "Rogue," and then me rolling up a Ranger. After that, give that I can fight, cast a little magic, and sneak around, you call me a Warrior, Cleric, or Rogue respectively, depending on what you need at the time. But doing this is going to frustrate our relationship: I can't live up to any of those three classes. In fact, my purpose is totally different from all three of them. Like I have a pet bear following me around, for starters.

So let me tell you what I'm actually good at. First of all, I can wear a lot of different hats. But second of all, the hats I DO wear, are different from the ones your straight-discipline guys wear.

I wear the hat of leadership. Ordinarily this would mean I'd know how to motivate people and seize the day. But specifically to me, I trade off some of the specialty leadership would ordinarily afford and exchange it for a competent and fairly detailed understanding of the development  process as a whole. A pure-blooded "Leadership Class" person has spent a lot more time learning how to manage time, keep on target, and set goals than I have.

But my derivation of the "Leadership Class" is synergistic with all of my other 'Development' hats. I've traded off some time I could have spent purely on leadership for a set of different skills that affect me in many ways. I know how to talk to programmers, to artists, to writers, to business people. I understand the relationships between the different parts of the whole, and where fractures can cause an entire company's development process to ground to a halt. And a totally self-contained "Leadership Class" couldn't do that.


My Two Hats



Now if you asked me, I wear about two hats. The first hat has to do with Leadership/ Production/ Management /Networking/ Business. This hat is newer, and I'm still working on developing it and integrating it with the rest of myself.

The second hat, much older and more established, is the Artistic/Technical hat. Right now, if you asked me what I am, and 'Designer' or 'Developer' wasn't a good enough answer for you, I'd tell you that I am an Artistic Technician.


Artistic Technician


So what does it mean to be an Artistic Technician? I am obviously not an Engineer or Computer Scientist. I'm not even a Computer Programmer. But I am also not a Writer, not an Artist, not a 3D Modeler, Texturer, or Character Concept Artist.... What exactly is it I do? Certainly I can do SOME of all the above tasks, but none as well as a specialist. To fill in their boots is to be a Ranger filling in the role of an absent Warrior.

Where's the bear that follows me around?

An Artistic Technician's strength comes from their ability to apply a wide variety of unrelated disciplines to a seemingly unrelated problem. We are cross-disciplinary creative problem solvers. At first this sounds like I'm saying I can solve Artistic Problems, but I only have half the Artistic Tools- and that I can solve Programming Problems, but I still only have half the Programming Tools.

Not so!

The real value of an Artistic Technician is that I can solve Artistic Problems with Neurology Tools, and Engineering Problems with Interior Design Tools. Here's a case in point: an Engineer has written a piece of software that can do unusual computations. Right now, he is working on trying to find the perfect technology for programming a computer to drive a car. Everything going on in his mind is related to camera vision. His narrow focus means that he is able to reach out very far in one direction, but simultaneously he is aware of few disciplines outside his own. He can neither pull nor push ideas to or from those other disciplines.

As a Artistic Technical person, I don't have the in-depth understanding of camera vision to program very sophisticated vision software. In fact, I'm not even up to date on all the technical jargon for the discipline  or the latest algorithms. But I have the baseline tools. That is, I have the access tool that allow me to peer into any discipline and follow a quick path from no understanding of a given subject to a functional understanding of a given subject in a very quick period of time. For any discipline.

So although I'm currently designing a game for children that involves spelling, I can A) translate a game problem into generic terms, B) go out, research, and find a few disciplines that may be able to yield solutions to my generic-ified game problem, C) find the engineering paper on computer vision, D) read and comprehend the paper sufficiently, and E) take his work across a wide variety of disciplines and apply it to video games totally unrelated to computer vision, who merely use the technique in order to augment the 'fun' factor.

And likewise I can take anything a fashion designer knows about how the human eye registers distinct visual objects, and talk to the Engineer about it in terms he'll understand. My knowledge might change the way he thinks about the problem he's trying to solve, and inspire a solution from an entirely new angle.


So What are SSH, HTTP, and GIT?


Lately I've been working with Social Coding frameworks in order to make my coding process smoother and more intuitive, and so that I can develop simultaneously on multiple machines. I had never done this before, and so ran into a lot of hiccups as I struggled with alien terminology and command lines.  Of course, the process of working with the Social Coding framework has probably taken up more time than it would have saved- but that's only for this specific six week project. Now that I have an understanding of how social coding works, I am going to be able to understand similar paradigms forever- really useful given that odds are most of the teams I'll ever work on will use some form of Social Coding framework.

A network person might laugh in my face at the difficulties I had. After all, countless thousands of people out there all use Social Coding. It's not like I discovered a new planet, here.  But the issue at hand here is that those people are usually working IT jobs. I'm a Technical Artist. Am I just fooling around with stuff I shouldn't have to know, ignoring my true discipline? Heavens, no!

Just imagine down the line when the IT department and Art department are arguing over an asset that has gone 'missing' in a network Commit, and no one can seem to make the other side understand exactly what the 'problem' is.

My talent is not in understanding everything. I trade off having an in-depth internal library of knowledge concerning every one subject in exchange for having the baseline tools to understand just about anything. And then I only learn tools as I need them. I am an interpreter, not a compiler. And I like that word 'interpret.' Because not only do I absorb skills precisely in the order they become useful, but I also interpret between different disciplines.

 I cannot stress how important this is: because usually the different disciplines of the world all 'know' certain things that they've never shared with other disciplines- things that would make everyone's life a lot easier, and advance technology a lot faster. Imagine if your teacher actually understood how to use all the technical tools available to them through the school. Imagine if they knew how to use every feature of blackboard, and had a thriving internet metropolis of ideas flowing about online as a result. Imagine if the guys who build blackboard could actually talk to the teachers, and redesign the system for increased usability.

Cross-discipline problem solving is everything. For the everyday layman, every technological problem they could ever have has already been solved by someone out there- they just don't know how to find that info or what to do with it if they find it. I'm the missing link.

For games? For one of the most interdisciplinary jobs on this planet?

Cross-discipline problem solving is probably the most valuable skill a developer could have.


Git, Plz


So what did I do? Simple on the face of it. My GIT repository for social coding was having difficulty accepting HTTP posts that exceeded a certain size. Although I was pushing <50MB, the system was slowing down and hanging and the remote server was hanging up unexpectedly. Part of the issue may have been when I re-imported my Spartan King prefab from the Asset store in order to get back some animations that had gone missing along the line.

I simply upgraded my system to use SSH keys, which all in all took about two hours with some setup and troubleshooting guides and an alternative .bashrc script I found on Stackoverflow while Googling. Then it worked like magic and I've been pushing fine ever since.

If you understood a word of that, you still might not understand why my skill set is so valuable because you underestimate the difficulty of what it is you already understand, and you also have no way to gauge how difficult other aspects of my job are, like designing this so that it stretches properly in the Unity 3D engine:


For those of you who didn't really understand a word: rejoice! I exist as a point of communication between you and the tech guys, and I can report back simply this:

I put together a system so you can download the latest version of our project from any computer in the world. It's always up-to-date. We got a bug in the system when the project started getting too big. I fixed it this morning. This means it is going to be easier to back up and archive our art from now on.

Tuesday, April 10, 2012

Alan Cooper and the Goal Directed Design Process - Hugh Dubberly

This paper was written as Hugh Dubberly's explanation of Alan Cooper and Alan Cooper's Goal Directed Design Process.  It receives a Gaming Imperatrix Thumbs Up.

Style and Contents

This paper was written in an instructive/explanatory/educational format. It was smooth reading even though it contained a great deal of useful insights, and was generally a pleasurable paper to read. The paper is structured with a page of introductory material.

It introduces the reader to Alan Cooper, who he is, what he cares about, what his goals are, what is background was, and what his driving forces were, which let's the reader get a good sense of where the paper is going to go.

After this, it highlights in bold the five steps of his goal-directed design process. In each section, it writes in italics the old methodology, that this bold step replaces. Then it explains the reasoning for the approach in plain text.

After this phase, he goes into a further study of the goal-directed design process, homing in on useful details. For example, the Designer + Design Communicator core that Alan Cooper advocated building teams around, the evolution of the design process and the necessity of putting design before programming, the different dimensions of design, an input/output table for the software development process concerning persons on the team, and then a final overview of Goal Directed Design and a methodology for how to build a successful product by using GDD. The paper is covered in graphics, tables, and charts, all of which are fairly easy to synthesize.

Interesting Observations
I liked this paper, and learned a bunch of interesting little tidbits from it. Although I knew that software development had gone from lone-wolf programmers up to an elaborate design process, I hadn't thought of it in discrete steps before, or realized that the step we are currently unseating (or have just recently unseated) was a phase of doing design and code work at the same time.

I noted with interest that Alan cooper (or Hugh Dubberly, I'm not sure which) considered Art and Design to be more-or-less the same thing! This was a useful insight for me, because I am interested in being a game designer, not a game artist. In the movie industry, movies usually always have distinct producer, director, art, and technical roles. In an analogy, I want to be the director for a video game. I've been coming to the realization over the years that this role is still working to manifest itself clearly in the industry. One would hardly think of shooting a movie without a director, but for some reason it seems okay to build a game without one? Nonsense!

I have also been listening to how gaming companies are structured, and have noticed that the role of director/designer frequently gets mistaken for or folded in to other roles. Sometimes it is the lead programmer, other times it is the 'Creative Lead.' Now I understand why anyone would fold 'Designer' into 'Creative Lead,' as there is a theoretical precedent for it!

Hugh explains- and I think his phrasing/Alan's idea is superb- that there is a conflict of interest between Programmers and Designers. Programmers want something to be easy to program, and Designers want it to be easy to use. If you use that means of thinking, then obviously there must also be a conflict of interest between Designers and Artists. But the conflict of interest is deeper than just how much work a person has to do.

A Programmer has a conflict of interest with a Designer because the Programmer wants something to have good, functional code that he/she is proud of. He wants to show off his programming. His programming becomes his center of focus, instead of design. Likewise, the artist's art becomes the center of focus for them, instead of design. Design- the composition of all of the game's various interrelated elements, from the data gathered by market researchers for use in HCI, to programming, to art, to user requirements, to producer requirements- that composition job is a job all in its own, and should be kept free from any other job that might try to claim it.

I love the idea of pairing a Designer- or really any job- with a dedicated communicator. Usually the people who have technical skills are not necessarily the best communicators!

I enjoyed looking at how the individual rules on the software development process interrelate based on the input/output chart, but some of my favorite graphics were about Cooper's People/Technology/Buisness model. At my old school, Architecture and Design were of course grouped together, and our Games students presented their final projects with Archtiecture students.

I agree that they share many attributes- although I feel Architecture is more closely related to Level Design and Installation Art than to Game Design as a whole. In the end, Architecture is about designing spaces, and the usability of spaces; but Game Design also requires Interior Decorators to make the art, Physicists to make gravity work, and a Director to make sure they're all working on the same project.

I also like how the paper compared Cooper's specific software-design model to the original model and derivations thereof. He showed us the abstract version (Desirability/Capability/Visibility) with its abstract-y words next to a more functional and applicable version, to show how the abstract version could be instanced into a functional model.  Cooper's explanation of Apple, Microsoft, and Novell using this system extended its ease-of-use even further.

All in all a pleasurable read. A+