Monday, February 27, 2017

Gameplay Is Dum

This article is going to be a rip-off of this wonderful article by the indomitable game theorist Alex Kierkegaard, but applied in greater detail to the tabletop space.  So go read that, learn from it, and report back when finished.

...

You finished?  Great!  Let's get started.

'Gameplay' is one of my least favorite words ever.  Now typically when I don't like something about games lingo I just whine incessantly and curse like a drunk, but for this particular subject I'm going to try and approach it with as much clarity and respect as I can muster.  Why the gravity?  Because I firmly believe the word 'gameplay' damages people's abilities to have effective conversations about games and game design, and thus the industry as a whole.  Let me take a few minutes of your precious time to explain myself.

The biggest problem with 'gameplay' is that the word is so exceedingly vague it seems to serve no linguistic function other than putting up a smokescreen in front of an opinion that the person using the word doesn't know how to adequately articulate.  And you know what they say, behind sloppy talking is sloppy thinking.  Did someone say that?  Well I'm saying it now.

I often hear 'gameplay' described as the interaction between the player and the game, or the overall feel of a game while playing it, and I say a word THAT broad is basically useless.  We don't have a word for the overall feel of a movie, or what it's like to read a book, or the way food is to eat, or for any other industry that begets journalistic criticism.  Words like that aren't useful.  We use words like cinematography, editing, narrative, characterization, imagery, taste, texture, substance, etc.  Words that refer to specific elements of the artwork or creation we are expressing an opinion of.  And what do we do when we when we want to make a broad, general statement about those things?  Simple.  We state whether or not WE LIKED IT.

Let's go back to my earlier statement about the word 'gameplay' providing a smokescreen for opinions people don't know how to adequately articulate.  Let's elucidate why this is a problem by imagining this hypothetical conversation:

Tim: How could you not like Game X?
Allen: I don't like the gameplay.

What an obnoxious answer!  What does that even mean?  I see this happen all the time and it drives me flipping crazy.  Here's how a proper conversation should go:

Tim: How could you not like Game X?
Allen: I think it has pacing issues, confusing turn order, obtuse combat, lacks interesting choices, is overly random, and rewards players for playing overly conservatively which doesn't match up well with its theme.

Now regardless of whether or not you agree with Allen, at least you know that he's actually given THOUGHT to his opinion.  At least he made statements that help EXPLAIN why he doesn't like Game X.  Even if all Allen said was "I don't know, I just don't like it" that would be more useful than "I don't like the gameplay" because then at least you'd know that he hasn't given the topic much thought, so it's probably not worth diving into a full conversation with him on it.

Furthermore, every single sentence that uses the word 'gameplay' would make perfect sense without it.  In many cases the sentence would make MORE sense without it.  Here are some examples:

"This game has really fast gameplay."
"This game has really fast pacing."

"This game has confusing gameplay."
"This game's turn order is confusing."

