Riot Games is the powerhouse developer behind League Of Legends (LoL), the most played video game in the world. Due to the intense passion Riot has for both their game and their players, they are growing at a staggering rate. In order to stay focused on delivering a quality in-game experience to their worldwide community, Riot needed an outside team to focus on forward thinking greenfield online projects. However, finding a team that could answer the call was difficult. Not only would the team need to deliver Riot quality, at Riot scale, consistently and quickly; they would have to “drink the culture koolaid” and function as an integral part of the Riot team.
The team at MadGlory has over 15 years of experience in the gaming industry. In order to deliver for Riot, we assembled a crack squad of designers and engineers each of which had prior experience building online gaming products to support tens of millions of players. The team used cutting edge technology like Riak, Redis, and Node.js to deliver on Riot’s vision.
In addition, we adapted our practices, tools, and schedules to match the way the team at Riot works. Last, in a display of great individual sacrifice, we forced ourselves to play hundreds of hours of League Of Legends in order to ensure that we were versed in both the mechanics of the game as well as the the motivations behind the largest gaming community in the world (tough work, we know!) GG! « Back to Case Studies
Stuck refactoring code in an unwieldy Rails project? Check out ‘Rails Antipatterns’ by Chad Pytel and Tammer Saleh. It contains real world examples of, and proven solutions for, code smells that may hint your code is heading down the wrong path. From models, through controllers, and up to views it shows how you can both effectively avoid pitfalls in new projects and dig yourself out of holes that have made their way into legacy codebases.
One example of such a solution is pushing find methods into scopes contained in the model. This simple pattern doesn’t just help cleanup code by encapsulate functionality, but makes code more reusable and maintainable.
If you’re looking for a quick read with a great return, checkout ‘Rails Antipatterns’ today!
Being confident about what you do can be a real stress reliever, but I think it also helps in terms of communicating effectively and producing efficiently. One way of building self-confidence is by learning or improving upon your skills. That is one of our core values at MadGlory: constantly improve yourself. Jumping into the deep-end can be exciting and is definitely one way of learning, but there are also a plethora of books, screencasts, and blog posts from industry folks who have first-hand knowledge of pretty much any problem, language, framework you can think of.
I have been following Avdi Grimm‘s Ruby Tapas screencast series (awesome little tips and techniques) for a while now, and I recently picked up his latest book entitled Confident Ruby. To be honest, a blog post wasn’t my original intent when I began reading, but after the first few chapters the idea that we should be developing ourselves as much as the applications we make kept coming to me.
Aptly titled, the overall theme of Confident Ruby is to build self-confidence, but it does this from the most basic level – the method. Each chapter is about one of a method’s four roles (collecting input, performing work, delivering output, and handling failures) and many of the various patterns that each of the roles follow. Finally, there is a chapter about refactoring by applying the techniques taught in previous chapters.
Learning how or more effective ways to use new frameworks and plug-ins is great, but getting down to the very core constructs of a language is fantastic. I’ve really enjoyed the book so far and have definitely learned a bunch of (and been reminded of a few) awesome ways to think when putting my fingers to the keyboard and designing my code. I’d highly recommend this book to beginners and seasoned Ruby developers alike.
Object.freeze() forces me to define all of my constants in one place and stops me from modifying them later on. Give it a shot sometime and see how it works out. Let us know if you have any other cool tips like this!
We opened our first studio in October 2012. Our main criteria for choosing the location was price and convenience; we wanted something we could afford that was walking distance to all the bars (and, um, coffee shops) in downtown Saratoga Springs. The office was 900 sq/ft (with 650 sq/ft for working) and had more than enough room for the five of us that were working here at the time.
Fast forward a year, and we’ve more than doubled our full time staff. We’re over fifteen if we count the part time staff as well. The old office simply wasn’t big enough. In May we set out to find a new location to fit our growing team. Our new location is just under 3000 sq/ft and should last us for a few years. We have a dedicated (quiet!) work space, a bathroom with shower for the folks who bike in, a full size conference room, and a recreation room with a wet bar. We have a lot of open space still yet to fill, but we’re taking our time. The biggest problems so far:
Our new chocolate hardwood floors show footprints
I can’t high five Clarke without first walking to his desk
My desk feels small
Seth can’t turn his monitor to show us his in-process design work
Dungeons & Dragons Online (DDO) is a massively multiplayer online game originally released in 2006. The game was created by Turbine Games and published by Atari.
The game was originally subscription only. In 2009 Turbine announced a free-to-play option would be available and increased the level cap to 20. This model has been quite successful, with revenue reportedly tripling after the change.
The original site was built and launched in 2006 in conjunction with the game. 7 years is a long time for a site not to get revamped. This is where we come in. The goal was showing game art as well as prioritizing important information for the DDO player community.
In conjunction with the latest expansion pack the company decided to reboot it’s community website located at ddo.com. We were tasked with doing a complete overhaul of their website with a new design and migrating content and users into a modern platform. We worked closely with Turbine and their community manager to create the best site possible for DDO fans.
Since the original site was expanding with content for 7 years it was a priority to perform a content audit and make some decisions on what was the most important for player experience. In the end we highlighted updates on their homepage as well as character classes and races. All of this was accomplished using a Drupal theme with custom content types.
Similar to LOTRO we built a custom Ruby migration script to move their vBulletin users to the latest and greatest version.
At the end of the project both Turbine and the DDO community were thrilled with the results. Just another happy MadGlory customer. Next! « Back to Case Studies
In order to focus on the future, Turbine needed help supporting their most popular current title Lord of the Rings Online (LOTRO). The project required expertise in data processing, online gaming systems, and web-based community tools like Drupal and vBulletin. In addition, the project would require expertise in popular DevOps tools like VMWare and Chef.
In order to deliver for Turbine, MadGlory handled a series of design and development tasks required to modernize LOTRO’s aging web community. Similar to DDO, we built a custom Ruby based data pump to migrate existing user data for millions of passionate players, cutting the required down-time from days to hours. Finally, MadGlory built a series of new functionality on top of one of the LOTRO community’s favorite online features; daily lotteries.
The result? Players are happy, Turbine is thrilled, and MadGlory chalks up another win.
Those who have done it understand this advice at an almost visceral level, but it bears repeating that successful software startups almost always give the same advice (see the old article on scaling Instagram), namely:
Clever code is complex code. It costs more to create, it costs more to change. Don’t be overly clever.
Don’t plan too far ahead, conditions will change around you before you would ever benefit.
Focus on simple, easy to understand, easy to change systems.
Hardware is almost *always* cheaper and faster than building software, though this is often counter intuitive.
Speed of iteration is everything. Be razor focused on shipping.
I’ve read a similar list to dozens of customers and various engineering teams in my career. Each time everyone nods and looks bored; everyone has read the same literature at this point. With that said, when you’re in the thick of things many people throw these concepts out the window. In the real world:
Team members call multi-hour planning meetings to resolve a technical disagreement (where I’d advise each of the warring parties to go spike out a solution)
People start getting worried about “technical debt” and “code quality”. Dirty code feels dirty.
My advice: If you’re feeling uncomfortable about your startup, you’re probably doing it right. Decide on your list of values early on (at the stage when everyone looks bored and nods their head) and staple it to the walls around the office. Once you get into the development phase, point at the list whenever you see a dip in velocity. Ship.
When you use a tool all day (every day) you get tired of typing the same things again and again. I use the Fish Shell which already has great auto-comple and auto-suggest features, so I don’t need to get too creative. With that said, who doesn’t like to save a few keystrokes! I stick the following in my ~/.gitconfig file:
st = status -sb
ci = commit
br = branch
co = checkout