The Blog

Posts from February 2011

Feb 25

Meta Leaderboards

By David Czarnecki

Traditionally, leaderboards rank players using one criteria, e.g. XP, kills, etc. What if you wanted to retrieve information from a leaderboard that combined more than one criteria? I’m going to show you how to do that.

To be honest, I don’t necessarily have a definite use case for this functionality, but I thought it might be useful. So, here goes nothing.

Let’s say you’ve got a game and its multiplayer mode can be played across 5 maps. We’ll also simplify things and say that we’re only ranking players on each map on XP gained when finishing the map. If you want to generate a leaderboard of players ranked by XP who have played in any of the maps, you would need to perform a merge of each of the leaderboards for the 5 maps. If you want to generate a leaderboard of players ranked by XP who have played in each of the maps, you would need to perform an intersection of each of the leaderboards for the 5 maps.

This functionality is now present in the Ruby leaderboard gem released today.

You can use the merge_leaderboards(…) call to merge the current leaderboard with any other leaderboards into a new leaderboard.

{% gist 843517 %}

You can use the intersect_leaderboards(…) call to intersect the current leaderboard with any other leaderboards into a new leaderboard.

{% gist 843527 %}

Hopefully you’ll find this functionality useful.

You can find more hilarity over on my Twitter account, CzarneckiD.

Feb 24

Your Definition of Success

By Mike DelPrete

I have been called many things in my life. Most recently, some have called me a “successful entrepreneur.” I am introduced to people as the CEO of a “successful business,” or prompted to tell classes of my “success story.” But what is success?

Success can mean many things to different people. I like to use the phrase “depending on your definition of success” when talking to people looking to start a business, because that definition changes everything.

For some it might be to create a billion dollar company. For others it may mean working happily with a handful or coworkers. Success is a multi-dimensional factor, and can be based on financial, personal, product, or legacy criteria (among others).

If you want to start a business, first figure out your measure of success. What are you trying to accomplish? Is it all about the people, the product, or just making money? What motivates you and what goal are you striving towards?

At Agora, I’ve defined success as many things. It’s doing high quality work that I’m proud of. It’s creating and maintaining a reputation as an awesome company to work for. It’s being profitable, so I can keep doing what I love.

To me, success is not about being a certain size, reaching certain revenue numbers, or doing a certain number of sales in a year. These are all a means to an end. For me – for Agora – success is having a job like no other; if I manage to create an incredible place to work, staffed with incredible people, doing incredible work, I am successful.

Feb 17

The Path of Iteration in Business

By Mike DelPrete

Entrepreneurs often ask me what the biggest factor was in our success. They want to know exactly what we did and how we did it so that they can duplicate that success. The truth is that there isn’t one thing, and there never is. You can never attribute the success of a multi-year, multi-person venture down to exactly one thing. However, there are factors that can help.

The advice I give to entrepreneurs is simple: just keep trying. Succeeding with a business is a result of hard work and constantly trying new things. Don’t put all of your eggs in one basket and hope it works out. Try something, get it out there, and repeat.

Many entrepreneurs are stuck on the notion of a “master plan.” They think of a huge idea with huge potential returns, huge risk, and a huge cost. In reality, no one can perfectly plan where the business will take you.

Instead of executing on a plan with a high risk and high reward, I encourage entrepreneurs to take baby steps. Interested in a particular market? What’s the quickest, simplest project you could do to take you there? Have a product idea? What’s the easiest and quickest way to develop a prototype? How can you get something out in a month instead of a year?

While not the single key to our success, adaptability has been a huge part of it. Take an idea, try it out, and learn from it. Instead of plotting out a 12-month plan to launch your business, focus instead of taking smaller steps in the general direction you want to go. The knowledge you gain along the path of iteration is well worth it.

Feb 11

Code Reviews

By Brian Corrigan

Everyone knows code reviews can be awesome. They can be agile, smart and effective, or they can be shallow and pedantic. They can be an hour-long laser-focused meeting on the points that matter, or a rambling mess of code reading to sleepy co-workers desperate for some cookies and a nap. I’m on the team that builds backend services for the latest and greatest games; we take code reviews very seriously, and we look forward to them. So how do we go about it?

We’ve developed two schemes for official code reviews, and each one serves a unique purpose. The first approach grew organically and is informal, whereas the second is a relatively new scheme that we’ve adopted and has already been very successful.

Our older code reviews are somewhat similar to how many other teams conduct their reviews. A major new piece of code is written, and if on general consensus it is deemed “important”, each person on our team, or at least 2-3 of us, are responsible for giving it a thorough review, writing down their notes and attaching them to a Lighthouse ticket. We schedule a time for review, and then gather as a group and walk through each and every item of note, discussing as necessary. Usually the original developer leads the review, though one of the reviewers may also lead the discussion. We typically use this style of code review for new modules and services which are deployed in development or staging, to be entering production “in the future”. It is the first pass review, intended to bring many eyes to bear on immature code, where only one or two people may have been involved in implementation.

We’ve adopted a more formal practice for services and modules entering production. For any given title which is nearing production, we list all of the services it is using, including ones that may be very mature. For each service, we assign two reviewers and one change implementor, preferably none of the people who originally wrote the module, though in a small agile team this can be open to interpretation or convenience. The reviewers each perform a rigorous analysis, covering everything from code to configuration, interaction with other modules and services, algorithm efficiency, test suite coverage and whether the entire package conforms to the latest team practices. Our standards continue to evolve, and so even mature services benefit from this continual review process. A third person, the change implementor, then applies the recommended changes as well as anything else they see as needing improvement. The reviewers then review the changes, recommend additional fixes, pass back to the change implementor, and so on, until all 3 individuals agree that the service is ready for production. We make liberal use of git branches to track these changes. Near launch day, a fourth team member is responsible for confirming that the production deploy is operational; configurations comply with the final requirements, databases and other datastores are setup as designed, and AMQP hosts are operating as expected.

In addition to these two formal schemes, we also use git and Campfire to continually review smaller changes. Each team member discusses their recent work in our daily standups and brings attention to code they think needs attention from others, and everyone takes part in reviewing changelists and recommending improvements as their schedules allow.

We’ve realized great benefit of these two approaches in combination. The former yields an informal but wide review of the code base, giving everyone an opportunity to understand the bleeding edge of our technology. Sometimes this includes learning an entirely new language or framework during the course of the review. The latter style yields a production-ready deliverable that has been approved by no fewer than 4 members of our team. In practice, the entire team has had a chance to either code a feature, review it, or implement changes, such that everyone can sign off that we are ready stand behind the coming tsunami of happy gamers playing the best new titles on the market. Both schemes allow individuals to thoroughly review the code at their own pace and according to their own schedules, so that group time is dedicated solely to discussing the items of importance. Everyone is involved in the success, proudly putting their signature on the final product even when their role in supporting a particular title may have been minor.