Category : Design

Treasure Quest

Fun, Flash and Festivity: Tagged Winter Game Jam

Most games take months or years to develop. During a recent Game Jam, our Games Team made four fully functioning games in 24 hours.

At Tagged, Game Jams feel reminiscent of music jam sessions, where friends gather for hours on end to rock out and tap into their creative side. Sub out the guitars for computers and rockers for coders and you’ve got a feel for our vibe.

Over the course of 24 hours, our game designers, artists, programmers and producers develop at an extremely fast pace in order to create several playable versions of concepts generated by the team. Game Jams provide a great opportunity to step out of our usual roles during production and skip right to the heart of creating something for other people to enjoy. It’s also a great chance for people to create with co-workers outside of their regular teams.

This Game Jam, specifically, helped us focus on how we can best prototype for Flash. Our team recently decided to use Flash for our next few games as we found it to perform better when stressing animation, audio and customizable art assets. Due to the nature of how technologies like HTML5 load bitmaps and animation-data, we’re better off using vectors with flash instead of developing a new loading pipeline for bitmap. This is important as Tagged serves a number of users across many browsers and connection speeds, and a poor loading pipeline can severely impact both the first-time experience and the game as a whole.

We established a few goals at the beginning of the Jam in order to make it both extremely fun and productive. Our goals for this Game Jam were:

  1. What techniques and tools can we use to be most efficient in Flash development?
  2. What game concept should be developed for our next Tagged game?
  3. Team building!

Laying out the games

At 5 p.m. we gathered in our main meeting room where our assignments were revealed. The next 24 hours were intense. Early success came when one of our groups had a playable game in only a couple of hours. Two of the teams were working with the Flixel library in order to skip most of the basic game loop coding. Most of the groups pushed on through the night with small celebrations by the teams as each part of their games started to function.

Working hard

By 10 p.m. everyone had hit their stride and were coding their respective games.

Our productivity held strong through the early morning hours, but we grew more tired and silly as the morning went on. We recharged with pizza at 4 a.m., and pushed through the morning. Final tweaks and polish were added during the last few hours, and teams took their hands off their keyboards when the Jam ended at 5 p.m. the next day.

We still had to celebrate though! So in classic Tagged fashion, we brought in some beers, played some games, and reflected on the past 24 hours of insane productivity in a debrief.

The results were incredible! By the time we ended, we had four fully functional games: a paper prototype, a two-player game, a networked multiplayer game and a game that was running in flash and on the iPhone! We learned most of us made design decisions based on what could be coded quickly, not necessarily what would be the most impressive feature. Having this clear vision of ‘do it quick or not at all’ really allowed the teams to make playable games with many features in a short amount of time. All of these were solid prototypes that will be played and studied over the next few weeks to find the next best game to release to our users on Tagged.

Game discussion

At the end, not only do we have some awesome new games to play, but we also learned more about how each member of our team works and how insanely fast we can make games. We also all grew closer through sharing this intense, exhausting, and fun experience together. We’ll definitely be doing another Game Jam next quarter and will be sure to report back!

Above screen capture is of “Treasure Quest”.

Auston Montville is a Junior Game Designer at Tagged and loves chatting about games.

Mark on UX

UX Principles for Mobile

Last weekend, I had the opportunity to give a presentation on  at the Designing and Developing for Mobile workshop put on by AngelHack. The event was attended by a spirited crowd of over 250 designers and developers, and included some insightful presentations from Janice Fraser, Founder & CEO of LUXr, and Aryeh Selekman, from Facebook.

UX is a great passion of mine and I’m excited by the new paradigm of designing continuity for products on multiple screen sizes. My presentation covered some tips & tricks for mobile design, analyzing mobile as a unique user experience, and how best to move forward in responsive design given the capabilities of the many devices for which we design.

I’ve embedded my slides below for anyone interested and will have the recorded screencast up shortly. Hope you enjoy! Feel free to leave a comment below or reach me at if you have any questions!

Mark Lieberwitz is Mobile Product Manager at Tagged.

Tech Talk: Responsive Web 101

At the end of each quarter, Tagged interns present a tech topic of their choosing to share with the broader team. I’ve been quite fascinated by Responsive Web Design so this is the topic I presented on in December.


Responsive Web Design means developing a website that A.) rearranges the layout as the screen size changes (so simple, but so cool!) and B.) supports all browsers and devices, as opposed to having a specific mobile site to support lower-end devices. Ethan Marcotte, who coined the term “Responsive Web Design,” provides an excellent foundation over at A List Apart.

