On Reasons I Like Third-Person Camera

There has been plenty written about why one should make a game in third-person or first-person:  Convention and what your target audience will already be familiar with.  How much you want the player to be immersed as the character in your game.  And so on.  Today, I would like to discuss my biggest consideration: information – as a gamer who likes when UX/UI emphasizes information and clarity, third-person camera appeals to me more.

While first-person camera appears immersive immediately, there is quite a bit of information that it will not be able to capture until VR tech gets further along.  Forefront is touch/proprioception.  In addition to the first-person view I have out of my own head, I can feel where the ground is below me and where a wall is behind or beside me without having to look at it.  Touch/proprioception allows me move comfortably around my environments in spite of my own limited field of view.  With first-person camera however, you can’t tell that you’ve landed on a surface or if you’ve bumped up against a wall unless the camera stops moving or if one your directional movements starts pushing you along something.  It’s not ideal and, at least for me, requires an additional moment of mental processing to figure out what is going on.

Now enters third-person camera.  It does not give us completely natural proprioception of the environment; however, it does allow me to see the floor and the walls in lieu of feeling them.  I can more closely see where my character is in space just as I would feel where they are in space if it were ideal first-person.  In lieu of physically being able to brush up against things, at least I can see where the 3D models touch.  This restores more of my sense of space and allows me to move in the game more reflexively.

I can’t just outright recommend third-person camera.  Of course, when poorly implemented, it can cause just as much frustration.  What I do want to say is that in most cases, when given a choice by a game, I would choose the third-person camera over the first-person camera because it feels more natural to me.  More natural because, though it sacrifices the sense of immediacy and of seeing “through the character’s eyes”, it offers information normally provided by touch/proprioception.

Reflection on Werewolf

I’ve played Mafia, a lot of Mafia, and some of my thoughts are probably anchored based on how those experiences went.  Nevertheless, I wanted to comment on something that stood out to me the most on my first game of Werewolf played on 1/30/2015:

We let every villager have a role. While letting every villager have a role was a nice way to give everyone something to do, I didn’t like it from a game design perspective. Having too many clear roles upset the fuzziness in identity that makes this type of game confusingly compelling.

For example, say there is one werewolf and two villagers left:

If those two villagers had specific roles, say bodyguard and seer, then in that case, the werewolf must claim to be one or the other. However, the person with that card would know that is a lie and it would simply come down to a shouting match between the two.

If on the other hand, those two villagers roles were just “villager,” then the werewolf could claim to be a villager. In that case, both real villagers only know that they themselves are one of two villagers, and could be played against each other by the werewolf claiming to be the second villager.

In the first case, the onus is entirely on the werewolf to process all the information, make an optimal choice, and then try to be the loudest.  In the second case, the werewolf has the choice to be more deceptive, and play both villagers against each other, creating flexibility.

When my group played with too many roles last night, then, it was simply a process of elimination and matching up individual roles with people, which made it easy to solve the game. I found it difficult as a werewolf to pretend to be “part of the crowd” as there was no generic “crowd” to be a part of. Instead the game was about knowing the ideal next steps.

My recommendation would be to play with more regular villager cards but give them artifacts if they want to have unique powers. Having duplicates makes it more difficult to determine who people are and creates more confusion, politics, and intrigue, which is what I believe is the essence of these types of games.

Geometry 1/13/2014

Something that I’ve been trying to figure out what to do with is my affinity for random geometric problems (e.g. staring at a half-covered design on a random pizza box and realizing that the lines of the “pizza slices” do not intersect at the center of the arc in which they lie).

Today, I was pondering over the toroidal map type in Civilization. The game still plays on a planar rectangular projection of the map, but how much distortion should there really be?

I’m going to assume that the width of the map is the maximum latitudinal circumference around the outside, and therefore I am interested in how much narrower the “poles” should really be to meet each other on the inside of the torus.

My initial condition therefore is that [map width] = 2 * pi * ([major radius] + [minor radius]) and that [map height] = 2 * pi * [minor radius].

I am interested in the minimum latitudinal circumference, described by 2 * pi * ([major radius] – [minor radius]).

After some very basic algebra, the conclusion is that the poles should be only as wide as [map width] – 2 * [map height], a significant result! The distortion is quite severe for maps of appreciable height!

If a toroidal Civ map was twice as wide as it was tall, the poles would all still come to a single point, which is not much actual space for units and cities placed up there. Though, if we had to play on Civ maps where distance was physically accurate given the 3D shape of the world, it’d probably be even more confusing to keep track of.


A not actually very informative scan from my scribbles

In Regards to Filming an iPad

