Creating A JAR File From Scratch on a Mac in 4 Convoluted Steps

Skip this introductory blurb for steps!

A common problem in engineering that (race card, activate!) hinders minorities from immediately accessing a culture of engineering is the practice of searching.  Yes, really.  Back in college, a black buddy and I went to our CSCI professor's office hours to ask about the class content.

He told us to go to google.com and typed in exactly what we asked him.

She was livid and we were both pretty insulted.  It was pretty lame, but I understand his mindset, today: there are lots of people that grew up with everything they needed to learn how to build stuff. Experienced adults and professionals and their recommended resources are great supplements for learning industry-level creation.  Those people know how to search for the right terms that put them down the right road to get a solution.

Today, when I go to search for how to create a .jar file from scratch, a Google search yields parts of processes that assume I've set up my environment with Eclipse or Ant, that I know how to run a command from the terminal, that I know the terminology used at Oracle's documentation, or some other thing a cool programmer might have shown me or berated me about on IRC.  I do know these things, but my younger compadres in El Monte that haven't gone to USC might not, if they were anything like me.  To give an end-to-end depiction, I'm listing my discoveries below.

Disclosure: the above also means that I don't know how to do everything I'm outlining below.  I'm going to figure it out and you're coming with me.  Your mileage may vary, so don't blame me if it doesn't work.  At the end, it'll have worked for me, pal!

Rudeness disclosure: if you're an experienced programmer, some of my language will offend you because it's going to sound so lazy. That's okay.  I really just want what you do: good practices and good technology. Unfortunately, I'm really critical of how things have ended up, so I'm going to sound like an annoying UX designer and point out every single inconvenience as if it's something an ignorant, uncaring jerk would have implemented.  You have been warned.  What's that you say?  Why don't I change it myself?  Because, somehow, we've screwed ourselves even at a meta level.  It's better to at least berate implementations that came before me about these problems so the next generations make things incrementally better, for now, until I start a company to improve engineering accessibility.

Steps: How to Create A .JAR from Scratch (On An Apple (sucks) Mac)

1. I have the JDK installed. Maybe you should, too.  Here's how to get it.

