The Sledgehammer – Version 2.0

January 27, 2014

The Stupidest Idea I’ve Had All Week: Optimizing Delivery of Restaurant Baked Goods With Ballistic Devices

Filed under: Food, Random Stuff — Tags: — Brian Lutz @ 1:21 am

Last week, the Old Spaghetti Factory was celebrating their 45th anniversary by offering their various carb-based meals for $4 for a couple of days.  Me and my girlfriend decided to take advantage of this offer, and unsurprisingly, we found that we weren’t the only ones.  It took close to a 45 minute wait for a table to become available for us after we arrived, and even once we were seated we found the service to be somewhat on the slow side, presumably owing to the large crowds they were dealing with that evening (and no, I’m not complaining about the service, I figure that just comes with the territory when you go for this type of thing.)  Typically, when you start a meal at the Old Spaghetti Factory they bring bread to your table, but even the bread was taking some time to arrive this evening.  Being hungry after 45 minutes of waiting just to get a table, we were naturally getting a little bit impatient.  And when I get impatient, bad ideas usually tend to be the result.  And believe me, I’ve got plenty of those to go around.

It’s not like there was any lack of available bread in the restaurant, at least as far as we could tell.  A quick census of the other tables revealed that a significant number of them had received bread at some point prior, although we did not have any reliable method of determining the  TTB (Time to Bread) value for any except our own table.  Given the fact that the bread at this particular restaurant is typically served hot, it is entirely possible that the baking mechanisms could bottleneck the process at times of extreme volume (it is probably reasonable to assume that this would have been considered a time of high volume) but on the whole, it would seem that the bread supply on hand was adequate.  That would mean the most likely delay in bread delivery to our table would have been the delivery itself, which depended on a server who was presumably too busy dealing with his other tables to deliver bread in a timely fashion.  Surely there has to be some way to speed up this process.

It was about this point that we recalled an incident that happened on one of our Disneyland trips last year.  While wandering around the Pacific Wharf area of California Adventure, we came across the Boudin Bakery, where a number of people were inside preparing what appeared to be bread bowls, presumably for clam chowder or something similar.  We paused for a minute at the window and watched, when suddenly someone inside tossed one of the bread bowls at us.  Fortunately there was a window between us and the flying carbohydrate projectile, but it startled the heck out of us, and months later, we still joke about the time that we went to Disneyland and they threw bread at us.  But upon recalling this, it occurred to us that this could, in fact, be a significantly more efficient way of transferring bread from oven to consumer when compared to the current methods.  Some further research on this subject reveals that I’m not the first person to have this idea.  Lambert’s Cafe, founded in Sikeston Missouri with additional locations in Ozark Missouri and Foley Alabama, has been throwing bread at people for decades.  As you can see from the video below, this is a very efficient method of bread delivery.

Then again, even though setting up a cart in the corner and getting a guy to throw rolls at customers works well in a down-home place like Lambert’s, in a modern high-volume foodservice environment you’re going to need something a bit more efficient than that.  Fortunately, we have plenty of sources we could borrow from for this type of thing.  A quick search reveals that there have been literally hundreds of years of research put into the subject of placing objects in precise locations on a ballistic trajectory.  There are also quite a few time-tested methods of delivering ballistic projectiles to precise locations, any one of which could possibly be adapted to the application of delivering bread in a foodservice environment.  Granted, most of this science behind this type of thing tends to be concerned more with things like heavy boulders and high explosives, but I’m sure some of the existing research could be adapted to baked goods if necessary.  You would probably need to figure out a few minor details like mass, avoiding obstacles and not demolishing the tables and/or restaurant patrons with your bread-delivery system, but I’m sure those problems could probably be sorted out in a year or two.  Targeting could also be an issue, since the average restaurant server tends not to be well acquainted with the art of ballistics.  Fortunately, I think this problem tends to be fairly easy to solve.  After all, most restaurants tend to keep their tables in well-defined fixed locations, so if a pre-programmed computer controlled trajectory could be established for each table and/or seat, then you could ensure reasonably consistent  placement of the baked goods, although for a number of reasons (primarily variance in the mass and aerodynamic properties of the projectiles, as well as any air currents that might be present) within the restaurant) I think you would probably still need to allow for about a 5% margin of error.

