ButtonWeavers blog

Those who have been on the site for a while will know that there are quite a few buttons that are not yet playable. Mostly, this is because a die or button skill hasn't yet been implemented. But sometimes, the reasons are more subtle. Two of the US States buttons, Arizona [k(7) g(9) (12) F(15) (X)] and Hawaii [n(4) m(5) k(8) F(13) d(Y)] have been disabled for the entirety of the time that most of the other US States buttons have been playable, since January 2016. And on a first glance, it would appear that these buttons should have been enabled for play, since all the component die skills were already implemented at the time. The story really starts in September 2015, when devious and irilyth found a konstant bug while testing the button Hawaii on the dev testing site. It turned out to be caused by the underlying code not correctly determining whether an attack involving konstant requires fire support. I submitted a fix for this, and as usual, Chaos ran her automated testing bot o...

Tournaments are coming! This will be one of the biggest changes to the ButtonWeavers site that we've ever made in one hit. The initial commit, which only includes very basic functionality (rudimentary UI, single elimination tournaments), requires changes to 22 files and the addition of 44 files. It involves roughly 5000 new lines of code, including 3 all new UI pages. The backend design of tournaments is intended to meet future requirements easily, including new tournament types button restriction better display of tournaments, tailored to each tournament type the ability to force the tournament to advance past idle games (no more bonefish ing!) automatic site generation of daily tournaments I'm excited, but there's a lot of testing yet to happen, and the look and feel of tournaments is likely to change a lot as we start using them. My hope is that tournaments will help people to get connected with others on the site more easily. I am looking forward to stumbl...

Once upon a time, there was a site where almost everything worked, sort of. And then things broke. You'll find the extended story of the resurrection of Button Men Online  here , but that story ends with the announcement that Button Men Online would be opening for testing by dedicated testers in November 2013. This is the continuation of that story. After we opened the website to testers, the developers pushed really hard — or probably more accurately, I pushed the developers really hard — to get the website to a state where we were willing to open it up to the general public, starting with players from the old site. Our  closed Github milestones  show that the website spent three and a half months in this period of closed alpha testing. In this time, we somehow managed to close 162 issues, which works out to be more than one issue a day! This spike in activity between December 2013 and March 2014 is quite obvious on the  Github contribution graphs  for Chao...

One of the first times I really thought about game states in a game was when I was learning Magic: the Gathering. There, it can be really important to know which phase of the turn is currently occurring, so much so that sometimes, you need to explicitly say things like "I'm beginning my upkeep phase" or "I'm about to end my main phase", so that opponents were given the opportunity to react during that phase. When I started working on Button Men, I thought that things would be much simpler, and that turn order wouldn't be nearly as important. Looking at the status of class BMGameState in July 2013, many of the game states were already present: startGame applyHandicaps chooseAuxiliaryDice loadDiceIntoButtons addAvailableDiceToGame specifyDice determineInitiative startRound startTurn endTurn endRound endGame Interestingly, we haven't yet used the game state set aside for allowing a handicapped game, it's just there as a placeholde...

Anyone who knows me knows that I'm not a great fan of Javascript. However, any time someone suggests that we move to using some framework like Angular, I feel a bit like this: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f Disclaimer: Actually, we do use Grunt, and I considered using it to minify our JS code right at the beginning, but we still haven't gotten around to it. Related issues on our issue tracker: manage third-party javascript libraries used by UI Discussion thread about the REST API URLs Discussion thread about the REST endpoint's data format Try out AngularJS for the front end

Our implementation of Button Men isn't perfect. Nor is it complete. In fact, at the time of writing this blog post, we have 396 open issues worth of imperfection and incompleteness. However, we also have 775 closed issues worth of completeness. If you haven't yet taken a look at our issue tracker on Github , you might find it interesting to have a browse. I find that browsing issues in chronological order helps me to keep my perspective on what we've already achieved. For example, our oldest open issue has an issue number of 108 , and there are only 10 issues still open with an issue number less than 200. Of course, this is slightly confounded by the fact that pull requests (which contain submitted bits of code) use the same numbering system as issues, and that pull requests make up roughly half of the total number of issues. But even so, that means that we have addressed roughly 90% of the issues from the first 100 real (non-pull-request) issues. Since we have 39...