Filming an iPad app is not a trivial task.  Sure you can record the screen directly, but then you don’t see the interaction of someone’s actual hand with the touchscreen.  Filming a screen though, presents interesting challenges, practically and artistically.

Below I describe the setups used by Capital Games during my Fall 2012 semester and then that used by Bravura during my Spring 2013 semester.  These were both semester long graduate projects and our teams are primarily game developers so we had no fancy studio equipment; just whatever the school had / we had lying around.


During Capital Games, we filmed our iPad app on top of our coffee table with the camera set on a tripod behind it.  The camera cannot be pointed straight down since the tripod legs would be in the shot; however you can see that the edges of the iPad slant slightly away because of the angle.  Our biggest concern was screen glare and so there is actually a black board help up above the screen.  Otherwise, only the ambient light from the room was used.  As you can see, the quality isn’t bad at all.  However, we did have trouble with white balance.  The hand and the table were very orange if we balanced to the iPad screen so we actually set the balance so that the iPad is a bit bluer.  Sound was recorded directly from the device via the headphone out.  Not bad for a first time.  Mike and I reunited on our Spring project, though, and we decided we would do it better.

Mike found a video about filming the iPad on top of an iMac with a white screen (I’ll put the link in when I find it).  This was an amazing breakthrough because:  (A) the background itself creates an even back-lighting that has the same temperature as the iPad and (B) the iPad’s natural habitat is floating in a clean white void.


This however creates lighting problems for the hand, which will now be even more dark and orange against two screens.  So at first we tried to light the hand by throwing a projector against a bounce board.  This lit up the hand great; however, it also turned the hand a pale, zombie-white color.  So I started grabbing lamps we had lying around.  Incandescent bulbs throw a nice warm orange, but since we were balancing to blue already, that made everything too orange.  What I really wanted was yellow, but alas, I was making do with what we had.  So I grabbed a bunch of blue / green transparent folders and bags and draped them over the lights (fire-hazard, do not attempt unless you are monitoring the temperature constantly), which got us more or less there.  Our final setup looked like this when we were filming (the camera is not on the tripod … because I’m taking the picture with it):


The same set up with the room lights on:


The final result is below.  I still wish we had proper lighting setup to bring out the hand, but pretty good otherwise.


Game Producing Effectively

So, as I mentioned in my previous post, I want to take a look at the chapters I had intended to read together separately as well.  In this post, I will be looking at “Habits of Highly Effective Producers” from “The Game Producer’s Handbook.”

The chapter starts off with an alphabetical list of good habits.  Admittedly, this list reads very generically, and is really good advice to anyone in any role (is there a job position where one should not “Demonstrate Professionalism” or “Meet Commitments”?).  For someone new to producing or looking at it from the outside, this advice doesn’t translate well into a tangible to do list.  However, as someone who’s produced for a little over a year now, I see what people say about producing being a very individual practice.  For myself, some of these suggestions translate into past anecdotes and specific practices I’ve adopted, but I wouldn’t be able to say that I’ve figured out the “right” way to go about everything.

Nonetheless, the latter half of the chapter does get in to more specific practices.

The first one is “Daily Delta Reporting” or what we refer to as “Dailies” at the ETC.  It is the practice of every team member reporting (either to the whole team or to management) about what specifically they worked on that day and what states those things are in, whether it be done or in trouble.  This is a staple of producing and I couldn’t imagine ending a day without knowing what happened.  It is very similar to “Dailies” in film where the crew looks at what was recorded that day.  However, film dailies are specifically a look at the collective product and how individual contributions appear in it, while game development dailies are just individual reports (there may not always be a collective product at the end of the day).

The second one is about asking clarifying questions.  This sections seems the most oddly specific, especially since being a producer in an academic setting means I’ve never had to deal with questions like “when a team member is unhappy with a raise.”  However, I really appreciate this section for giving very specific examples of how to frame questions about sensitive issues – usually in logical or resolution-oriented ways.

Further along, “Always Follow Up in Writing” is a good one.  It turns out that it isn’t just in legal situations where having exact events and responsible parties in writing is useful.  Law involves the practice of communicating very specifically, and producing also requires that – albeit probably to a not-as-exacting standard.

In “Scheduling and Rescheduling,” Dan Irish mentions specifically that he uses MS Project and Excel for schedule, a nice specific fact.

“Knowing What You Don’t Know” was a nice section to see near the end as well.  This is a fundamental problem that plagues my mind:  As the producer, I both want to defer to the expertise of those who know better than I, but I also want to know what they are talking about in detail.  I think one of the core things about being a producer is about being in control enough to know who better to put in control.

