This is mostly just a placeholder for now, I ran all the game results for the 2012 season through a simple ELO generator I wrote. Here are the preliminary results:
American League National League
OAK 1320.1 ATL 1266.43
BAL 1286.49 SF 1266.01
LAA 1274.66 WAS 1261.66
TB 1271.04 CIN 1238.35
NYY 1270.66 MIL 1230.31
DET 1249.01 PHI 1226.64
TEX 1237.41 SL 1223.88
SEA 1198.28 LAD 1219.55
CWS 1189.35 SD 1216.5
TOR 1175.02 ARI 1188.84
KC 1164.9 NYM 1139.73
MIN 1126.35 COL 1129.06
CLE 1116.02 FLA 1121.09
BOS 1105.49 PIT 1116.45
HOU 1089.87
CHC 1080.85
These numbers are a straight win/loss record ELO with a K-rate of 15 and nothing else taken into account. I'm going to try and find time to make some sensible adjustments for things like home/away advantages and possibly scale the K-rate as the season progresses.
Nate Silver did something very similar a while back that can be found here: http://www.baseballprospectus.com/article.php?articleid=5247 but hasn't really been kept up to date that I found, there may also be some additional objective measurements that can be used to improve it now.
Data from the one and only retrosheet:
http://www.retrosheet.org/gamelogs/index.html The information used here was obtained free of charge from and is copyrighted by Retrosheet. Interested
parties may contact Retrosheet at "www.retrosheet.org".
Edit: charts and graphs as promised
Charts and Graphs:
Distribution
ELO Distribution grouped by 25 points
The first graph is a distribution graph. In games like chess we'd like to see a nice bell shape indicating a normal distribution with a few really good players and a few really bad ones and the majority somewhere in the middle. For baseball though, that doesn't quite work. There could very well be 50% of the teams that are heads and tails above the rest and evenly matched amongst themselves. Trading or not signing stars in hopes of building for the future can leave a significant number of teams near the bottom as well.
Method
I initially did 2 Distribution graphs, with the first one grouping the teams by 50 points and the second grouping them by 25 (shown above). While the first one looked like a bell curve with a chunk taken out of it the second is much more interesting as it really shows the divide better. The groupings were done starting with the indicated ELO and including all teams at that level up until the next one, so a team with 1149 would have been counted in the 1125 group in the above chart.
Analysis
There really seem to be 2 or 3 groupings of teams. Some (~9) bad teams, some(~8) average teams, and a lot (~13) of good teams, including one outstanding team: Oakland. This is more or less what I would have expected.
More to come...
Here's a sneak peek for AL East fans (you can use the slider on the bottom or zoom in out in the top left):
I promise I have some upcoming posts on some Arduino projects and gaming stuff, but while I was in Montreal last month for a Refused concert I was fortunate enough to catch some of the Just for Laughs festival.
Apart from great comedy the Just for Laughs festival really takes over a good chunk of downtown Montreal and features all kinds of events and buskers and cool stuff... and food trucks, delicious, delicious food trucks.
One of the really neat things that I almost missed (A friend actually noticed it) was the "Bar A Jeux", which, despite my tenuous grasp of the French language immediately piqued my interest. They had a dozen or so tables set up with umbrellas and chairs and a booth full of boardgames. We walked over to have a look and a super friendly young man asked us if we'd like to learn how to play a game.
I took a quick glance at the selection for something quick (we didn't have as much time as I would have liked) and noticed a couple copies of Zombie Dice on the shelf along side dozens of other dice/card games and even some more significant games like Agricola and 7 Wonders. Having seen Zombie Dice on an episode of Table Top and being interested in it as a quick game that my friend (not a boardgamer) might enjoy that was our selection.
The volunteers offered to come over and show us how it worked which would have been super helpful if I wasn't already familiar with the game. I asked if they needed my id or a CC number or something but they just said to bring it back when we were done with it, another small gesture that I appreciated. It was really nice to see how excited they seemed to help people learn about some of these cool new games and to see how many people seemed interested in sitting down and learning/playing.
Zombie Dice was a fun game, we played through 3 times while enjoying shade and a couple beer. The booth supplied a nice little dice box which made playing on the smallish tables very easy (Agricola might have been a challenge to fit).
After we were done I asked if it was possible to purchase a copy of the game from them and they said they weren't selling them but there were a couple games shops (and apparently a pub that has games which I really wish I had time to visit) around that sold them.
Next to the boardgame booth was another booth with wooden dice games and magnetic foosball/hockey type games and some neat puzzles. There was also a large game with a balancing platform and odd shaped blocks that people were playing with, like some sort of super-sized tip-it game.
I hope they bring this back for future festivals, even if I can't make it there it's great just to know that somebody is getting to sit out in the shade and learn a new game. Thank you Just For Laughs.
Pandemic is a very popular board game around the office, but there are a couple things about it that bug me.
First, I'm pretty competitive so even though this co-op game can be a real challenge I really wanted to find a way to pit players against each other (other than using the bio-terrorist role). The other thing that has always bothered me a bit about pandemic is that one or two vocal (hopefully experienced) players can often drown out the other players. I've occasionally considered granting each player a certain amount of time per round/game and using timers to limit an individual's vocal contributions but this kind of takes away from one of the most fun parts of a good game of pandemic, the interaction and debate.
A colleague of mine, Mike McGraw, proposed an interesting twist on the game that seemed like it might solve both of the above issues. We had multiple copies of the game, what if we could sync up the decks so that we could have 2 teams simultaneously playing the same game? Because of the way that pandemic works it would be relatively easy to have both teams get the exact same player and virus cards in the same order. This means that the decisions made by the teams would be the sole difference in the results of the games. A nice even playing field. We decided that the winning team would be the team that cured the most viruses, if both teams won, then the team that won first (real time, not turns) would be the victor. This incentivised both teams to play at a quick pace, but not a reckless one.
A nice side effect of having both teams play on the same (large) table and use the same card order is that at least at the start of the game you don't want to talk too loudly or too much about the cards you draw or the good ideas you have because your opposing team can also hear them and use that information. While I don't think either team used this advantage to any great degree in our game it's an interesting dynamic.
Once we decided to give this variation a try we didn't want to have to require an extra person on hand to do the initial deck sync and make sure the post-infection shuffles also resulted in the same ordering. Fortunately I work in an office full of talented programmers, one of whom (Luke Dewitt @whatadewitt) spent a couple hours building a web-app that takes a seed and generates a shuffled deck of pandemic cards, has buttons for drawing from both the player and virus decks and manages the actions required for infection events. We had 2 computers load up this app and input the same seed and the resulting play through is symmetrical (in terms of cards drawn).
Luke's Pandemic Card-Sync-app
To make it a little easier to get the app running in the limited time we had before playing we decided to remove a couple special event cards that can affect card drawing which could potentially break the drawing symmetry. Since you only play with a subset of the special event cards anyway this shouldn't be a problem.
The game itself went really well, my team had to restart after a missed turn early in the game, but this was easily accomplished using the app and the same seed and we quickly caught back up to where we were before. The game ended with one team curing the last virus and winning by being the first to do so. I'm confident that both teams would have won the game (we were playing with 4 infection cards for this initial play test) so the real-time aspect of the variation made the difference.
The 2 Teams and Boards
We plan on playing another game like this sometime soon, if it turns out I'll record it and post it here. I think everyone enjoyed the game and the new angle that the 2-team variation brought. One thing we've considered for future iterations is finding a way to track (or perhaps record) which moves each team made so we could review it post-game and find the turning points.
In particular I like the idea of picking a seed at random, generating a unique game and playing it either with a group or solitaire (Pandemic is a great solitaire game) and then sending the seed to a friend to see how they did with the same card sequence.
Thanks to Luke, Mike, Shawn, TJ, and Jamie for the great game,
When I was young I used to think about how much fun it would be to play SMK with a real bike. Now, many years later, we finally have the ability to create such a thing without a lot of very specific knowledge and tools.
Some of the things I used:
Arduino microcontroller (UNO)
A few transistors
Some pushbutton switches
A few resistors
A 2$ photo interrupter
An SNES controller
A very old stationary bike
A breadboard
Nothing there is overly expensive and none of it should require more then a little time and googling to figure out how to use. That said I'm not particularly experienced with electronics so there may very well be better ways to do some of this. (Actually I've found a few things I'd like to correct myself quite recently)
This was my 2nd Arduino project, the first being an n-back test game which I'll make a post about in the future (https://github.com/statuswoe/nBackGame).
There are two separate parts to this project, the first is finding an easy way to output from Arduino into the SNES and the second is having the Arduino recognize when the bike is being pedaled and when the buttons are being pressed.
Arduino to SNES
The SNES controller isn't particularly complicated, there looks to be a multiplexer and a couple resistors but little else. I wasn't able to find a really good diagram though. There is a description of the pinouts here: http://www.gamesx.com/controldata/snesdat.htm but I wasn't really interested in playing with a clocked signal when I didn't have to since I had an old SNES controller that I wasn't using. All I needed to do was put an NPN transistor across the points that the buttons contacted and I can fake a button press by applying voltage to the base pin, this was pretty simple.
My soldering is getting a little better, couldn't get much worse.
What I ended up with is a series of input pins that I plugged into my Arduino board and when I set them high the associated SNES button is triggered.
I mounted the project board and the modified controller into a small toolbox which was the cheapest container I could find that fit them both. The SNES connector comes out of one end and the Arduino connector comes out of the other. One of my goals was to make the SNES controller adapter entirely separate so that I can use it for other games/peripherals.
Bike to Arduino
The Handlebar buttons are pretty self explanatory. I used momentary push button switches that are on unless pressed just because I had some on hand. Because I'm running them into the Arduino I was able to invert the state in software.
The fun part was finding a simple way to track pedaling. I found a few caveats:
- Because the wheel doesn't stop when you stop pedaling and there are no real breaks I didn't want to use the wheel to track speed. I need to know when the user stopped pedaling.
- Running wire onto the pedal would be a pain because the pedal rotates relative to the bike so I'd need to set up brushes or something that wouldn't twist up when you pedal.
Because of these issues I decided to mount a photo interrupter next to the sprocket and have something attached to the sprocket at regular intervals that can pass through the interrupter and trigger the state-change. I ended up using 6 small pieces of playing card to do this.
Once the photo interrupter and buttons were hooked up to the Arduino I wrote some quick code to read the inputs and set the appropriate outputs to the SNES Controller adapter. The code is available here(and could use some polish).
I have the code and SNES Controller adapter set up to accept up, down, left, right, A and B, but I don't have the up/down hooked up to the bike yet because I'm not satisfied with the toggle switch I was going to use for it.
So in the end we have The Bike pushing data into Arduino, which does a little logic and sets some appropriate outputs which saturate the transistors to press the appropriate button.
EDIT:
Maicol asked for some more info on using transistors to control digital buttons, so here's a better image of that part of it, click on it for full size. The common ground is the red blocks, the blue side is the per-button input from the arduino (high to simulate the push). The NPN transistors bridge the path from the (green block) SNES controller wires to ground which the SNES reads as a button having been pressed.
The SNES is a bit odd in this sense, what you really want to do if you're using this for any other sort of input is put one side of the NPN transistor on the wire leading into one side of the button and the other side of the NPN transistor on the wire coming from the other side of the NPN transistor. You can then apply a charge to the middle pin of the transistor and it will act as though the button had been physically bridged. Hope this helps.
