3. In interface builder, right-click your ScrollView (not the file owner) and hook the delegate property up to File's Owner. This involves drag-and-dropping from the circle next to "delegate" that shows up in the drop-down when you right click the scroll view.

4. Click the "Show the Size inspector" tab (it looks like a ruler and is next to a bunch of cutesy icons like a paper, squiggly lines in a dark box, a newspaper, a belt, and an arrow). Under Scroll View Size -> Content Insets, set the "Bottom" field to a number larger than your current size. This change makes it so the user can scroll to that size.

The other fields for "Content Insets" would probably have the same impact when changed, I imagine.

Saturday, April 13, 2013

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).

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.

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!

Monday, February 4, 2013

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.

Log in to the game on the character which will be participating in the non-default battleground.

Acquire ten gold (gold are units of in-game currency for World of Warcraft).

Discover, find, and then speak to an in-game NPC to pay the ten gold.

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.