What makes this approach so compelling from an engineering standpoint is that having one site that works on all devices means you have one unified code base. No duplicate code for mobile and desktop. You’re no longer forced to build features two or three times. And most importantly, Responsive Web makes for a much better user experience.

Responsive Web Design works by keeping the content and markup the same across all devices by just manipulating the layout with CSS. CSS media queries detect the size of the screen and specify how content is displayed accordingly. However, since we can’t fit everything that would fit on a desktop site onto a mobile device, we define the “main content” of the page that all devices should see and load the other modules on the page conditionally (i.e., add more modules as the screen gets bigger). Ideally the “main content” is static so that lower-end mobile devices can access it, and everything else is loaded with JavaScript so that it only loads what is needed.

This approach adds quite a bit of CSS, of course. However since we only load the modules we need, and the modules only include the CSS they need, it’s not a code load problem. Extra time spent on CSS to implement Responsive Web Design is still less time than creating duplicate code for mobile and desktop Web – well worth it in my opinion!

We’re testing this approach at Tagged and I’d love to see this approach adopted across the Web as more users access sites from multiple devices.

Amulya Sanagavarapu was a Fall 2011 intern and is studying Computer Science at the University of Waterloo.

Tech Talk: Design + UX

“Design you say? Pah, leave it to the designers! And leave me to my PHP and Node.js.”

Not so fast. As it turns out, the more you know about design, the more efficient you can be with your development work, leaving more time to focus on coding.

As Tagged’s Senior UI Designer, I want to remind you that even the most hardcore coders should think about design. Why? Because by considering a few practical design and UX practices, developers can create and code better products – while saving time typically spent backtracking with designers. Design and development actually share many principles in common, including: unified hierarchy, elegant simplicity, consistency and scalability/flexibility.

Each week at Tagged’s Development Workshops, we present best practices in product development. In this presentation, I discussed some essential design foundations for developers including:

  • Top-seven design principles for developers
  • Standardizing common elements with style guides
  • 960 grid system for layouts
  • The responsive Web, and designing for multiple-screen resolutions

Check out my video presentation and download the slides here. Got a design question? Leave a comment below or email me at

king leonidas pretty pissed

Spartan: How a Team of 6 Manages 1,000 Servers

At Site Operations at Tagged, our goal isn’t 99.999% uptime; it’s enabling developers to make changes fast. Although we want to help our developers try out new things as quickly as possible, as many seasoned IT professionals know, changes make systems break.

To cope with this, we’ve developed an internal IT culture that helps us manage a network of over one thousand servers with just six people with minimal burnout. This post will be the first in a mini series on how we run one of the world’s largest websites with a minimalist approach.

At the core of our approach is how we play it fast and loose with the SiteOps rotation, literally. We have three people who are in rotation between managing user requests, handling server events, and downtime to work on projects. A typical request might be to deploy a new version of an app to the servers and to facilitate the developers in development. This is a DevOps kind of role, where the developer and the Request Manager coordinate development from the inception of a project. Events covers managing the pager, handling broken servers and hardware, troubleshooting and problem solving. Projects covers long term projects, many of which are automation oriented.

To prevent burn out, the rotation is very fast–one week for each role. It’s very rare for two major incidents to happen in one week and that prevents us from getting that “Oh no, not again!” feeling that is so well known to SysAdmins. The schedule is also very loose where we horse trade roles, tit-for-tat often. When a SiteOps engineer is tired and in danger of burn out, we’re very proactive about stepping in and taking over the role for a few hours or a day when needed. Working in a startup gives us this flexibility without complicated policies.

Another technique we use is constant automation. Aside from our long term quarterly goals, our SiteOps engineers are encouraged to automate everything that takes up a lot of time. The Projects week is a distraction free time for doing analysis of the previous two weeks and working on concentrated development. This could be automating routine user requests, for example creating a user provisioning tool that HR and hiring managers can use, or automating taking a thread dump and restarting a Tomcat server when it runs out of memory. We also integrate automation into requests, all our developer requests for changes on servers are managed with Puppet where possible. By guaranteeing the time, even though it’s in fast rotation, it helps us focus on quick solutions rather than complicated ones that can’t keep up with the fast pace at Tagged.

While some of the aspects of loose communication don’t always scale to larger organisations, this setup enables us to grow our site without the need for a large team. Fortunately, growth of our site has been a steady incline which gives us plenty of time for planning. As the number of users and apps go up, by focusing on these two techniques, we’re able to improve the site while reducing the amount of human effort per server unit. This enables the entire SiteOps team to work with the systems at a very high level approach and it’s a great intellectual challenge.

Make everything as simple as possible but not simpler. -Albert Einstein

Yaakov Nemoy is a Systems Administrator at Tagged.