There are also some inherent problems with applying this type of solution to existing restaurants, as it turns out that a shockingly small number of the restaurants opened in the United States in the last 50 years have taken projectile physics into consideration in their designs, which creates some challenges when it comes time to integrate a ballistic baked good delivery system into an existing restaurant.  Perhaps the biggest obstacle faced by the designers of such a system is how to deal with ceilings, which would tend to artificially limit the allowable height for projectiles.  In theory the baked goods could still be delivered to their targets on lower trajectories that will keep them at more acceptable altitudes, but this would also require more power to be applied at the launch end, which could result in some complications (including but not limited to spilled drinks, bruising, broken bones, tooth loss, unsightly dents in restaurant walls and/or shattered bottles of top-shelf liquors if a projectile intended for a bar patron goes off course.)  Ultimately, retrofitting an existing restaurant for ballistic bread delivery would ideally involve raising the ceilings to allow for higher arcing trajectories that are less likely to encounter interference from existing fixtures.  Determining the optimal trajectory for each table in a given establishment would also be a matter of trial and error.  Unfortunately, a lot of the existing science on this type of thing tends to be based on the assumption that the intended targets for most ballistic projectiles are intended to be demolished by said projectiles, a condition which is generally considered undesirable in a foodservice environment.  Then again, most baked goods tend to have relatively low mass when compared to most ballistic projectiles, so with a few minor countermeasures to arrest excessive velocity at the receiving end I’m sure something could be worked out that would deliver (mostly) intact bread on a reasonably consistent basis.  More research is clearly needed on this subject.

Then again, I’m not an engineer, and most of what I happen to know about ballistics comes from Wile E. Coyote cartoons and playing Scorched Earth as a kid, so I’m sure there are factors in play here that I have failed to properly consider.  All I know is that there are significant inefficiencies in the current foodservice bread-delivery paradigm, many of which can be solved with the judicious application of physics.  But what if you want butter with your bread?  Well, I guess the engineers still need to figure that one out.

January 19, 2014

We’re Only at Home When We’re on the Run

Filed under: travel, Wanderings — Tags: — Brian Lutz @ 12:43 am

(Optional soundtrack for this post, if for no other reason than the fact that I’ve had this particular song stuck in my head for most of the past month.)

Although I’ve done a fair bit of traveling over the years, there’s no doubt that 2013 is by far the most traveling I’ve done in one year.  In addition to the usual commuting back and forth to work and wandering around the local area, I’ve been on seven different trips of various lengths over the course of the year, and over the course of my travels I have been as far as 4,200 miles away from home.  Granted, most of my trips have been much shorter than that, but with two trips to the East Coast, thirteen days spent at sea and a number of other interesting little side trips along the way, it occurs to me that I’ve probably put in quite a few miles over the course of the last year.  Even though I don’t expect to be doing nearly as much travel this year as I did last year, I thought it might make an interesting exercise to try to figure out just how much traveling I actually did last year.  If I count all the different methods of transportation I used to get around over the course of the year (including ones such as walking and riding the bus) it becomes just about impossible to get an exact amount (it’s not like I’m keeping track of all this stuff very well) but for things like air, sea or rail, it’s actually pretty easy to figure out the distances involved.  With that in mind, I’m going to make a (quite possibly misguided) attempt to estimate just how many miles I traveled across all of the various modes of transportation I used last year.

Driving:  This is probably going to be the least  accurate part of this, since I haven’t really kept track of this all that well.  That means I can’t really do much better than an educated guess.  I figure that in an average year I probably drive somewhere between 10 and 12 thousand miles, give or take a thousand or so.  I’ve owned my car for just about 6 1/2 years now, and have somewhere in the neighborhood of 68,000 miles, which averages out to about 10,460 miles or so per year.   Nonetheless, I feel like I’ve done more driving than that over the past year, since I do commute to my job in Downtown Seattle and back at least a couple of times a week, possibly more.  Back when I worked in Downtown Bellevue a couple of years ago and didn’t need to drive at all to get to work and back, I know that the overall usage on my car was significantly lower.  Ultimately it averages out, but just to keep things convenient I’m just going to say that I drove (or rode in other people’s cars) for around 12,000 miles last year.  During the last year I didn’t go on any roadtrips in my own car, and I don’t recall having my car more than about 50 miles away from home at any given time.  Typically those would be included in the overall total, but since there weren’t any to speak of, I don’t need to account for any.