• Go to the Java people's website.  Their name is Oracle.  You see a digital ton of scary buttons, images, and links. 
• Right now, the link I used says "Java Platform (JDK) 7u17" under it.  Click that image (it's actually a button).
  
• Click through whatever more hoops of "Download the SDK" it links you, then agree to whatever it requires and look for the listing of your operating system.  To check whether you have 64 bit or 32 bit, go to your Apple icon at the top-left of the screen and check out "About this mac" and then whatever additional properties/info is available until you reach it.  It was a pain and I had to Google that up, but eventually it should list your type or you should be able to match your processor to a 32 or 64 bit match.
• Install it like you would any other app.  Usually that means you double click the file after you download it.

2. Get Eclipse.  It's like Microsoft Word but for code instead of essays.

• Go to Google's Android website and click the button to download the bundle.  You can always Google the words "Android SDK" to find this sort of thing.
• It's a nifty folder with two folders inside that say "eclipse" and another that says "sdk".  Go into the "eclipse" folder and you'll find an executable application called "Eclipse".  Double-click on that to run it.
• Some popup will come up.  The popup is dumb and useless to me,  but I never check the box that lets me avoid it in the future because I'm paranoid.  What if, you know?  What IF I want to change where my working files go because it's the end of the world unless I can change my working directory?  Just click the confirmation button that you're cool with it (OK or YES or whatever other submission of will is available) and feel free to be less paranoid than I.

3. Set up your code that will become your JAR file.  This is like opening a new Document in Microsoft Word, but with a lot more convoluted steps that you need to do before you can actually get anything in a practical state to work.

• With Eclipse open, go to the File > New > Java Project menu items. 

• Next, fill out the minimal information like I did in the screenshots below, because too many programmers are still so abysmally ignorant with actual UX in our own tools that you'd think we're simultaneously sadistic and masochistic with all the goddamn text fields, radio buttons, and drop-downs we force on ourselves.  Here, I wrote "Making A Jar" as the project name. 

• Click Finish.  I was busy taking screenshots, so make sure to fill in any information I might have forgotten to let you click it.
• Man, that is one sweet project.  Sit back and nod to yourself confidently, with a deserved smugness.
• What's that?  Oh, you savvy cookie, you're absolutely right: we need a class up in this project so that you can actually write the code for your JAR file.  After all, this class is going to be what your JAR file contains and it's what other programs could talk with.  Expand some folders in the project pane (there are folder icons listed in it) until you see the "src" folder.  Then right click on that and select New > Class.

• Another monstrosity of text fields and controls appears!  The Eclipse UI uses ERROR ATTACK!  You used FILL OUT THE NAME FIELD attack!  Nicely done, the Eclipse UI yielded its Finish button... but what's that?  Eclipse UI continues to thrash!  Eclipse UI uses ERROR ATTACK!  It's SUPER ANNOYING!

• It's almost as if you did something wrong just by opening a freakin' window.  You can get rid of that error message and its high-and-mighty caution sign by filling in the Package field with something in a format that you wouldn't know about unless someone told you (nothing like some pain for the newbies to give you that frat initiation feeling, COM.WELCOME.TO.PROGRAMMING.NEWBIE.).   Fill it in with something like "com.yourpackagenamehere".  As you can see from the screenshot below, I filled it out with "com.shoulddoitforme", because it should.  Also, a class can have a main(...) method in it, usually if it's the entry point for your application.  Don't know what that means? I clicked it, but don't worry about it.  At least now you can click the Finish button without a warning in yo' face.

• Congratulations, you now have a Java class.  This'll contain the function that you can call from something using your .JAR file, supposedly.

• Now you can write in whatever awesome functionality your JAR file will contain.  At least, that's what I think you can do.  I've never done this before, so... let's find out!  Here's a method that inquires about your well-being.  You can write it too, I guess, and hope it works later.

• Press CMD-S to save and let's see if we can create a JAR out of this.  New territory for me here, too, folks!

4. Make the JAR file! 

• Don't click it, but some link with a pretty good list but a lot of words (hey, I know I'm not the most curt communicator in this posting; it's "style") tells you how to make the JAR file in Eclipse.  Here's the visual version: start with File > Export.

• An interface that asks you about a destination appears.  Ignore the words on it, it actually just wants you to select Java > JAR file.  The actual "destination" is later, so click Next.

• I don't actually know what selections to make with regards to the export, but you can see what I chose below.  The JAR file location has to be specified.  I also checked "Export Java source files and resources", though I'm not sure how that's different than a JAR that doesn't do so.  Specify the destination and click Finish.

• Congratulations!  You made a JAR file from scratch in 4 easy convoluted steps!

The reason I'm discovering this is because I need to get a JAR into Unity.  I don't know how to do that with ours, so creating a JAR from scratch -- where I know everything about its creation -- seems like a good start.  Now I can use this JAR against the instructions for getting it into Unity, which involves all sorts of fun JNI nonsense, and then repeat that process with the "real" JAR file that I want to use in Unity.

That's how you make a JAR, folks, but I don't know how good it'll be for practical usage.  Will it work with my Unity case?  I'll find out!  Do you already know?  Let other people know in the comments and chime in on whether or not something is wrong with the steps here!

Immersion Dissonance & How I Wrote My D&D Adventure

You've experienced what I'm about to describe below.  Though I originally coined the term based on experiences in games, the concept of "immersion dissonance" can be found in many confused layers of general software all over the world.  Oftentimes, it's the result of an ill-assigned author.

First, we'll explore a real-life example of immersion dissonance.  Then, we'll move on to my approach for a completely original Dungeons & Dragons adventure.  Finally, you'll see how the approach prioritizes a meaningful and positive end-user experience over unpleasant mechanics by directly addressing immersion dissonance in Dungeons & Dragons.

World of Warcraft and the Twink Problem

World of Warcraft is a popular game where the user plays the role of a denizen in a fantasy world.  Progress and power are marked by numerical levels that eventually reach an upper bound.  Designers create meaningful and emphasized activities of warfare and conquest for players at that upper bound; this is known as "end-game".  The activities of warfare and conquest previous to those are known as "leveling".

The occasional community-organized fireworks show
was also good fun if you happened to play on
the best server in the world. No levels for that, though!

As the image above shows, there are activities available outside of the activities of warfare and conquest designed for the game. These do not contribute to the progress of the character toward the upper bound of power.

One such circumvention used the following mechanics available before a certain patch changed them.

• Players could join a "battleground" -- a space where players could engage in directives-driven warfare against other players -- based on level brackets.  As an example, only players with characters at levels 10 through 19 could join the 10-19 bracket.
• Battlegrounds did not contribute to the level of a character.

Some players would progress to the maximum level allowed in a bracket and maximize certain powers on that character as allowed by the system.  In this way, the player was allowed the enjoyment of engaging in warfare against other players in a consistent manner and without having to progress their character to an upper bound that changed with game expansions.

Players' characters used in this manner are called "twinks".

A negative and popular side effect, however, was the grief experienced by players that did not maximize powers or levels on their characters within each battleground level bracket.  This problem would be resolved with several side effects -- one of which was the loss of my interest in the game.

A Multi-Layered Implementation

The negative experiences caused by twinks would be resolved by changing the aforementioned battleground mechanics.

• Players could join a battleground based on level brackets.
• Battlegrounds would now contribute to the level of a character.
• Players could join a battleground based on level brackets that is separate from the common, default battleground.
• This separate battleground would not contribute to the level of a character.
• This separate battleground would only be accessible if the player executed a set of actions to enable access to it.

The previous behavior of joining battlegrounds would result in the new battleground mechanics that contributed toward character level.  In order to activate the access to the battleground that did not contribute toward character level, the player had to execute the following actions.

1. Log in to the game on the character which will be participating in the non-default battleground.
2. Acquire ten gold (gold are units of in-game currency for World of Warcraft).
3. Discover, find, and then speak to an in-game NPC to pay the ten gold.
4. Attempt to join a battleground by using the same interface options available previous to the twink-solving patch.

Switching between the two battlegrounds requires the player to execute the above process each time.

Pay Gold to Change Matchmaking: The Elimination of a Community

The steps involve actions within and without the World of Warcraft game.

Step 1

• involves the typical interface options and in-game actions required before the twink-solving patch; no change.

Step 2

• involves in-game actions to accumulate in-game currency, which often (if not always) coincide with leveling; at least one character must advance to the point of obtaining that currency amount, which means lower-level battleground options are now inaccessible to new players that might have explored the secondary battleground.
• affects the character's in-game wallet.

Step 3

• involves searching for a story-irrelevant NPC's information on an internet site such as Google or wowhead.
• involves positioning the character at the NPC's location within the game world.
• involves the loss of ten in-game currency from the character's in-game wallet.
• affects the matchmaking system that places the character in a back-end queue.
• affects the character's in-game wallet.

Step 4

• involves the typical interface options and in-game actions required before the twink-solving patch; no change.

Lok'tar ogar, rogue. 
Set my graphics settings to High
and turn off my experience, please.

Although the intention and end result expected from the end-user are the same as before the twink-solving patch, the implementation ultimately uses in-game means to affect the matchmaking system -- a feature outside of the game world with which the player never interacts.  Their immersion in the game is disturbed in order to affect features and systems that have nothing to do with the game world; the solution is dissonant to the immersion of the player.  This confusion of features and user experience layers is what I call "immersion dissonance".

If it were PacMan, this would be akin to changing the volume by eating three ghosts after consuming two big pellets on the right side of the screen.

With this multi-layered solution, dwindling twinks -- a sub-community within the World of Warcraft playerbase -- banded together on one "battleground group" (a collection of servers which funneled players to the same battleground queue).  Though I suspect that they eventually vanished due to the weak numbers of players queuing for the experience-less battlegrounds, I cannot say for certain since I was one of the players that got tired of the aforementioned failures to find matches.  Instead, I played League of Legends, a game that readily offered gameplay against other players in a consistent manner and without having to progress toward an upper bound that changes with game expansions.

Unlike World of Warcraft, the barrier between my entry to the product and my desired gameplay experience was exactly what it should be: user interface options such as buttons to determine game types.   A superior solution for World of Warcraft would have been listed alongside the Graphics and Sound settings, or would have appeared in a secondary "XP" and "NON-XP" list when selecting the battleground to join.

A Dungeons & Dragons Adventure Around Immersion Dissonance

If you've ever gone through the game design workshop at GDC, you'll easily understand the use of MDA concepts to procedurally create a D&D experience that avoids the many pitfalls of immersion dissonance within D&D.  As a notorious roleplayer but first-time DM, this was a major priority when creating my adventure.

For the rest of you, the MDA framework is an approach to game design that describes a game as a collection of Mechanics, Dynamics, and "Aesthetics".  With a little practice, you can break down any game into these components and methodically tweak each layer to impact the others.  This is not directly a breakdown into those layers, but my focus was on these points for D&D.

• Numbers from dice rolls determine success or failure.
• Success or failure in encounters determine XP and Gold rewards, which -- at a macrocosmic level -- determine the fulfillment of the character.
• Players determine the actions that their characters execute within the game world, without bounds or reason, similar to the actions possible in real life.
• Actions by characters determine the entry into encounters.

I decided my group would not simply say things like "I do a perception roll" to arbitrarily overcome some unintuitive skill challenge. The above mechanics must not trump the story and "reality" of my players; I had to ensure that the dynamics would maintain that hierarchy.

Dumb Engineer Solution

If you look at the materials provided by Wizards of the Coast, you'll read tons of text about what players should do within campaigns and how the next paragraph will be reached.   For a game that often has annoyingly imaginative fools like me, this seems far too linear; the unexpected actions of any players had to be somehow predicted.

So, as can be done with any problem, I drew a flow chart.

What do you mean engineers have no empathy?
See, I reduced your bad life choice to this node right here,
pretty thorough -- I mean considerate -- if you ask me!

Plotting out my points of interests in nodes offered lots of flexibility; flow charts are scalable.  There's a yes or no determinant for everything, which means that all the actions outside of that can be artfully guided back to answering a very binary question.   If you notice lots of erasing, strikethroughs, and dotted lines, it's because new actions and activities could be added or removed at a whim before -- and even during! -- the game.

If you want to follow along, the beginning is at a ritual being proposed for the group.  Though this leads to a node where a new (the usual DM's) character is introduced, his introduction actually ended up being scattered.  The party ended up making their decisions before the new character was introduced to them, and searching for the ritual components led them to that introduction.  Reasonably and contextually, the driving NPC inquired: was the new player in for the ritual, just as the other players had decided to be?

These nodes are all in-game actions and elements; they're all story.  The lines ended up being the aforementioned mechanics; what did players choose to do?  Did they decide to suddenly blast a hole in the roof?  Does that ruin a DM's pace?  No: all that matters in the story is whether or not that No or Yes path could be taken.  Cleanly abstracting the story out, separate from the mechanics, allowed those mechanics to powerfully serve as the entry and exit points to the next part of the story.

My favorite part is the scalable nature of flow charts.  Are players using the mechanics to spend a while between nodes?  Great!  That means they're enjoying themselves and immersing themselves in the gameplay; no problems with flow and you have the opportunity to better portray the environment, culture, and universe around them.  I had two new characters show up to this game instead of the expected one; adding them was no problem between nodes.  All that mattered was the pivotal decision: in?  Yes or no?  Regardless of which path was chosen, they all eventually led to the important story-pushing node.  In fact, my players ended up spending a lot of time fooling around but I was able to cut nodes from the game thanks to the scalable nature of a flow chart.

-------

Want to read more?  Please let me know and I'll better format this as a 3-piece series.  If not, then the message is clear: readers don't find value in my writing more, so I won't waste my time!

Specifically, I can talk about handling skill challenges for better player immersion and how my most celebrated game mechanics ended up being created on the fly. 

-------

Observation: Signing Up is a Thing of the Past

This is a quick overview of how people behaved when presented with a beta list signup versus social media buttons.

Intention: Measuring Interest

Don't laugh, but I've been having fun trying to predict the actions of the investors on Shark Tank, a show where people pitch their business ideas.  Despite its seemingly mass-media appeal, I think I've gleaned something useful

Below are the things that seem to matter most for negotiating a deal with or impacting the behavior of an investor.

• Sales
• Sales
• Sales

If your idea or product is not at the point of sales yet, you need some hard numbers that could easily turn into sales.  Without that, your ideas are as worthless as any other unvalidated opinion.

When I turned on the tracking for http://liederboard.com, I was surprised at the high amount of traffic.  At the time of this writing, we're nearing 10k hits in a little over a month's time.  Taking a tip from Dropbox's story in Eric Ries's "The Lean Startup", I decided that a more substantial metric could be obtained through beta signups.

Beta Signups

Around July 11th, a beta signup page was implemented in my project.  Here are the figures around the beta signups today.

• 6 signups total
• 1 was a test entry from me
• 5 were from individuals that I directly asked to sign up if they wanted to show their interest

That means that 0 out of at least 3,000+ hits over July 11th - July 22nd signed up purely due to the feature's existence.  Some people would sign up if I asked them to.

Conclusion: there is a strong indication that users are not willing to use forms to sign up for something of interest, regardless of whether interest exists.  A conclusion cannot be made about actual interest.

Social Media Buttons

Observing the failure in the strategy, I implemented social media buttons on the website.  On its first day, the measurable "interest" matched and exceeded the figures portrayed through the beta signup -- don't get too excited as not even double digits were required to accomplish that.

With no announcement, post, or any real attempts to propagate the feature beyond natural interaction and testing, the social media buttons stand with these figures.

There were over 1,000 hits on that first day, but that may have been due to repetitive testing and iteration.

Okay, So How Do I Do It?

My most effective method for the How To of social media buttons was to search on Google.  Seriously, if you enter "Google+ button" or "Twitter button", you will usually see an official page that will give you the code to paste into your HTML.  The buttons themselves work in javascript.

Here are the pages I used.

Google+ Button

https://developers.google.com/+/plugins/+1button/

Twitter Button

http://twitter.com/about/resources/buttons

Facebook Button

http://developers.facebook.com/docs/reference/plugins/like/

LinkedIn Button

Note that if you want to point to a company page, you have to have a company page on LinkedIn.  That deterred me from implementing the LinkedIn button, but the page below has a "share" button that I might also incorporate later.

http://developer.linkedin.com/plugins/share-plugin-generator

Pinterest Button

Scroll past the useless information at the top which will otherwise make you mistake it for an FAQ.

http://pinterest.com/about/goodies/

Reddit Button

http://www.reddit.com/r/dayz/buttons/

Share the Wealth!

Hope that helps you gauge effectively.  Don't forget to +1/Like/Tweet/etc. my project!  If you're a redditor (boo to 9gag), imagine all the karma you'll get by submitting my project to a subreddit like music, musicians, or sheetmusicexchange!

Analysis for a Gameplay-Based Lore Framework

This segment was taken from another entry due to the length of that entry.  Here, you will find the analysis that leads to the lore framework discussed in that original entry.

League of Legends is Gameplay-Based

Like Monopoly, the most important thing in League of Legends is a gameplay that is meant to be adopted by a mass market (and equal to or greater than that which played DotA).  Lore is secondary to gameplay, so we can consider League of Legends to be a gameplay-based game.

Let's put on our game/user experience designer hats to understand the gameplay elements that will form the lore framework -- just like we did at a high level with the gameplay-based Monopoly lore framework.

- A user selects the champion they will control in the match.
- The 4 teammates and 5 enemy summoners select their own champions for the match.
- The match begins with all the users' selected champions at a spawn location.
- The spawn location provides a source of modifiers for champion stats or abilities.
- The spawn location provides restoration of a champion so they may maximize the time until which they are next forced back by the enemy.
- A set of minions stream out at regular intervals from the victory condition node to the enemy's victory condition node.
- Enemy users, obstacles, and enemy minions prevent minions from reaching the victory condition node.
- A team wins when their users overcome the obstacles and enemy users such that the enemy's victory condition node is reached.

Laying out the Static Elements of League of Legends

Now let's put on our creative director hats (we're creative directors that happen to understand game, UX, and technical design because we attended many GDC parties, okay?).  If you look at the above, it sounds very dry and mechanical -- which it should, because those awesome game designers know how to break down games to their bare mechanics.

It's your job to find the resultant lore framework elements and give those mechanics life and purpose.  Here's where the game stands with the description/chat from your designer -- as well as from playing the game yourself.

Minions = Minions

Spawn Location = "Fountain"

Victory Condition Node = "Nexus"

Source of Modifiers = "Item Shop"

Modifiers = "Items"

Obstacles = "Towers"

Most of the time,
it's the same things
every time.

You also understand that the macrocosmic unit of experience for a user is a "match".

The above are static because they are the same across all matches.  You might be thinking of a few other static elements, such as "the jungle" or champion death.  They were left out for brevity and because they are also unchanging across matches; more static stuff you can trust the excited writers on your team to tackle.

There are some remaining terms, though...

Users = Summoners

Champions = Characters released over time

These are dynamic across matches and real time, with champions being limited in the sense that they are always the same from a selection made by the user from a pool of champions available at that time.

These could be the opportunities for large-scale immersion beyond the scope of a single match experience.

Creating An Immersive Experience in League of Legends

The content described here in absolutely no way previews, hints, nor in any way whatsoever represents any development going on at any of my past employers' studios.  This is an original direction and vision for lore and game IP that is based only on my experience as a video game player; it is not based on any specific content or methods of development experienced at any studio.

One of the reasons I've been a League of Legends fan since the beta was to see how the game realized or failed the potential I saw in it.  The game, like many others, offers a fantastic opportunity for lore, story-telling, and immersion in the multiplayer space.

Since I'm not currently working for its developer or any competitors, I can finally write this out for fellow lore dorks dissatisfied with the video game industry's trend of story-telling.

A Game's Lore Framework

Because I get paid to do engineering and not writing, I've come to call this a "framework".  A lore framework is the space within which stories and events must be told to make sense of or contribute to the overall purpose or functioning of the universe.  This overall functioning is usually based on a creative director's vision or by the successful past works in the universe.

A story about how an orc and a human got along
despite a game where orcs were at war against humans.

In WarCraft III, a common lore element is redemption.  Redemption and internal conflict are a part of the most notable plots and characters in the WarCraft lore framework.  A harmony with the framework exists in WarCraft III when Thrall the orc makes nice with Jaina Proudmoore the human daughter of a naval fleet commander, despite their pasts, for a greater good.  A conflict with the framework exists in World of Warcraft when the player can in no way support nor interact with the opposite faction, because this flies directly against the elements of redemption and internal conflict.

Can I be like Thrall and Jaina
or does that quest bang mean "no"?

The League of Legends Lore Framework

A very interesting (and awesome) lore opportunity arises with the DotA-based game.  On launch day, there are no known actors.  There is no universe; there is a map.  The lore is haphazard and champion-based, with the world map only being relevant because it represents a champion's origins. With a few retcons to rectify some haphazard origins, this trend would pave a path that the game continues down -- to its 100th champion Jayce -- today.

Let's look at a successful, practical parallel to give us some perspective.

A Similar Lore Framework's Results

Monopoly is a multiplayer game with a single board.  Based on chance, players move to points of interest that provide opportunities or immediate consequences for their money.  The player with the most money is considered to be winning.

No one knows what Baltic Avenue is, what it looks like, or its history.  As people play, however, they naturally infer that it is something like a poor residential area or slum compared to Park Place and a personal connection to the landscape is formed based on nothing other than the gameplay.  Go ahead and bet on Baltic Avenue's history not being in the manual; even if it were, what would that matter?   Few people read the manual anyway -- much like mainstream players do not read game-external publications that are sometimes in no way relevant to its game and, more a fault of the system than of the authors, eventually are deemed non-successes by executives or senior management.

Thanks to the accessible and natural immersion of the player in the game mechanics, consumers that play Monopoly might immediately understand "That's the Boardwalk of Los Angeles" or "Don't go too fast, you'll go to jail.".  Furthermore, this identifies the consumer as a fellow player of what might be considered a subculture, reinforcing something of a community for the product.  Finally, there is a positive regard for fellow consumers of Monopoly simply due to its sheer popularity: if you don't get those references, you might be considered uncultured!

This is where you live, right? 
Just under here, Mr. I've-Never-Heard-of-Monopoly?

Thanks to that same immersion, developers of games easily draw connections between the original Monopoly landscape and that of any other world -- all by just honoring the lore framework established by the game's mechanics.

It's to the point that you could probably come up with a Monopoly variation right now.  Is there one for Pokemon, My Little Pony, or tech companies?  If you understand your own universe well enough, chances are that one indeed exists right now -- in your head, at least.

Analysis of the Gameplay Basis

For the sake of brevity, this segment has been posted to its own entry.

A Summoner-Based Lore Framework

Riot Games deserves a shout out for something it's done since its early days.

In pretty much every single forum post, their employees address their users as "summoners".  By doing this, users become attached to the role they play in the game and are unified regardless of currencies or tenure.

I don't care what team I'm on;
in my head
my robes are dark red.

Sadly, that's where this attachment ends.

Let's take advantage of that opportunity (how many game companies before Riot referred to their users as their in-game equivalents?) to further strengthen the role of summoners in the League of Legends IP.  As we roll out the lore framework for the game, summoners will be the main focus.  As a bit of a (common sense) bonus, this focus also embraces the Riot Games mission statement.

- A "Summoner" is an individual that summons champions. [Gameplay equivalent of user]
- Summoners rarely, if ever, take part in combat themselves. [Gameplay]
- Summoners mostly, if not always, interact with champions through summoning. [Gameplay, UX]
- A huge population of summoners exists. [Technical, Gameplay, UX]
- A huge number of matches exist. [Technical, UX]
- Champions have strong relationships with or against city-states in the game world, Valoran. [Gameplay]
- Champions have strong personalities conveyed through splash art, voice-overs, and in-game visual presence (animations, models, etc.). [Gameplay]
- Summoners summon champions at the The Institute of War. [Pre-existing Lore]
- The Institute of War was created to moderate war in the interest of environmental stability. [Pre-existing Lore]

Actionable Ideas from Our Lore Framework

With our understanding of our lore framework, even laying out those few elements may inspire some ideas.  It's time to meet with our team and discuss feasible possibilities, then make one of them a reality.

A Guiding Element from the Lore Framework

After sharing and explaining your list of elements with the team, you hit up the whiteboard and scrawl the conclusion that is going to guide them in satisfying the common lore dork like you.

 

In the League of Legends, you will immerse your players by having champion selections affect the in-game world.  You ask your engineering gal to get data on champion usage over the last week or two, look at who was the most popular and most victorious champion, and tell your artist what their city-state is all about.

Implementation

1. On the Sunday night of every two weeks, get champion usage data from the last two weeks, ranked from most used to least used.  Iterate toward multiple factors and observe what happens, but we can simply start off with the following.
- champion name
- percentage/number for selection of that champion
- percentage/number of wins on that champion
- percentage/number of losses on that champion

2. On Monday, go over the numbers with your team and decide which city-state and their champion can be considered "most victorious" over that time period.  Reasons can be arbitrary, but document them; you'll be sharing those reasons with summoners as a record-keeper of the Institute of War's history.  Also document that victorious city-state; this is the beginning of the known history of the League of Legends.

3. After deciding which city-state is "most victorious", complete 2-week development on the following.  At the minimum, have an artist do the first.  Iterate to see what people actually respond to and use, and discontinue any features or methods that have diminishing returns.
- [1 junior-mid artist, 1-2 weeks] A summoner icon representing that most victorious city-state.
- [Agreement from Marketing and Design, 1 Engineer] Change of price of champions from that most victorious city-state to the maximum in the range (6300 IP at this time), and change of price of champions from least-victorious city-states to minimum in the range.
- [Web developers, 1 Community resource or Writer] A website containing the most victorious city states over time, the most victorious champion
- [1 Community resource or Writer] A forum post reporting the victorious city-state thanks to the summoners that supported their champions, explaining the criteria -- and whether or not they've changed -- as if from a record-keeper at the Institute of War.  Communication that the city-state will be rewarding the top summoners contributing to their glory; perhaps even a listing of those summoner names for notoriety.
- [1 Data Specialist and a Community resource or Writer] A list of the top X% of summoners that won with the city state champion -- the ones essentially responsible for the city-state's "victory" -- and an email to those summoners with a code for their city-state summoner icon.
- [?] City-state skin?  Forum avatar?  Voice-over that treats summoners with particular respect because of their contributions to the city-state? 

4.  At the end of the 2 weeks of development, deploy the summoner icon, send out the emails, post up the forum posts or website.

Maintenance, Measurement & Iteration

Congratulations!  You've used existing technology to create an immersive experience in the League of Legends universe!  That's the claim, anyway.  It's time to see whether or not your strategy is working.

Testing the Hypothesis

Among our leap-of-faith assumptions is that players want an immersive experience in League of Legends.  The advantage of starting small (with a single summoner icon, email, and forum post, for example) is an easily gauged answer within a matter of weeks. 

If that top percentage of summoners all redeem the codes emailed to them and set their summoner icons to that city-state icon, it is a strong indicator that they care about such tokens toward immersion.  If the forum consists of pages of posts from players wondering why they did not receive a summoner icon, it is a strong indicator that they care about such immersion.

If player match histories or the bi-weekly data numbers suddenly show a huge shift in champion selection that reflects city-state influence, you are well on the way to giving "Influence Points" and the "DEMACIA" battle call a whole lot more meaning.

The Future

Using the implementation above, the most important city-states will get summoner icon work that must only be done once per city-state.  Eventually, if all city-states are represented, all city-states will get summoner icon work done that does not require further investment.  The worst-case cost of this work is linearly proportional to the number of city-states that exist in the game.

Likewise, by exercising the strategy from this lore framework, champion developments are potentially funneled to the number of city-states as well.   Instead of future development scaling with the number of champions, costs are based on interactions with a summoner and based on the single city-state relationships of the champion being considered for development.

With the eventual completion of development for all city-states, summoners can start receiving their rewards directly after the period of judgment.  There's no more need to develop a Noxus icon three months in; it's already there.

Hand out the benefits to the elite % of summoners on the day of, or soon after, the judgment period.  Suddenly everyone's participation in the League of Legends becomes a conversation of champions, city-states, and lore -- all with the summoners at the root of those conclusions.

Measuring Up to Other Games

There's no reason games can't achieve the lowest common denominator.
(Comic from penny-arcade.com)

This is another entry in and of itself, but a good lore framework will provide elements to strengthen three major aspects of a game's universe.

- A macroscopic immersion in the game universe.
- A microscopic immersion in the game world.
- Story-telling and development around the character.

This implementation offers the player a macroscopic enjoyment by making each match (the microscopic experience) relevance throughout League of Legends history.  There is also a small-scoped impact in particular strategies, such as if IP prices change around summoner victories for a city-state.  Finally, the summoner gets to feel as if he or she is being rewarded for a devotion to a set of champions and a distinct sense of identity is formed that positively reinforces that identity and the identity of other summoners within League of Legends.

Conflicts

It is possible that selection of champions will be considered disruptive to game design.  The composition of teams may change, custom games may be started so summoners can select champions that earn a city-state's favor, or the already-existing behavior around champion selection might change in a way we don't foresee.

Good.

Auction House Feature Breakdown

This segment was taken out of this piece on MMOs for the sake of readability.

I'll analyze the auction house ("broker") feature because -- to say it diplomatically -- there's a reason SW:TOR now has to patch up their "auction house" in their next few patches (if they haven't already).

Use cases for the broker:
- Player wants to sell an item they possess.
- Player wants to purchase an item they need.

My expectation is for production to understand and own the implications of the use cases in the context of their particular games. Here, we'll look at the first case generally, avoiding going too far into game-specific minutiae.

In Aion, "Player wants to sell an item they possess" involves deciding the price and transferring the item to the broker system, which really means...

1. Player travels to the broker NPC to interact with it.
   
2. The interaction brings up some UI, but the player doesn't really care because...
   
3. ... the player right-clicks on their item that they want to sell. The UI populates the search field with their right-clicked item.
4. The user presses Enter or clicks the Search button to see all current listings.
5. The player now knows what their item is worth. This is an intention!
   

Compare this against (disclaimer: what I remember of) the equivalent SW:TOR Galactic Market use case.

1. Player travels to the Galactic Market terminal to interact with it.
2. The interaction brings up a UI.
3. The player looks at the drop-down labeled "Required" to understand the drop-down selections.
4. The player chooses the drop-down selection that seems most appropriate for the item.
5. The player hits search that returns the listings of that drop-down categorization at that time -- but to enable the Search textbox.
6. The player types the name of their item into the Search textbox.
7. The player presses Search to search for listings that correspond to their item.
8. If no listings are found, the player might go back to step 3 to make a different guess at categorization. If listings are found, the player now knows what their item was worth at the time they searched for the categorization*!

The First Google Offers Experience

I've been called a Google enthusiast. Throughout my time as a Google fan, though, I don't immediately recall a huge push for Google Offers. Today's is the first, executed through Starbucks as a $5 for $10 offer that also donates $3 to American jobs on Google's behalf.

Jobs, drinks, and electronic payment innovation offered today.

Let's consider the hard, prospective gains for each involved party.

• Starbucks stands to get more business from Google users.
  
• Google gets some attention to its Google Offers product and Google Wallet product.
• I (the common consumer) get five bucks toward Starbucks, as well as -- if you're into this sort of thing -- the feeling of charity for making Google give "American jobs" $3.

The Hope and General Conclusion

Today's experience was generally negative and could be considered a failure. There are many opportunities for this experience to be improved.

As soon as this offer was revealed, my hope was for an innovation in electronic offers and payments. I want to see ideas, which could especially (or only?) come from companies like Google, that eventually replace my wallet -- it's what they're trying to do anyway, and I'm excited! Could my shopping become as easy as installing an app on my phone and tablet from my desktop?

Not yet.

The User Experience

Let's break down one user's experience to clarify the problems and focus future improvement possibilities.

1. The consumer receives an email, from the My Starbucks Rewards program, to inform them of the offer. A "Sign Up for Google Offers" button is prominent in the email.
   
2. The consumer receives an email, from Google Offers, to inform them of the offer. A "VIEW AND BUY" button is prominent, and a relatively clean bullet list reveals details.
3. The consumer receives an email, from Google Wallet, to inform them of the offer. A "Sign Up for Google Offers" button is prominent in the email.
4. The consumer follows any of the aforementioned buttons, links, to arrive at the same page.
5. The user clicks the button to purchase the offer to have Google Wallet load their payment information -- if it exists. I'd love to hear from anyone who didn't have Google Wallet payment information stored.
6. The user confirms the purchase to complete the transaction.
   
7. Google Offers sends the user an email receipt to inform them of the transaction.
8. I don't know what to do right now. The user attempts to find information to obtain the goods purchased.
9. The user sees a link to the Google Offers app advertised on the purchase confirmation page (not the email), which says the mobile device can be shown to the retailer -- perfect! -- and downloads the app. Momentary confusion: I have the Google Shopper app; is that different? Answer: apparently, yes.
   
10. The user physically makes a trip to a Starbucks to find out more information and purchase a drink with the purchased offer.
    
11. The user shows the Starbucks employee the Google Offers screen to obtain the purchased goods, because the app says "Show this screen to retailer to redeem your offer.". The Starbucks employee does not know how to make use of this.
12. The Starbucks employees try to find out how to make use of the purchased offer. Specifically, they ask other employees, try to interact with the app, and call someone off-site to find out how to make use of the offer.
    
13. The user opens up the web browser to navigate to the website listed in the app.
14. The user navigates through all the required UI actions to get to their purchased offer under "My Offers".
15. The user follows any UI component that could possibly lead to a resolution, to possibly reach a resolution. It works and a UPC bar appears.
16. The Starbucks employee scans the UPC bar and adds $10 to the consumer's pre-existing, physical Starbucks card.
    

The User Intention

As a consumer, the primary intention was to get $10 for $5. After that, my secondary intention was to get a drink.

I didn't really care which services that involved -- I trust Google, perhaps more than I should. I'm already signed up for many of their services, even when some are not useful.

Sixteen outlined steps is huge. If you had the patience to get through it all, you can see that there's a lot that lies outside of the user intention. We can distill the process according to the user intentions.

Steps 1-4: Information.

Google partnered with Starbucks to give me $10 if I spend $5? Okay, sure -- I want that, but the following doesn't tell me how to get it.

Given the above, describe to me how I get my $10 for $5.

Steps 5-11: User Actions toward Intention.

What do I need to do to get my $10 for $5? Google and Starbucks did not provide the actions required from their consumers. The users could have been informed of the expected process, upfront. Here is what Google developers seem to have expected.

1. Purchase the offer from Google Offers to take advantage of the offer.
2. Navigate to google.com/offers, click the "My Offers" button, navigate to the Starbucks offer, and click the "Redeem" button to reach a page with a UPC bar.
3. Present this UPC bar to a Starbucks employee to complete the transaction, either by printing out the page, or by navigating to this page on your mobile device.
   

Had this process been communicated to me from the very start, I could not so easily consider this Google Offers attempt a failure.

Steps 12-16: Delivery of Goods According to User Intention.

I expect a Starbucks employee to actually credit me with my purchased offer's goods. Once we all figured out how to do that, this delivery became possible.

The Payment Innovation Hope: A Successful Example

As stated, I'm excited to see the implementation of ideas that streamline the process of payment. Let's look at Eventbrite's implementation, which has achieved the following, simply because of graceful user interaction/experience design.

1. Made me a user of Eventbrite where I would usually not be an Eventbrite -- or any event-organization service -- user.
   
2. Streamlined the acts of making an RSVP, payment for event tickets, and attendance.

Just yesterday, I attended a screening of Indie Game: The Movie, at a 4-plex in Santa Monic. Here was how the process went.

1. I receive an email, from Eventbrite, to inform me that a viewing will happen. Now that I think about it, I'm not exactly sure how they knew to email me -- possibly from GDC -- but that's okay since they correctly targeted an interested consumer.
   
2. I see additional incentives via twitter, by sheer coincidence during my normal twitter consumption.
   
3. I follow the link from the Eventbrite email to purchase tickets.
4. I select the number of tickets, enter payment information (because I don't want to link my PayPal account), to complete my transaction.
5. At the door, I show them my Eventbrite app, which immediately displays the barcode to allow me entry. The app was already downloaded and installed.
   

Note the closer mapping of information, user action, and delivery of goods. Especially consider that the hurdles are user-created -- I chose to consider additional incentives and look in two different mediums (email and twitter). It was not forced upon me by the process.

Let's look at my GDC experience with Eventbrite, which really made me an Eventbrite user.

1. User "purchases" GDC party tickets from Eventbrite at $0.00, to gain entry to future party. There are many parties which do this.
2. User forgets printed tickets. Unintended user action.
3. User looks up confirmation email on mobile device, because it has the QR code in it, to show bouncer and gain entry to party. User sees there is an app.
   
4. User downloads app to satisfy curiosity.
   
5. User loads QR code from app to show bouncer and gain entry to party.

Again, we see a closer mapping between the user intention -- getting entry to a party -- and the minimized process to reach that. Complications are created by the user.

Eventbrite deserves further commendation because I was never at risk despite my own complications. Without their downloaded app, my QR code was still in my confirmation ticket. Compare that with today's experience for Google Offers, where my email confirmation only has a link to a website, which itself has a link to the actual purchased goods.

Three Recommended Future Steps

I want to see innovation on my payments, services, and delivery of purchased physical and virtual goods. Here's how I would make that happen if I had Google's development power.

1. Clarify and communicate the process, with consideration for the user intention. Validation/results: user can correctly inform the developer of how to satisfy their intention through the developed system.
2. Minimize the process, maximize the opportunity for intention satisfaction. Despite the user knowing how to reach their goal, the way to do that can still suck. You can steal Eventbrite's practices directly (why not give me my UPC code in my confirmation email?), or try to minimize the process in a new way -- just iterate with your developers' ideas on how to get better than the process from 1, while always making sure the user can recite it back to you without your having to teach them. Validation/results: user can achieve the same intention as 1 in a more efficient manner, as measured by time, interaction, steps in process, or whatever is relevant to your project.
   
3. Reduce external confusion. With some solid process available, we can now expand into reducing the confusion outside of that. Users don't know why Shopper is different from Offers right now. Users don't know why Offers isn't showing the bar code that the Google Offers website does show. Eliminate these questions: choose a medium (I vote for the mobile app, personally) and synchronize all mediums with that one as the primary. Validation/results: you can delete the non-primary services while users know they can achieve their intention with that primary, single medium.