Overall, I found this chapter very relate-able since my primary experience at the ETC is also in game-production.  Maybe I’ll find out that production is not much different across industries other than the industry knowledge.

Capital Games Personal Post-Mortem

The Fall 2012 semester at the Entertainment Technology Center is over:  Food Quest has been handed off to the client as well as into the ETC archives, and the Capital Games team is officially disbanded.

The team achieved a great deal this semester and I’m very happy to have been their producer.  My team really stepped up to every challenge and obstacle we encountered along the way.  I hope they’ve learned a lot, and as for myself, I feel like I learned a few things about producing as well:

From my advisors:

I met with my faculty advisors twice over the course of the semester for individual performance grades and evaluation, and they told me a good number of insightful things about me as a producer.  There are there main things I need to work on:

Leading the team:
I’ve normally got a passive personality, and that’s pretty apparent to anyone who meets me.  While the faculty sees me as doing extremely well with the administrative and clerical duties of producing, I’m not yet a figurehead.  This is something that I need to work on and I believe I can; I came to graduate school to improve what I’m not good at, not to continue to do only what I am good at.

Growing the team:
I’ve got personality quirk that isn’t a problem for me, but is detrimental to those around me.  That personality quirk is that I’m pessimistically optimistic:  I like to talk about how bad things might be so that we can make it turn out better; this is how I internally motivate myself to work harder.   Turns out that constantly lamenting how terrible the project is going to turn out is not the best way to motivate a team  and help them get in the mood to work hard.  It’s fine if I keep the pessimistic optimism for myself, but externally, I need to show more optimistic optimism.

Pushing the team to achieve:
My normally passive personality towards others makes it simple for others to get away with the “easy way out” in their work, and I need to recognize that and know not only when to retreat from challenges that are too big, but push my team towards challenges that they can overcome.  For Capital Games, the team took a bit of time to hit our stride at the beginning and could have arguably hit it a little sooner if we hadn’t let ourselves be so daunted by our project initially.

From Anthony Hildebrand:

Anthony was our Writer and Sound Designer on the team, but he plans to be a producer as well.    For our project, he wanted to be able to look at the producer from an external role so that he could learn from me and I could learn from him, and it worked.  As the producer on a team, I’m the “go-to guy” but it helped for me to sometimes have someone else I could “go-to;” moreover, having someone else to help evaluate and criticism my actions and decisions really helped me to grow and develop.

One thing that Anthony helped me with was my communication.  In my circles, I’ve never been the social leader-type, but around the time I started graduate school, I realized that most skills aren’t innate, they’re practiced, and so my communication is something that I’m actively trying to improve during my time here at the ETC.  Anthony helped point out a lot of my shortcomings and how to solve them:

  1. One thing was to be aware of falling back on certain words too much and “cheapening” them.  For myself, I too often use the word “definitely” when I want to sound confident: “X will definitely happen” OR “I will definitely do that.”  While being confident is important, I was using this speech tick too much as a crutch.
  2. The biggest thing, though was my lack of control in a conversation.  My default personality is the passive nice guy and I can be afraid of controlling a conversation because it feels selfish; Anthony explained that as a producer, it is important to let others have their say, but to then bring it back into the larger picture to show that you always know what’s going on.  One particular thing he suggested I practice as well is to end conversations on “a button” – when I know a conversation is ending, I should take control and leave an important takeaway that I want everyone to remember as well as finish with a definitive phrase that ends the conversation.

The biggest thing he helped with was helping to facilitate communication with the client.  On Project Xense, the client was more hands-off than here on Capital Games, but Anthony had dealt with a more responsive client on his own previous project at the ETC, Pixel Pushers.  He gave a lot of great pointers about how to help the client understand what the team was and wasn’t capable of, but moreover on how to make sure to address the client’s concerns while suggesting alternatives.  It can often be easy to push back aggressively against unexpected client demands, but one really needs to dissect the meaning of those demands.  If you understand what the client needs relative to what they want, you can come to a compromise that is acceptable to their values and your own schedule.

And of course, he kept my confidence up and made being on the team a fun time, and that’s an even more important characteristic of a good producer.

GDC 2012

This was my first time at a conference, let alone such a big one like the Game Developer’s Conference.  While I wasn’t as outgoing as I probably should have been, I still really appreciated being able to hangout with all my ETC friends in a setting outside of class and the ETC building.

As to the conference:  It was quite something.  The amount of expertise being crammed into a two-block radius was palpable, and I can’t wait until the GDC Vault opens and I can watch all the great talks that I had to miss to listen to other great talks.