Of course, that’s only what I drove in my own car.  On the various trips I’ve taken in the past year, I figure I’ve put in a decent number of miles in various rental cars as well.  Between three different trips to Disneyland (which I figure typically involve around 300 miles or so, based on roughly a 100-mile round trip between LAX and the place we stay when we go down there, 3-4 days of a 50-mile round trip between the condo and parks, plus another 50 miles or so for miscellaneous driving (sightseeing, trips to the store, etc.)  to make a total of about 350 miles per trip.  There were also a couple of other trips (a quick weekend business trip to San Jose, plus the days before and after the December cruise in Florida) where I drove rental cars, but generally didn’t drive nearly as much on those ones.  I’ll estimate about another 200 miles of driving total for those two trips (although I suspect that number is high.)  I suppose if I ever bothered to keep the receipts for these trips I’d be able to get more exact numbers here (apparently the rental car companies are a lot more meticulous about this type of thing than I am) but since we’re pretty much working off estimates here this works.  If I add all this together, I come up with a total of around 1,950 miles driven in rental cars.

In addition to driving in rental cars, there was also the trip to Atlanta back in May for my brother’s wedding, followed by a road trip up to Charlotte, North Carolina to see a NASCAR race and back.  The shortest route between Atlanta and Charlotte would be I-85 (which is the route we took back to Atlanta afterward, roughly 266 miles) but since the wedding reception was in Augusta, we ended up taking a different route that took I-20 to Columbia South Carolina, then I-77 from there to Charlotte, for a total of around 344 miles.  Given the drive to Charlotte and back, plus miscellaneous driving for various things along the way (including a day spent in the Charlotte area touring around the various NASCAR teams’ race shops,) I estimate this trip to have been roughly 700 miles total.

Given all of the various driving and riding in cars I’ve done over the course of the past year, I’m going to estimate a total of somewhere around 13,950 miles traveled by car (both as a driver and as a passenger) over the past year.  Since I figure I’m probably not being very precise with this anyway, I might as well just go ahead and round that up to make it an even 14,000.

By Mass Transit:  In addition to driving, I also frequently commute by bus as well.  This is another one that is somewhat difficult to accurately estimate, but fortunately there’s at least some record keeping going on here, thanks to the ORCA card that I use to pay my bus fare.  if you look on the ORCA website, you can find a record of all the bus rides you’ve taken for a specified period of time.  which means that I can see that I rode on Metro and SoundTransit buses 207 times during 2013.  I can also see which buses I rode on.  Most of the time the bus I ride is either the 212 or 554 that goes to and from the Eastgate Park and Ride, and these two routes (and related routes with different numbers but which follow basically the same routing) accounted for 177 of the 207 trips.  By my estimate, each trip on this route is roughly 9.8 miles in each direction, for a total of 1,734.6 miles.  In addition to that, I also took 24 trips on route 550 (which is the direct bus from Downtown Bellevue that goes to Seattle.  If I take this one I don’t have to drive to the park-and-ride, but I also find it generally takes 10-15 minutes longer in each direction if I take this one than it does if I take the 212/554)  By messing around with some of the routing tools on Bing Maps, I can estimate that this route is roughly  11.5 miles for each trip, for a total of 276 miles on Route 550.  I also rode twice on Route 522 (a round trip from Kenmore Park-and-Ride to Downtown Seattle and back, about 15 miles each way) and there are 4 other trips I can’t be certain of (I think they may have been local trips in Downtown Seattle, I’ll just ignore those.)  I also rode once on the Light Rail from International District to Sea-Tac Airport (about 14.5 miles.)  If I add all these together, it comes out to an estimate of 2,055 miles total (give or take a couple) riding on mass transit last year.  I suppose if I really wanted to get nitpicky here (well, more so than I already am) I could probably try to figure out the distance I rode on Disneyland parking shuttles or the free trams they provide in Laguna Beach during a visit there, but that just makes my brain hurt.

By Train: This one’s actually pretty easy to figure out.   I took one train trip last year from Vancouver BC to Seattle aboard the Amtrak Cascades following the cruise we took in May.  According to the Wikipedia Article for the Amtrak Cascades, the distance from Vancouver to Seattle by rail is 157 miles.

By Air:  Perhaps not surprisingly, this ends up being where most of the distance traveled in the last year comes from.  Fortunately, it’s quite easy to get a fairly precise distance for all the flights I took last year, since  the various resources offered to frequent flyers for the purpose of figuring out their miles make it easy to find distances between airports, including connecting flights.  Based on the various flights I took last year, this is what the distances would look like:

  • SEA <-> LAX (3 round trips:)  1,908 miles roundtrip x 3 = 5,724 miles
  • LAX -> SFO -> SEA (one trip, one way:) 1,016 miles
  • SEA <-> ATL (1 round trip:) 4,360 miles
  • SEA <-> SJC (1 round trip:) 1,392 miles
  • SEA -> ATL -> FLL (1 trip, one way): 2,762 miles
  • FLL -> MSP -> SEA (1 trip, one way:) 2,880 miles

When I combine all of these together, I come up with a grand total of 18,134 miles traveled by air in 2013.  At this rate, I suspect that I might even manage to get a free flight with frequent flyer miles in another 3 or 4 years.

By Sea:  I suspect that most people don’t have this one on their list these days, but given the two cruises I was on last year, this accounts for a pretty significant chunk of mileage as well.  On the last day of each cruise, Princess Cruises provides each passenger with what is known as a Log of the Cruise, which describes where the ship has been and provides some statistics on the cruise, including the total distances between ports and the overall distance sailed.  It is from this that I get the distances for the two cruises I took last year:

  • Island Princess, Pacific Coastal (3 days, Los Angeles to Vancouver, no port stops:) 1,718 statute miles, 1,494 nautical miles
  • Emerald Princess, Southern Caribbean Medley (10 days, Roundtrip from Fort Lauderdale, stops at Eleuthera (Bahamas), St. Thomas, Dominica, Grenada, Bonaire, Aruba:)  3,565 statute miles, 3,100 nautical miles

Between these two cruises, this comes out to a total of 5,283 statute miles (4,594 nautical miles) traveled by sea last year.  Not that I was paying much attention to any of them…

Unless there’s something I’m forgetting here, this should account for all the traveling I did last year, both at home and abroad, by land, air and sea.  Now to add all of this up:

  • By car (both driving and as a passenger): 14,000 miles
  • By mass transit:  2,055 miles
  • By train:  157 miles
  • By air:  18,134 miles
  • By sea:  5,283 miles
  • Total: 39,629 miles

So when all was said and done, I came up with a total of nearly 40,000 miles traveled last year, which would be enough mileage to circle the Earth nearly 1.6 times.  That seems like an awful lot of traveling, but I do also know people who can end up traveling twice that many miles in a year on a regular basis (one of my friends did a two-week trip to Southeast Asia by way of Australia last year, plus another trip to India for work, and those two trips by themselves would probably come close to matching my whole mileage total for the year) whereas this past year was a fairly unusual one for me in that I did a lot more traveling than I usually do.  I do plan to continue traveling this coming year, but I seriously doubt I’ll be putting in quite as many miles.  On the other hand, I never know just where I’m going to end up.  After all, these things seem to have a tendency to sneak up on you when you’re not looking.

January 11, 2014

What Software Testers Can Learn From Video Game Speedrunners

Filed under: Games, Quality Assurance — Tags: , , — Brian Lutz @ 2:53 pm

I see a lot of this when I attempt to play video games.

Over the course of the past week, I’ve spent far more time than I care to admit watching other people play video games far better than I could possibly do it.  Every year around this time, Speed Demos Archive puts on an event known as Awesome Games Done Quick, where a group of speedrunners gets together and plays games nonstop as fast as they possibly can for an entire week, streaming it online as a fundraiser for the Prevent Cancer Foundation (and a pretty successful one too, raising nearly $450,000 last year, and as of this writing the total for AGDQ 2014 is sitting at roughly $663,000 with about a day to go, plus whatever bonus streams follow the main event.)    For someone such as myself who has pretty much no skill whatsoever when it comes to anything requiring fast twitch reflexes, it is fascinating to watch this type of thing for several reasons.  First of all, the amount of skill being put on display by the various speedrunners is amazing.  And the second (and perhaps more compelling) reason is that as the various speedrunners go through their runs, they tend to provide a running commentary explaining what they’re doing as they go along.  And quite a bit of what they’re doing is, quite frankly, breaking the games.

But as I’ve watched the marathon and seen the types of techniques that speedrunners use, it has occurred to me that there are actually some things I can learn in my professional career as a software QA engineer from watching this type of thing.  Even though I don’t do anything related to games in my job (and only one or two things I have ever done in my career have come even remotely close to it) it seems to me that a lot of what of people do in the course of speedrunning games is quite similar to what I do in testing software, with one significant difference:  As a tester, I’m trying to find problems to get them fixed, speedrunners are typically trying to find them to completely break things.  And to be perfectly honest, I think the speedrunners might be winning on this one, judging from some of the ways they can take tiny little glitches and completely break entire games with them.  In most cases this has no real impact other than to beat games far more quickly than they were ever intended to be beaten, but we’re generally talking about twenty year old games here.  If you’re running mission-critical software in an enterprise environment and things like this are happening, you might find the impact of something like this to be far more problematic.  Naturally, it’s best to catch these types of things well before the software (be it a game or something more functional) goes out into the wild.  As such, I thought I’d put together a post that goes through some of the lessons that I have learned from watching speedrunners during AGDQ.


1. People will go to great lengths to make even trivial gains in performance.  Although the speedruns in AGDQ are compelling enough on their own, the part that really makes it interesting is the commentary that goes along with most of the runs.  Whether it’s coming from the speedrunner(s) playing the game or from providing a play-by-play from the couch, it quickly becomes clear that the people doing this stuff have put as much thought and effort into this as most people would put into far more serious subjects.  I suspect that the collective knowledge that has been gleaned from one of the more popular speedrunning games such as Super Mario Bros. could fill a book, or at least an article in an academic journal.  Nonetheless, even for games that have been well documented and well understood for years, people are still trying to find ways to shave fractions of seconds off their times.  In particular, one of the popular (yet somewhat controversial) categories in speed running tool-assisted speedrunning, also known as TAS.  Tool-assisted speedrunners use various tools to do things like run games a single frame at a time and use savestates to keep running through segments until they can figure out the optimal paths through or pull off difficult tricks, which allows them to eventually work toward what could be considered a fully optimized run.  In many cases, these optimized runs can be much faster (often by multiple minutes) than what even the best human players can manage, but they also tend to do this by using tricks that human players would not be able to do.  Nonetheless, the TAS players can find hidden strategies that can save time in regular speedruns, but at the same time can also be very difficult and/or risky.  It’s not uncommon to see speedrunners taking big risks on difficult tricks that might save them a fraction of a second if they pull it off, but can cost them much more than that if they don’t.  Speedrunning is by its very nature competitive, and at times it can be mere fractions of a second that can separate players in a racing each other on an hour-long speedrun (I don’t have a way to link to it yet, but the 4-way Super Metroid race from AGDQ 2014 is a very good illustration of this.)

Although this isn’t a scenario that necessarily translates to real-world software in the same manner (as you might imagine, when working with most types of hardware and software the goal is far more to reduce risk as much as possible than to reward it,) one thing I do typically see in the course of my daily workflow as a tester is that there are a lot of repetitive tasks that come up, not just in the actual testing, but in the course of dealing with the other associated tasks that come along with it such as bug tracking, test case management, setting up test environments and reporting results.  Although the use of automation in test case execution is widespread and can save significant time over manual testing in situations where it can be applied, I’m not dealing with much of it in my current job.  Nonetheless, even if you’re not automating  your test cases, you can probably identify little repetitive tasks here and there that you might be able to automate with something like a batch script or a macro.  Even little things that don’t seem like much can add up over time, and in the long run you can make significant performance gains out of little things.

2. Things that may seem random rarely are.  As you watch the various speedrunners going through their runs, one of the things they point out frequently is where things are or aren’t random in the games.  As you watch the various runs, you realize that at least under specific conditions, most seemingly random things aren’t actually random.  This is frequently important because a lot of the strategies (speedrunners typically call them “Strats”) depend on certain things happening at certain times.  On the flip side of the coin, random events tend to be a hindrance, as they can interfere with things often.  Mostly through exploration using TAS and other playthroughs of the game, it is possible for them to determine what is going to happen when, and also to figure out ways to precisely control the circumstances in which certain things happen and manipulate them to their advantage.  While testing software, often one of the biggest challenges testers face is trying to come up with consistently reproducible scenarios for bugs that have been reported because you have no way to verify if you actually fixed a bug if you don’t have a reliable way to get that bug to manifest itself in the first place.  This can be difficult, especially for bugs that may have been seen only once or twice, or issues that have been reported by non-technical users who provide only limited information and in a production environment where you might not have access to the debugging tools you’re used to having on your test bench.  It is for this reason that you need to be familiar with the environment you’re working in, and that you know what circumstances might lead to one particular code path instead of another.  If possible, you also want to have ways to collect at least some sort of data from low-information users in situations like this.  In many cases, understanding what circumstances might cause certain unwanted behaviors to occur in a piece of software can be largely a matter of determining the state of the environment at the time the problem happened.  Granted, this can require going rather deep into things, but speedrunners (and especially TAS runners) have gone surprisingly deep into the games they’re speedrunning, and have managed to do some rather surprising things, as this tool-assisted run of Super Mario World from AGDQ2014 illustrates.  It starts out unusual, gets downright weird, and goes…  Well, you’ll just have to watch.

3. You’re always going to miss something no matter how much testing you do.  The vast majority of games being played in the AGDQ marathon were some of the best-selling and best known games of the time when they were created.  Although the tools and services available today to game developers has allowed many smaller indie developers to put out products that can rival the big-name studios, in general a lot of games being shown were produced by rather large teams of developers, testers, artists and other support staff, often across multiple companies.  That means that by the time these products made it to the store shelves back in the day (something that has, ironically, become less and less of a reliable indicator of a product’s quality as console technology has reached the point where patching has become not only possible but practically expected)  they may have had hundreds of people involved along the way, including large numbers of testers dedicated to finding and reporting bugs to be fixed.  In spite of all that, the speedrunners still manage to find glitches, exploits and other bugs.  Not all of these are necessarily going to be useful for reducing speedrun time (in fact, a lot of these don’t do much more than crash things.) but these can be little things, big things, or somewhere in between.

Of course, very few of these glitches are things that a player going through the course of the game in the intended manner would ever run into (a lot of them involve finding ways into areas that the player is not supposed to be able to go into,) but unless they’re specifically restricting themselves to this, most speedrunners are going to use every glitch they can manage to get.  And I’m sure that there are developers and testers out there who have smacked themselves in the head after seeing some of the stuff that the speedrunners have pulled off in their stuff.  In the course of running a test pass on a game like the ones featured here, a lot of the scenarios where the glitches appear would be considered edge cases, which are things that very few users would even go anywhere near.  The main problem with these edge cases is that you’re generally wandering well off the “happy path” that normal users would be on, and in general the returns on these test scenarios tend to be very low in terms of the amount of time spent running them.  Then again, if you aren’t going to find the problems here, there’s a very good chance that someone else will gladly find the problems for you.  And you’re probably not going to like the results when they do.

4. Anything that is deemed unnecessary will be skipped one way or another.  During this year’s AGDQ, one of the featured runs was for Resident Evil 4, a game that I’ve never played (it’s not the type of genre I’m interested in) but which was still quite interesting to watch.  One of the biggest things I took away from this particular speedrun was that the player basically just ran right by probably 75% of the enemies in the game without a second thought, and suffered no ill consequences for doing so.  A lot of these fights would likely be rather difficult (and time-consuming) if the player was to actually do them the way the developers intended, but oftentimes it turns out to be completely unnecessary, as they just run right by and keep going.  Of course, in a speedrun saving as much time as possible wherever possible is crucial, so a lot of effort goes into cutting out even trivial things.  In particular, cutscenes and dialog are frequent targets of speedrunners, who will often take rather unusual steps to keep them from happening or exit them as quickly as possible.  In some cases, you’ll see people literally reset the game or quit out and reload in the middle of a speedrun, because starting from scratch and reloading from a save can in some cases be much quicker than watching a cutscene.  As long as the established ground rules for a particular game allow it, this is considered perfectly normal.

Another thing you see that happens quite a bit is that players will intentionally take damage in a lot of instances in order to use the temporary invincibility that typically goes with it  to bypass things.  In games, people tend to think of health or energy (or even lives) as something they have to try to keep as much of as possible, but speedrunners tend to treat these things primarily as a tool.  In particular, games like F-Zero GX (one of the most notoriously difficult games in recent memory, and one of the major highlights of the past couple of AGDQs as speedrunners have absolutely destroyed it) give you an energy bar that acts as both your health meter and something that can be consumed as a boost, allowing you to go faster but significantly increasing your risk of failure by doing so.  Then again, this is a normal (and expected) mechanic of this particular game, but taking intentional damage to bypass obstacles and improve speed is surprisingly common in many speedruns, especially for 8-bit games like the Mega Man and Ninja Gaiden series.  In some games, strategically placed intentional deaths are a common occurrence as well if some advantage can be obtained by doing so.  Then again, most players need to use that health and those lives just to keep themselves from hitting the game over screen too soon, so a lot of this comes down to having enough skill in the first place to avoid unintentional damage as much as possible, since it becomes a lot riskier when people play this way.  This means that in addition to all the various strategies and optimizations involved in the whole process, there’s also quite a bit of raw skill required just to even be able to think about speedrunning a game (of course, even if you can’t do live speedruns you can always try to do TAS, but that’s basically something entirely different.)

5. If there’s a way to pull things off the rails, someone will find it.  In many ways, this really ties into #4, but I feel it should also be considered separately.  One of the most popular genres of games for speedrunners is the so-called “Metroidvania” games (of which the 2D Metroid and the non-linear Castlevania games such as Symphony of the Night are the most prominent examples,) which typically are played on large non-linear maps but ultimately still have a linear progression that the user is expected to follow.  Of course, it is possible to follow this linear progression and do a speedrun that way, but most of the time the goal is to finish things as quickly as possible no matter how this is accomplished, so when a new game of this genre comes out, the first thing the speedrunners do is try to find so-called “sequence breaks,” which are strategies that allow the player to subvert the expected linear progression of the game and skip significant portions of the game entirely and acquire items that they aren’t expected to have  until much later in the game.  Of course, it’s gotten to the point that a lot of developers these days just hide intentional sequence breaks into the games, but in most cases these have come about as a result of players messing around with things they aren’t supposed to be messing around with, trying to actively subvert the intended order of the game. 

The effort that goes into testing a particular piece of software is as much a matter of planning as it is execution.  After all, you (generally) have a specific set of requirements that the software must be able to meet, and you need to be able to demonstrate that the software can meet those requirements.  And these days more than ever, security testing becomes a very important part of those test plans.  After all, no matter what type of software you are working with, it’s highly likely that someone out there will be trying to find ways to get around whatever limitations happen to be in it, especially if you’re dealing with any system that stores sensitive data.  But even aside from that, you can find yourself surprised by some of the things you’ll see users try to do with your software, things you would never expect.  As you go through the various test passes and validations that you might do over the course of a software development life cycle, you start to develop a surprisingly deep understanding of how things tend to work in the system, even if you aren’t working directly with the code.  As a result, you tend to build a bit if an intuition for some of the unusual things users might try somewhere along the line.  Don’t hesitate to try some of these things out; you never know just what kind of weird issues you might manage to run into.  Not that all of it will necessarily get fixed (after all, developers’ time is a finite resource, and you eventually have to ship something) but if you can think of it, chances are that at some point someone else will do the same.

All things considered, there’s actually a surprisingly large correlation in the methods used by speedrunners and software testers for their respective tasks.  In both cases, people are going deep into the inner workings of the software they’re using to try to find things that don’t work the way they’re supposed to.  Both use a lot of the same methods, and both find a lot of the same issues.  It’s how these issues are used where things tend to diverge though.  As a tester, it’s naturally your job to find these issues in order to get them fixed.  As a speedrunner, you’re trying to find issues that you can use to break things even further.  Either way, the results can be fascinating to watch.

January 1, 2014

Statistical Overview of 2013

Filed under: Site Stuff — Tags: — Brian Lutz @ 1:44 pm

Once again we have come to a new year, and as I typically do at this time of the year, it’s time for me to do my semi-annual statistical overview post (the other post typically gets posted on June 6th, which is the anniversary of when I started this Blog.  As usual, I post this mostly for my own benefit, so I can go back and look at this data later on and see where I’ve been and where I’m going.  As you can see, traffic overall continues to decline compared to where it has been in previous years, but still holds reasonably steady.  Since I long ago gave up any pretense of ever trying to make any money doing this type of thing this isn’t a big deal, although I do tend to think I write better when I’m writing for an audience, which is my main motivation for writing this Blog in the first place and continuing to do so.

For those of you who are still reading this and who continue to do so, I thank you once again for your continued visits to this Blog.  I have no intention of giving up on this anytime soon, and should have some interesting stuff coming up over the course of the next year.

  • Total Posts(all time, including this one):  629
  • Total Comments (all time):  970
  • Total  Page Views (all time):  286,361
  • Total Page Views in 2013: 32,446
  • Total Page Views in 2012: 42.260
  • Total Page Views in 2011: 42, 742
  • Total Page Views in 2010:  52,228
  • Total Page Views in 2009:  60, 939
  • Total Page Views in 2008: 50, 219
  • Average Visitors Per Day in 2013:  89

Top Posts\Pages (Last 365 days:)

Title Views
Sampling the Whitman’s Sampler: A Guide to America’s Favorite Box of Enigmatic Chocolates 7,147
Home page / Archives 3,896
Retail Wasteland – A Tour of the Totem Lake Mall 2,348
Malls of the Seattle Area: A Tour of the Factoria Mall 1,359
Wandering Off the Beaten Path at Princess Cays 1,311
An Example to Others: A Short Story 994
Ya Wanna’ Buy a Watch? A Visit to St. Maarten 990
The Redmond Costco Moves Forward (Updated 9/9/09) 960
A Tour of Crossroads Bellevue – Part 1: The Mall 870
A Concise Guide to Surviving Disneyland: Dubious Advice From a (Somewhat) Seasoned Disneyland Veteran 822
A Not-So-Standard Chevron Station (Updated) 813

 

Top Posts\Pages (All Time:)

Title Views
Home page / Archives 59,449
Retail Wasteland – A Tour of the Totem Lake Mall 30,641
Sampling the Whitman’s Sampler: A Guide to America’s Favorite Box of Enigmatic Chocolates 24,929
Malls of the Seattle Area: A Tour of the Factoria Mall 12,126
Classical Gas – Abandoned Route 66 Gas Stations 11,705
A Tour of Crossroads Bellevue – Part 1: The Mall 8,400
The Redmond Costco Moves Forward (Updated 9/9/09) 8,156
My Very Nearly Award-Winning Chili Recipe, and Other Deep Dark Secrets 6,368
Malls of the Seattle Area: A Tour of The Everett Mall 5,490
A Brief Tour of the Bellevue Galleria, Bungie’s Future Home 4,849
The Beginning and the End of the Old Bellevue Safeway 3,843

Create a free website or blog at WordPress.com.

%d bloggers like this: