I believe this approach is a healthy and reasonable compromise to provide meaningful information without giving away too much. One may have to walk around for quite some time but there is reassurance that these Pokemon are obtainable and that the Nearby screen is helpful. All the while, people would still be walking and traveling about their community.
Sunday, July 31, 2016
Pokemon Go Nearby Radar
I believe this approach is a healthy and reasonable compromise to provide meaningful information without giving away too much. One may have to walk around for quite some time but there is reassurance that these Pokemon are obtainable and that the Nearby screen is helpful. All the while, people would still be walking and traveling about their community.
Wednesday, November 25, 2015
Icons to Buttons
Being how I am, I immediately think how silly it is to make this mistake--I am a stickler on semantics and I can't stand lexicon branding (eg Kleenex for tissues).
Perhaps the term icon is colloquially accepted for the thing that appears on a modern & conventional computer virtual desktop. Maybe I'm being harsh. I can't think of many times when I've had to refer to these things that appear on your desktop. And maybe I would end up telling someone to "press the blank icon".
I think of icon as an image used to convey or recognize something or an intent. What is created on the desktop is something more than just an icon. I'd say they have icons. Again, the software engineer in me has to make the distinction between is a and has a relationships.
The most recent time when I saw this misnomer, I decided to Google define:icon. The result was pretty much what I expected: the use of icon ramps up around the popularization of the personal computer (circa 1980).
But around 2000, the use of icon starts to decline. Why is society starting to abandon this term now? Given the misnomer noted previously and the correlation to computers and the modern computer desktop, did something change about computers around this time to influence this change?
First thing that came to mind: the iPhone; the new wave of mobile computing.
Below is the Google Books Ngram Viewer of icon crossed with iPhone.
The graph supports the theory that the diminishing usage of the term icon is eclipsed by the mobile paradigm spearheaded by Apple's iPhone.
So, that leads me to my next question: what term are people using in place of icon, particularly in the context of mobile computing?
Button?
Although the term button is also subject to the computer influence as icon, around 2000, increases in a similar fashion to the decreasing of icon.
Sunday, September 27, 2015
Global Gam Jam 2015 Retrospective
Introduction
In January 2015, I participated in my first game jam. It was also my first live on site game jam. I attended the Global Game Jam at Northeastern University in Boston. What is special about this location is that it is the domain of Susan Gold, one of the proprietors of the Global Game Jam. I intend on going again next year in 2016.The company for which I work has over the last year or so has made the attempt to adopt a more agile software development approach. I figured a live on site game jam would be a good opportunity to either learn or utilize some agile skills. That was the intention. Creating a game in 48 hours seems like an endeavor that requires rapid development. However, in the end, my team's largest mistakes were not following agile practices.
I've been putting off writing a retrospective. So, here I go.
What went well?
Preparation: I was meticulous with preparation. After registering weeks in advance, I drafted up a spreadsheet checklist of various things to acquire, take, and learn before going to the game jam. In some ways, it was like preparing for a software project at work. In other aspects, it was like prepping for a sleep over or camping trip. Apart from lots of tech and tools, a good portion of prepping was practicing various common elements of game development with an intended game engine, Unity3D, just to make sure I knew them.Team building: In general, a large group of predominately computer and video game geeks have trouble meeting strangers and forming teams. The jam site was packed with many new faces. It was encouraged to team up with strangers rather than coming with an already assembled team. I didn't know anyone, except for a coworker that I asked to attend.
As a way to overcome this situation, the jam site put everyone in one of about six large groups. And from there, asked the group to participate in some planning exercises. In the end, my team consisted of seven people which I believe all originated from my larger preassigned group.
Brainstorming: We spent about a half hour brainstorming game ideas centered around the Global Game Jam theme for that year ("What do we do now?").
We were told to brainstorm game ideas for about half an hour. What we did resembled speed dating. We all broke up into smaller four people groups. We decided to spend 4-5 minutes pitching and sharing ideas. After that time expired, we randomly dispersed to form another small group and repeated this process until the entire block of brainstorming time was up.
I actually ended up being the person which used my phone timer to time-box the small group brainstorming sprints for the larger group. It worked very effectively, as a lot of game ideas were generated during this time.
At the end of the session, we made a list of our favorite ideas on a whiteboard to go over with the entire group.
I was very intrigued by the way ideas were passed around, cross-pollinated, and evolved. In fact, by the end of the entire game jam, I saw splinters of game ideas which I contributed in a lot of the final games.
Workspace setup: The game jam took place on an entire floor of Northeastern University's library. This floor had tons of islands and tents with many workspaces with extra monitors and / or iMacs. Our group was fortunate to secure a 2 x 3 person workspace for the entire duration of the game jam. It was there that we were all able to work in a centered location. Face to face communication provided for quick communication and feedback, as well as fostering a sense of team and togetherness (which kept the team positive through pretty much all of the jam).
Manager role: One of teammates had a role which was fairly under-utilized with our particular game: writer. This individual shifted their role to be more of a manager (something that was close to their profession). This person communicated between present and non-present team members and facilitated the acquisition of art and other assets.
On the final day, energy was low. Our manager was one of the few team members which managed sufficient amounts of sleep. During the last stretch, particularly during the submission and finalization phase, our manager kept us together and on point.
What went wrong?
External game coach: The intention of the game jam site was to have an experienced game developer initially coach each group to make sure they were on a good path. Our coach, who shall remain nameless, set us on a bad path. This person had a tendency to insert their ideology into our more favored game ideas. In the end, the game idea we went with barely resembled any of the nice ideas initially brainstormed.I read a game developer's blog concerning some game jam advice that now really resonates with me: don't let anyone else (outside your team) tell you how your game should be. They aren't going to be the ones working on it. Your game is for you and your teammates.
Wireless connection: Northeastern sent out instructions well ahead of the game jam date to acquire a temporary user account to be able to use their network. Despite doing this, although I could log on with one of the provided desktop computers, I spent hours on the first day without network access and trying to track down IT to remedy the situation. The person I found to help me (and a few others who had my same problem) never did fix it. Fortunately, I brought a very long Ethernet cable--I used it for the rest of the game jam. I had to unplug one of the provided workstations and run my trip hazard away from my team's table.
An idea I put forth early but my team generally rejected was to have everyone on the team have a GitHub account, so changes to the project could be made and submitted by all members. The alternative was that art (and other assets) were channeled through email and through certain individuals and eventually to one of our coders. It caused a bit of unnecessary overhead and bottle neck.
Sounds & music integration: We were fortunate to have a very skilled musician on our team. My only criticism was that in combination of other complications with asset and code integration, sound effects were such an afterthought, most of the elements in the game were not accompanied with any sound effects--just music.
Software integration: Free GitHub projects work great for a 48 game jam. However, Unity3D, even with some tweaking, does not lend itself well to collaboration--auto-generated scene files and the like were often conflicting and resolving those conflicts manually was not always straight forward.
Distribution & faith of skills: The team breakdown of seven people was: writer / manager, artist, musician, coder, coder, coder, coder. The array of coders represented a range of experience both with video game development and software development. We perhaps had too many coders and not enough artists.
Being mostly strangers, we did not have much to base our confidence in each other's skills. Our unvoiced approach to work around this dilemma was to develop entirely separate mini-games. There was nearly no functional relationship between these mini-games. It didn't really feel like a complete game.
Game submission: During the final hours of the game jam, it was time to submit our game to the official Global Game Jam site. Our team worked up until the moment, furiously trying to pack in working code and assets. After we finalized our work, we were uploading our project with nearly the rest of the world of jammers. The system just couldn't handle this stress--and it was stressful for us.
Experiments & goals for next time
- Come and team with coworkers: I enjoyed meeting new people during my first game jam. However, having work experience with other people, particular with software projects, should be a big boon against the "faith of skills" problem.
- Everyone have a GitHub account: Regardless of role, everyone should be able to contribute to adding & modifying project files. This approach attacks some of the "integration" problems.
- Distributed & multiple roles: If there are not enough people on the team or just not enough people taking on certain roles, it may be a good idea to have most everyone on the team take on a major and a minor role. For example, a coder could also be an artist or a coder could also be a musician. This attacks the "distribution & faith of skills" problem as well as the "assets integration" issues.
- Only team with people with a strong interest in creating a game: It's questionable whether our artist spent the same amount of time as the other present members on our team. Being in person at least creates expectation and conditions which kept us working on the project. Of course that's the point of a game jam--to apply pressure, expectation, and synergy to actually create a game. It's hard to anticipate this problem. The only thing you can do is team with people you know and you have a sense that they are willing to put in the work for the entire game jam. This attacks the "remote teammate" problem, in the least.
- Only as for guidance if we need it: Our "coach" was kind of self-invited. We had a lot of good ideas and at the time, I don't think we had decided on one yet. It was just a matter of time. I think having a game jam under our belts should reduce the need of a coach.
- Stay away from Unity3D: Yes, I'm saying it. This beloved game environment is not conducive to collaboration, at least not for 48 hour / novice game development. The code conflicts it created were devastating. It's better to use something almost entirely manually source driven, such as HTML + Phaser.
- One game: The team should focus on making one game instead of a handful of incomplete games. This goal should be attacked in multiple ways:
- Focus the game-play around one or a few mechanics or genres.
- Break down the game into features, stories, and tasks that can be completed by any members.
- Break up the code into separate files and modules. In this way, there will be more opportunity for collaboration between coders and such. People will be less likely to step on each other's toes and create code conflicts. Come to the game jam with a project template which is ready to be populated by all the team members.
- Get the game working early: The term that's used to define getting a software project to this point is called "the critical path". The team focuses on the most essential portions of the project first to get something that is working and playable. This should mostly happen on the first day. It can involve incorporating placeholder assets, using non-elegant code solutions as proof of concept, and even borrowing code. Having the game always in a working state means the project is always almost done, in a way. It provides for early feedback and iterative improvements until it's time to call it quits. This goal partially attacks the "game submission" problem, in that it's easier to say the game is done early and thus submit the game early as well. This approach also plays a part in the "one game" goal.
Conclusion
Thursday, October 30, 2014
Response to GamerGate
Friday, June 27, 2014
Android L and the disappearance of the smart phone
Polydevicism is a term I coined in a 2010 blog entry, depicting the ever present array of personal computing devices which surround us in our daily lives. More specifically, the blog entry mentions how all those devices will be satellites to one primary device.
That primary device used to be a desktop computer. Now it is our phone. Soon, that device will be as non imposing as a credit card that is carried in a wallet--the disappearance of the phone as we know it.
Google announced the code name of the next version of Android called "L" at their yearly IO conference. A huge underlying theme of IO 14 was the integration between devices with an emphasis on "casting", like with their successful Chromecast device as just one of the means of doing so. If you connect the dots between everything shown at IO, it paints a paradigm shifting picture where the phone is made transparent.
I'll explain:
1. Google showcased Material Design; their attempt at a universal approach to UI that scales to any device, from watches to car displays to desktops to TVs.
2. Chromecast is an avenue in which anyone with a phone can walk up to an enabled TV and start viewing their own personal media: videos, music, pictures, music and likely soon news feeds, calendar, and documents. Casting doesn't have to be one directional; I suspect video conferencing will follow (think Google Hangouts on a TV).
3. To bounce off my last idea in #2, it was rumored before IO that Google will merge Google Voice and Hangouts.
4. Google announced Android Auto; an Android interface for a car. Think of Auto as the template and basis of my argument. The driver's phone will cast to the car, allowing for the car to act as a controller for the phone. In essence, the car is a phone, complete with speaker, microphone, and display. It will undoubtedly allow the driver to place calls.
5. IO also showcased Android Wear and more specifically an Android wrist watch. It is able to instantiate phone calls with the aid of a smart phone. Things like calendar events and even the time can be viewed from the watch. It used to be something to carry a pocket watch until wrist watches replaced them. Modern cell phones are like pocket watches.
6. Google also showed how a Chrome OS enabled computer will be able to run applications installed on the user's phone. The phone will communicate with the other computer, relaying notifications like when the user receives a call. I suspect making calls through the computer via the phone (like with Auto) is inevitable.
7. Google showed both the situation where A) the proximity of a Wear device unlocked a smart phone. B) the presence of a phone unlocked a Chromebook without the use of a password. A password is just a way of proving identity.
8. Chromecast will be getting some form of user permission system, where the owner can allow for some people to use their device instead of the current policy where anyone on the network can cast. I suspect permissions will be broken down into various tasks like viewing videos, making calls, etc. The user identification via device from #7 will play a role.
All the points I made have 1 major implication: the user does not have to take their phone out of their pocket or purse.
So, why does a "phone" require a display or speaker or microphone for that matter? All it really serves is a network connection.
Imagine a world where we can walk up to any display and access our "cloud data". Your computer stays tucked away while every display feels familiar as though it is your own. For example, ATMs will just be a cast of your computer's banking application. Drive through menus will display your favorite items as well as offers specifically for you.
Google will try to get microphones, cameras, and in some instances, speakers into or around every display. We'll see how well our social paranoia of surveillance lasts as we cast our hearts away.
Wednesday, March 21, 2012
Virtualization from my life seeping into my dreams
On the walk, my partner told me about a recent trip to New Orleans, focusing on an encounter with a stereotypical Voodoo magic fortune teller. The subject of horoscopes was brought up and I had asserted the notion that I am considered a Pisces (represented by fish).
It was good to come home as these recent weeks have been pretty stressful at work, as the software company I develop for is approaching a release deadline.
At home, in my spare time, I've been designing a fairly sophisticated software framework, where both computer programming language and system architecture are not only abstracted on one level, but in some situations, on two levels (namely, Javascript to native C/C++ to/from Java). Not to get too technical, but this process requires each software layer to interface the next with essentially what are functions that act as translations just like one person often requires a translator or dictionary when abroad in foreign countries.
I had a strange dream last night that seems to have tied these past events together. Much of the dream was seemingly inconsequential, involving me interacting with the various different people who facilitate the transfer and ultimate delivery of products at a large big box retailer or grocery store. First I drove around, early in the the morning, to meet up with the truck drivers who shipped products. There was some purpose in this encounter, but it is hazy. Later, I remember being in the store, wanting to make some kind of purchase or trade, but I recall having some minor difficulty with such.
The dream had a very abrupt culmination and realization not too soon before it ended. I finally acquired two things: a large quantity of fish that had been frozen in stasis (as in, ready to be thawed and to resume living) and a typed white on black (aka carbon paper) of a rather extensive specifications sheet.
The spec sheet listed the syntax for binding all the biological functions of that particular breed of fish, allowing them to be programmed via a computer application. I remember seeing lines that looked like Java JNI function declarations with titles like "..._fish_heartbeat", "..._fish_swim", "..._fish_breath", etc. Thinking back, I seem to recall that I understood the contents on the sheet, but I don't recall now what was the nature of the technology. Had humans developed the technology to precisely project and impose electrical signals that drove neural synapses in the fish? Or did the technology involve nanotechnology or both?
The principles in the dream are the same concepts played with in the comic/movie Surrogates and the movie Avatar: biological virtualization. I can only conclude that my subconscious felt it was starting to overcome some significant computer language/architecture barriers and decided to tackle electrical/biological barriers as well.
Thursday, February 17, 2011
Steve Jobs is the Elvis of the personal computer
But unlike Elvis, all these stock fears seem to suggest he is worth more alive than dead. Therefore, if Jobs' possible passing is being kept secret for financial reasons, then shame on anyone involved in the secrecy--it actually does not speak on the value of his life but that of Apple. Rather, if his possible passing is being kept secret for privacy reasons and respect for him and his family, I am as well as everyone else should be satisfied and content.
I have much more respect for Steve Jobs than I do with Apple. Notice how I make a distinction between the two. Not enough people do, unfortunately. And if we were purposely led to believe that there is no Apple without Steve Jobs, well shame on those people who pushed that idea.
And if Jobs was part of that idea, then perhaps the best thing he can do is say goodbye and resign before he passes, not the other way around. The best thing Apple could do is disassociate the company from the man. Perhaps it's too late to start.
I have no interest in using or developing for Apple products, but I hope Jobs recovers. This is all being played like a game of poker: the very notion that this is being kept secret is more or less a good sign, meant to keep others from folding their hands in the hope that they have a good hand (which can be likened to Steve returning).