"Top 10 Gameplay Mechanisms"
"Top 10 Game Mechanisms" (Or even just Top 10 Mechanisms, we already know you're talking about board games, bro!)

"I like the theme, but I don't like the gameplay."
"I like the theme, but I don't like the game."

Some of the people I've spoken to at length about this have specifically brought up that last example as a flaw in my argument.  What if you don't like a game's 'gameplay', but you enjoy the theme so much you still enjoy the game?  Doesn't that mean the distinction is important and thus the word is necessary?  I understand where you're coming from, but I'm just not buying it.

First off, is it REALLY possible to like a game's theme SO much that you should say you like a game even though you don't like playing it?  I would argue that you should not.  And if you DO like playing a game despite not liking its 'gameplay', guess what weirdo?  You like the game's 'gameplay' after all, or at least parts of it enough to enjoy sitting through the experience more than once.

Thinking about this mode of thought in context to other art forms reveals what a strange way of thinking it is.  If someone thinks a movie has great characters, but they didn't enjoy watching it; or if they liked the setting of a book, but they didn't enjoy reading it, does it really make sense for these people to say they liked the movie they watched or book they read?  Keep in mind we WATCH movies and READ books, just like we PLAY games.  The capitalized words of course being the way in which we interact with the artwork, therefore being the source of any coherent opinion about it.

To bring the analogy even closer, let's include movie and book terms that take on the function of the word 'gameplay' in games, i.e. its overall feeling.

"I like the movie's characters, but I don't like its watchability."
"I like the book's setting, but I don't like its readability."

How bizarre do those statements sound?  That's what the word 'gameplay' sounds like to me.  There is absolutely nothing wrong with liking a constituent element of a work of art that overall you just didn't care for, trust me you'll be fine.  In fact, in many cases it's necessary!  You see, pointing out the positives and negatives of any work of art is what makes criticism actually useful.

"The movie has great characters, but I still don't really like it."
"The book has a cool setting, but I just don't enjoy reading it."
"The game has a really creative theme, but I don't find it fun to play."

How natural do those statements sound compared to the former ones!  Clear, useful perspectives that words like 'gameplay' seem to do nothing for but obfuscate their intent.

Imagine the confusion if board game critics had separate top 10 lists for their favorite games of the year and the 10 games they thought had the best gameplay:

"Top 10 Games"
"Top 10 Games With The Best Gameplay"

My goodness, it boggles the mind!  Whereas:

"Top 10 Themes"
"Top 10 Art Styles Of The Year"
"Top 10 Twists On Established Mechanisms"

Wow, useful information that makes immediate sense.  Who'd-a thunk it?

I feel like I've made my point, but in the spirit of beating a dead horse, let's continue.  You cannot express anything useful with the word 'gameplay'.  It's impossible.  All it does is add fluff to a conversation and make things take longer than they need.  Let's revisit Tim and Allen for round 2:

Tim: I didn't like this game.
Allen: Why not?
Tim: Its gameplay is all messed up.
Allen: What do you mean?
Tim: Well, let me explain further...

And so on and so forth.  Save us some time, Tim, and just get to the point!

Tim: I didn't like this game.
Allen: Why not?
Tim: Well, the artwork is ugly, the turns take too long, the timing of the card draws makes planning ahead impossible...

See what a pointless little filler word it is?  All it does is wast a lot of everyone's time and energy, but I think the real reason it bothers me as much as it does is that the word seems to be ubiquitously accepted, which I find to be just a disastrous failing of the English language.

When I read Kierkegaard's above article, I immediately began cutting the word out of my writing and speech, and I can state as absolute FACT that I began reaching useful conclusions faster, as if my brain found a programmatic shortcut.  I was no longer wasting time thinking about what was good or bad about a game's 'gameplay', but what was good or bad about the GAME.  It might seem like an insignificant distinction, but I feel it in my bones that eliminating the word from our collective vocabulary would save us all a lot of time and improve the average level of discussion around the hobby exponentially.  If nothing else, it would force people to put more consideration into their thoughts and opinions about the games they are playing.

I'll leave it at that.  Hopefully, my perspective got you thinking a little differently about games and the language we use to discuss them.  I encourage you all to at least make an attempt to remove the word from your lexicon, and just see how it affects your modes of thinking and expression.  Thanks for reading!

Thursday, February 23, 2017

Programmatically Defining Power Grid's Marketplace

Power Grid is one of my all-time favorite games.  In fact, I just played it last weekend!  I won, of course.  But I had an unfair advantage: a deep understanding of the mechanical underpinnings of one of the most crucial systems in the game -- its unpredictable marketplace where players can acquire new power plants each round.

How have I acquired this understanding, you may ask?  It's simple, I was working on this blog post.  Let's get to it.

If we are to represent all of the core functionality of Power Grid's market in Swift, where should we start?  I chose the Resource Type of each of the power plants as my starting point, represented here by an enum:



Sick enum, bro.  Next let's make a struct representing our actual power plants:



Whoa, motherfudger.  That is a doozy.  Looking more closely, you can see that the only stored property of this struct is its number.  Both its resourceType and citiesCanPower properties are computed using switches on that  number.  This makes initializing these PowerPlantCards extremely simple!

Alrighty, we're also going to need some variables to store all these structs we're gonna be messing around with, so lets get those poppin:



Wonderful.  We got three arrays of type PowerPlantCard: one for the actual market where players can select new power plants to add to their collection, another for the future market where players can see power plants that will be available for auction soon, and a third representing a deck where future power plant cards can be drawn from.

We also have a variable to help us keep track of the total amount of cards drawn from this power plant deck.  Why?  Well, a game of Power Grid undergoes a major change on exactly the 35th draw from the power plant deck.  Playing the game, this is represented by an actual card physically placed at the bottom of the deck at the beginning of the game, but because we're in computer world this representative component is strictly unnecessary.

Aight, now lets set up our markets and deck so we can get this game going:



So here we're iterating over a range of numbers (3 and 50, to be exact) and generating powerPlantCards for each of them.  Cards 3-6 go into the actual market, cards 7-10 go into the future market.  The rest are shuffled into the power plant deck, except for card 13 which goes on top.  Any number that pertains to a card that doesn't actually exist in a game of Power Grid just gets iterated over using the continue keyword.

Great, let's take a look at our arrays and check out what they got going on:





Nice shuffling, now we just need some functions to be able to actually do some stuff with our cards.








This function is for removing a power plant from the actual market when a player takes one to add it to their collection.  It checks to make sure the actual market isn't empty, removes the card they select from the array, draws a new card from the deck, and arranges it into the market.  The markets in Power Grid must always be in ascending order with the lowest four ranks in the actual market and the  highest four ranks in the future market.  This makes rearrangement necessary every time a new card is drawn.  Let's take a look at both of these functions:



This function increments the totalDrawnCards variable, checks to see if this is exactly the 35th draw (and sets up the new market if it is), then draws a card and returns it.  The Card must be optional in case the draw deck is empty or the new market is generated on this turn.



This is a meaty function so I made it a bit bigger for your sorry eyes.  We got a new array, we got cards being moved all over the place, we got a sort method, we got functionality to check how the markets need to be arranged.  We got it all.  No questions, please.

At the end of every round of Power Grid the highest value card is put back on the bottom of the deck, so here's that:



Simple enough.  All that's left is our function that gets called by the 35th draw from the draw deck to set up the new market.



Not bad!  Once this function is called, the future market is obliterated for the rest of the game and moves all the power plants to the actual market, which now contains 6 cards instead of the usual 4.

You got all that?  You wanna see it in action?  No prob, here is the market after a round of play in which every player gets a new power plant:




The cards are moved around a bit, and there are four less cards in the deck than before.  But wait!  Haven't we removed five cards?  There are five draw card function calls happening here after all.  Don't forget that the removeHighestPowerPlantCard function also adds a card to the bottom of the deck.  You see that Power Plant Card #31?  If you scroll up and look at the starting state of the market  you can see that was actually the 4th card drawn and added to the market, but since it was the highest ranked card at the end of the round it got moved back to the bottom of the deck.

The last thing to check out is our market state after the 35th card draw.  In our case this happens in the 7th round of play.  Let's check it out:





There you have it.  The future market has tanked (don't gamble on futures, bro) and there are now six cards in the actual market.  The power plant deck now solely consists of cards that have been put at the bottom of the deck by our removeHighestPowerPlantCard function calls.  Just like the real game!

This was a fun challenge, but I happily emerged triumphant in the end!  You see, that's all it takes to be happy, kids.  Tenacity and obsessive fascinations with niche hobbies.  The golden path to any great future!  Thanks for reading!

Friday, February 17, 2017

Programmatically Defining Terra Mystica's Bowls Of Power

I would like to start this article off by acknowledging the vast audience this information will appeal to, so let’s begin by talking about Set collections.

Let’s say we have two Sets: one showing all the people in the universe that are interested in Swift Programming and the other showing all the people in the universe that are interested in European board games.  In Swift these would be written as such:


Now imagine there are thousands and thousands of entries in both of those Sets.  Lets run the intersect method on them to create a new Set that will show us how many people belong to both groups!


Okay, great.  Now let’s take a look inside the new Set we just made and see how big our potential audience is!


Oh, hey Tim. I didn’t know you and I had so much in common.

ANYWAYS, lets get to the topic at hand, The Bowls Of Power mechanism in one of my favorite board games of all-time, Terra Mystica.

The Bowls Of Power are an oft-maligned aspect of the Terra Mystica experience, decried by many as unthematic or fiddly.  This article will do absolutely nothing to dispel those criticisms and instead focus solely on mapping out the mechanism programmatically in the Swift Programming language.  Why, I hear you ask?  Well, I love board games and am interested in designing them, and I also seek to continually strengthen my Swiftiness in every way I can.  I thought this might be a fun way to dig really deeply into game mechanics and also write some code that provides some unique challenges.  Will I come out the other end a better game designer and programmer?  Or am I just wasting my time?  Only time will tell.  Let’s get to it.

In Terra Mystica, The Bowls Of Power represent your clan’s spell-casting ability or magical strength.  A player has three Bowls Of Power that each start with a different amount of Power Tokens inside them.  Let’s define a Power Token as an Integer and our Bowls Of Power as an Array of Integer Arrays: 


As you can see, Bowl #1 starts with 5 Power Tokens, Bowl #2 starts with 7, and Bowl #3 with 0.  I arbitrarily decided that Power Tokens are Integers equal to 1, but it doesn’t really matter because we’re going to be manipulating the amount of elements in the arrays, not the elements themselves.  They could be Integers, Strings, I could make a class or struct called PowerToken, it doesn’t really matter.  Please tell me why I’m stupid in the comments.

Anywho, a little bit more about Power Tokens.  Power Tokens are what you use to cast your spells in Terra Mystica, BUT they can only be used if they are inside Bowl #3.  “But Bowl #3 has no tokens in it!” I hear Tim Allen screaming at his computer monitor.  Ah, that’s where gaining power comes into play.  Every time you gain Power in the game, you move your Power Tokens around according to certain rules.  Let’s show it in a function.


The first thing this function does is set a variable equal to the amount of power to be gained.  Then, the function checks to see if there are any Power Tokens in Bowl #1.  If there are it moves them into Bowl #2.  Once Bowl #1 is empty, it will only then start to move tokens from Bowl #2 to Bowl #3 where they are available for use.  It will continue shuffling the Power Tokens around between arrays until there’s no more power to move around.


Makes sense?  Great.  Let’s check out what happens when you SPEND Power Tokens.



As you can see, the function checks to make sure there are enough Power Tokens in Bowl #3 before moving them back to Bowl #1, where they will available for future gainPower function calls.

But what if you want to cast a spell but you don’t have enough power in Bowl #3?  I gotchu bro.  As long as you have a large amount of Power Tokens in Bowl #2, you will likely be able to cast the spell all the same.  BUT there are some serious circumstances to this.  Let’s take a look.


We are only given the option to Sacrifice Power to cast a spell if we don’t have enough Power Tokens in Bowl #3 to do it already.  Then, we figure out how much Power we need from Bowl #2 and how much Power that’s still coming from Bowl #3 in order to cast the spell.  After that, we have to be sure that there are at least twice as many tokens in Bowl #2 than we need for the spell.  Why?  Because every time you cast a spell using a Power Token from Bowl #2, you must PERMANENTLY sacrifice one of your Power Tokens for the rest of the game.  The logic written below then shuffles around the Power Tokens into the appropriate bowls.

Great!  Our Power Bowels are good to go.  Let’s see them in action.  


Remember, to start off we have 5 Power Tokens in Bowl #1 and 7 Power Tokens Bowl #2.  Bowl #3 is empty.  Also remember that when we look into our Bowls, the Power Tokens are going to be represented with the Integer 1 (because I said so, k?).  So let’s look at how these Function calls exactly are manipulating our Bowls.


So there we have it.  The Bowls Of Power Mechanism from Terra Mystica defined in the Swift Programming language developed by Apple Inc in 2014 year of our lord .  All of their required functionality is included as these are the only three actions that ever need to be taken on the bowls in the game.  I thought about making the sacrificePower function get called within the spendPower function depending on if the appropriate conditions are met (and the other way around), but I already screen-capped everything so deal with it.  

Until next mechanism, bozos!

Tuesday, February 14, 2017

The Real Immersed Reality Starts Here

To the few readers I currently have, and the many more I hope to gain in the future: after a two-year break from the blogosphere (is that still a word in 2017?), Immersed Reality will be making its triumphant return in the coming weeks and months and years to follow.

In many ways Immersed Reality was never here to begin with as I never gave this blog much energy; I was too busy playing games, watching movies, and generally living my life (you know, that thing you do when you're not playing games or watching movies).  It was sometime toward the end of 2014 that I grew weary of updating this dump with yet more of my half-articulated opinions, so I just kinda let it sit for awhile.  In the mean time I wrote a novel, went back to school for iOS programming, and transitioned my gaming obsession from being primarily of the electronic kind to primarily of the table top kind.  I also launched a YouTube channel.

Despite all that living life and whatnot, my mind never drifted too far from Immersed Reality.  It is the home page of my browser after all!  I frequently thought about ideas for posts, or funny insults to hurl at my least favorite filmmakers, but I never really felt like putting them out there for anyone to see.  Recently however, a lot of the disparate aspects of my perspective on games and film and art as a whole have come together in a really meaningful way, and I finally think I'm ready to start organizing them into essays and submitting them to the public eye.  So without further ado, let's go over the three areas of discussion that will form the pillars of what Immersed Reality will be.

1. Film Theory

Film Theory posts will be in-depth sample texts from my four volume Immersed Reality series that I've been working on for the last six years or so.  These posts will cover genre, aesthetics, narrative, grammar, you name it.  They will glorify cinematic excellence and condemn the deceptive and tasteless works that seek to the debase the form.  The four volume series is titled as follows:

Volume I: A Journey Through Captured Realities
Volume II: The Deception Of The Elements
Volume III: Microscopic Organisms Of Light
Volume IV: A Universe Of Design

Volume I is structured as a top 100 films of all-time list.
Volume II is a surgical debunking of the ostensible merits in the oeuvres of many overpraised -- and overpaid -- filmmakers.
Volume III details how to fix the problems infecting modern cinema by providing a back-to-basics set of guides and principles.
Volume IV showcases the future of cinema, and its place in the future of visual art.

Eventually I will seek publication for these works, but in the meantime I will provide as much of this content for free on this site as I am able.  

2. Board Game Design

Another constituent of this blog's identity will be posts centered around board game design.  I host a YouTube channel about board games called Board Bozos (link above), which frequently features me and my friends trying to play games after having way too much to drink.  I have also taken about half a dozen design concepts up to the prototype stage, but have yet to publish any of them.

As we are living in the golden age of tabletop gaming, I think there is a strong need for detailed discussion regarding design trends, industry practices, and board gaming culture in general.  I don't see much worthwhile content with regards to the board game space on the web (my own YouTube channel included lol), so I want to help continually push the form in a positive direction by providing well-written and insightful articles that help people look at common concepts in a new light.

3. Swift Programming

I am a long-time professional in the Apple technology ecosystem (sales, operations, training, management, repair, software, hardware, you name it), and recently I made the career switch to development -- focusing almost entirely on the Swift Programming Language.  I strongly think the impact Swift is going to have in the programming world will be unbelievably huge, and I see the relaunch of this blog as an opportunity to provide some of my perspective as I go along for that ride.

These Swift posts will include things like small tutorials on goofy or easily misunderstood aspects of the language, my musings on the goings-on of the Swift development community in New York City, and thought pieces on the advantages that come with applying programmatic thought  to various topics.


So there you have it.  Three topics that each in their own way are experiencing a huge upswing in popularity and importance.  Swift because it is the coding language of the future (insofar as Apple wants it to be).  Board Games because they are one of the fastest growing entertainment industries in the world.  And Film because of the limitless untapped potential its hiding that I hope to help bring forth.  That being said, I will no longer be writing scored review blurbs for movies as I see them and have removed all of my former posts that feature such content.  Bits and pieces of that material will resurface in the coming Film Theory posts, but otherwise the time for such triviality is over.

Prepare yourself.

The real Immersed Reality starts here.