Now, I’ve made great improvements in learning the names of people I see everyday, but I’m still terrible at the names of “well-known” people so I won’t drop any here, but they certainly said a good number of things that other people and sites have taken note of.

I will say that I did learn quite a bit about producing, which has encouraged me to be more proactive with my project this semester, as well as about animation and portfolios, which has discouraged me from thinking that my knack for 3D art last semester is such a big deal.  I also met a considerable number of random people, though I found that many of them did not seem so interested in talking (trying to network with the big wigs? or perhaps that’s the characteristic of game developers?  OR maybe I’m really not that interesting?!?)

Global Game Jam 2012

Global Game Jam 2012 ended earlier yesterday.   The Pittsburgh International Game Developers Association held their event at the Entertainment Technology Center, right in my backyard, and there were about 100 Jammers who came.

While I wasn’t actually a Jammer, I did volunteer to help and I don’t regret it.  I got to hang out with cool people while having time between events to go back to my project room and do backlogged work.  Admittedly, most of the work was setting up and cleaning up food, but as someone who is interested in producing, I respect the fact that these things have to be done so that the more awesome game-making can get done.

The jam theme was the Ouroboros, and there were a lot of cool games here in Pittsburgh:  Some were simpler and casually fun; others tried to make you really think about the idea of biting your tail.

There was “Hebi Hanabi” made by the ETC stars Scott Chen, Brian Lee, Zero Liu, and Kaiyang Zhang.  They took the classic “Snake” game about eating eggs to grow longer and added two-player combat with the cool mechanic of actually having to bite your own tail to launch projectiles at our opponent.  A novel re-invention of “Snake,” their game was quite  polished and aesthetically clean.  They, in fact, won the Judges Award and Player’s Choice Award.

Another game worth mentioning is “Super Ouro Bro.s” which, despite the gimmicky name, had a really neat mechanic.  This game was made by Jing Li, Michael Lee, Dan Lin, and Felix Park; the latter three are of renown for their ETC project called “mindful xp” about meaning, expression, and games.  The mechanic was that every level a new enemy was introduced and the AI for that new enemy did something both predictable and frustrating:  It did exactly the same actions that you took in the previous level!  In the end, you were fighting yourself; now that’s “biting” yourself in the tail.”

I enjoyed quite a few of the other games that my friends made and would write about all of them, but it is 2AM and I have a project advisor meeting tomorrow; look for the games here:


And don’t forget to check out some of the other cool games that other people all around the world made.

Building Virtual Worlds Round 5

Final presentations for our Round 5 projects have ended.  The theme this round was to make something for the BVW Show.

You can see the game that my team produced in my portfolio under “Games: Building Virtual Worlds.”

My team from Round 1 got back together again for this round, looking to capture some of our previous magic.  This time, we made an ambitious choice to combine multi-player strategy gaming with a show element, and struggled through quite a few iterations of the game but the final product is pretty solid.

Luckily we decided to approach this round with a “lightening round” idea and polish it as much as possible; unfortunately, though, our choice in mechanic slowed us down a lot.  Coming up with a compelling strategy game takes a lot of balancing between control, random elements, and interest curve.  Moreover, multiplayer meant that there was a lot more implementation that would have to be done.  In fact, we changed our idea a multitude of times between interims and didn’t have our final design until after the last interim before finals today.  We went through ideas such as a silent auction to see-saws to scales and pulleys before settling on a simple tug-of-war style mechanic.  In regards to implementation, we started with Unity Phone, which still wasn’t ideal for having a lot of players connected reliably so over the course of the first few weeks, Zero spent most of his time with the help of Emmanuel developing a new web-browser based interface that people could use through their smartphones.  Turns out that this worked much more reliably than using the phone servers.

As to my contribution; I really did get a lot of opportunity to polish this project the way that I wanted to.  At the beginning while we were still finalizing the mechanic and aesthetic style, I took the initiative to model a whole multitude of low-poly prizes (cars, blenders, TVs, sofas, etc.).  Though these did not end up taking a main role as I had hoped, I did get to include them in the background of the final build.  The final tug-of-war mechanic did allow me to have a lot of fun animating our little characters, and they have a variety of different animations for each emotion.  What I am most proud about though is the subtle fact that they wave and acknowledge the guest when they receive a new command.  As to the overall environment, most every subtle detail that I wanted are there:  There are cameramen around the set that just rotate slowly and even a lighting grid on top of the ceiling  where little simulated spotlights are hanging from.

I had a lot of fun polishing this project, and the team was great.

EDIT:  This world made it into the Final Show!