I love story games. I love the fact that they exist. I love the fact that some people love them enough to create story tournaments. I love the huge variety of writing styles that can be found in story games. I love the odd pacing that the stories have, given that they're written within the constraints of a Button Men game. I love people being effusive about their stories and other people's stories. But you've got to admit that they're an odd feature to have on a gaming site. After all, how many new players would have expected that Button Men Online was a place to write two-player interactive fiction? And how many new players would consider a mirror haruspex game (with its single 99-sider) to be something worth playing? There are many things that encourage interactive story telling on the Button Men Online website: the opt-in mechanic for accepting or rejecting games asynchronous play at a relaxed pace an underlying game mechanic that prompts you when it's ...

A number of years ago, Chaos suggested that we deploy Button Men site updates on a regular deployment cycle. Personally, I had never deployed according to a regular deployment cycle before, not at uni or at work, so I didn't know why such a cycle would be useful, but I was more than happy to accept from Chaos's experience at her work that we would see benefits. For a long time, we had a deployment cycle that looked like this: the second and third weeks of the month were for accepting any pull requests that had passed code review and unit testing the last week of the month was for testing on a test server to attempt to find bugs in the code originating from recently accepted pull requests the first week of the month was a merge freeze, designed to allow us to focus on fixing bugs caused by the deployment to the live site This cycle worked quite well, I think, but there was always a large amount of work for the testers to be done in the one week before deployment, and ver...

There are times when I wonder whether I should try to tackle some issue related to the graphical user interface in Button Men. And then I wonder whether I shouldn't leave the issue to someone more capable. I am the first to admit that I have no real tendency towards graphic design, and I'm not awfully good at Javascript or CSS. However, I can usually muddle my way through to implement something that works and can be unit tested. My real dilemma, though, is that that testers often disagree strongly with me on what they consider to be important. My overriding concern is to get things done so that they are functional. I lose interest when people get hung up on issues of consistency, aesthetics, or emotional response. I've always felt that it was more important to make a new feature available for use as soon as possible, even if it still had some rough edges, than to delay it until it was implemented perfectly. The issue is not only related to me, though. Many pull req...

Those of you who have been paying attention would have noticed that I've started working on generating Button Men statistics for games played on the new site. If you're interested, you can see what I'm generating at http://stats.dev.buttonweavers.com/ui/stats/ . Currently, these are based on a cached copy of the database from 2017-07-07, but once we add the functionality to the live site, we'll be generating these at least once a day. As a sneak peek, here's a visual representation of the number of games played between each pair of buttons: Number of games played between pairs of buttons, with colour intensity scaled logarithmically

Updates are exciting in any web game, because they are a tangible demonstration to users that the devs are still actively maintaining and improving the site. Bugs get fixed, the user interface becomes easier to use, and every so often, new features see the light of day. However, to some users, it may seem that site updates on Button Men Online are few and far between. For a while, we were successful in maintaining a monthly release cycle, but that's proven to be impractical over the long term. So, why does it take so long to bring you new features? The most important consideration here is that the devs are busy people. One of the overriding considerations that we have always tried to honour is that Real Life comes first. So, while we might have nominal deadlines, these will always give way in the face of illness, work commitments and social events. We develop Button Men Online because we love both the game and the community, and we don't want the task of developing to becom...

For anyone who knows anything about web development, it may seem odd that we are using PHP for our back-end, especially since we made the decision in 2012, when there were many other feasible languages available. Here is the story of how we started out, and how we incidentally ended up being stuck with PHP. 12 Nov 2012 I broached the subject of resurrecting the Button Men Online site on the  Buttonmen Site Outage News  group, after nine months of downtime of the old site. One of the things that I left open was the choice of programming languages. 13 Nov 2012 After getting a bit of interest, I posted a suggestion on November 13 that we go with Python and PostgreSQL. Brooks chimes in that he is a Zend certified PHP developer, and suggests that Python frameworks may not be as robust as the Apache backend, and that the Apache backend is more widely supported on cloud architecture. He also mentions Pagodabox, which he uses for his PHP projects. Chaos posts that she knows Pyt...

A while back, I mentioned to Chaos that I was interested in sharing some of what the ButtonWeavers go through while we're working on Button Men Online . She thought it was a good idea, so we agreed to start a blog. So, what should you expect here? Well, I'll be starting with a couple of thoughts that I've had in the back of my mind, including a history of the new site, something about the mechanics of deployment, some recollections about skill interactions, and something about our priorities for the future. I'm also open to requests and suggestions for blog posts. Chaos has also expressed an interest in sharing some of her thoughts, and I'm looking forward to what she has to say. I think that it's wonderful that we've been able to revive the Button Men Online community. I'm committed to continuing to improve and expand our implementation of Button Men, and I hope that many of you will continue to enjoy the ride in the years to come. Oh yes, do...