What the Hell Even is a Pueblo?

Pueblo is a board game game that was published by Ravensburger in 2002. It was designed by Michael Kiesling and Wolfgang Kramer. What follows is a short analysis of the strategies that emerge whilst playing the game. Unfortunately, if you have never played the game, this is probably inaccessible as it doesn't include a rundown on how to play to put things into context.

Building - Initial Exposure:

Building has a number of intricacies, and mostly comes down to a tradeoff between the immediate cost of placing a block against the expected discount in points accrued over the course of the game. Lets start with the former. The immediate cost of placing a block largely comes down to where the chieftain currently is on the board. If he is likely to visit incriminating squares soon then this cost will be high. If you can move him on your turn such that it is impossible for him to give you points in the next turn cycle, this cost may be lower or zero. To an extent this also depends on your next piece, in as much as being able to block a particularly egregious brick on your next turn (before a visit from the chieftain) may make it the optimal long term play.

Building - Long Term Exposure:

Moving on to the expected discount over the course of a game, this metric asks the question of how many points you expect to expose each time the chieftain visits over the duration of the game. By way of an example, consider the first block placed at the start of the game. While the initial cost is high (see above), it is almost certain that the block placed next turn by your opponent will cover up one or more of its faces. In fact, by the time you get to place your next coloured block it may be completely hidden from the prying eyes of the chieftain. This is what makes a first turn play in the centre better than a similar one at the edge of the board. It also takes into account the remaining duration of the game. The first block on level one receives more weighting here than the first block placed on level three by virtue of the fact that the game only has a few turns left (compounded by the final check by the chieftain). The increase in points awarded as the pueblo gets taller has the nice effect of making later turns important (because they matter more than early ones) without making the first levels feel pointless.

Block Placement Order:

The way that the blocks are available to place has a few interesting properties. Initially, new players tend to fall into the trap of placing beige blocks first, in the belief that covering up exposed block faces sooner will benefit them. Then comes the realisation after their first game that this strategy falls down when they come to the final turn of the game and there are no good placement spots left. Now they do not have an opportunity to correct this inevitable bad placement and the game punishes this by having the chieftain make his final circuit. The next time they play they exclusively use their coloured blocks first, which is *almost* always correct. One fact that players often tend to realise after a few times playing the game is that being the first player to place on a new level is advantageous. For the price of a few points while your block is exposed, everyone else has to place around you and cover up the block you placed. What doesn't click is the connection between this and block placement order. Maybe it *is* optimal to place a common block this turn so that next turn, when the current level is all filled out, one can place the first block on the next level. It may well feel sub-par but the last places on levels one and two are often at the edges, which can never be covered up, as opposed to those at the beginning of a new level.

The Chieftain:

Oft mentioned in the above paragraphs, the chieftain is one of the more interesting game mechanics. I say he - it feels odd to have a gendered blob of molded plastic - but that is how the instruction manual refers to him/it/*whatever*. Anyway, by making it the players choice how far to advance him it introduces a whole extra game theory aspect to the turn cycle. The "If I move him here then the next player moves him there because they are trying to beat another opponent" lines are interesting and introduce a nice element of unknowable information which keeps the game fresh after a few plays. What really makes the chieftain stand out, however, is the fact that he is an amazing catch up mechanic. Think about it - by letting players choose who to screw over, the player in the lead will almost certainly accrue more points than if the chieftain had been moved by a die roll. That said, he doesn't actually impact the game in a meaningful way (the difference he makes is rarely enough to swing a victory), but he is a very visible way for players to feel like they can even the score.

Put another way, the chieftain bunches up the players such that the scores appear closer than they are before the final pass is taken into account. Each player, regardless of their skill feels like they can win at this point, which is an amazing achievement on the part of the designers. The finals scores will still reflect the skill of the players, and everyone is happy. All in all this is an excellent game, and I hope this short analysis begins to cover some of the deeper strategies that emerge during play.

The Bottom of the Stack

As with all the best things in life, this all started with a crazy idea that was initially dismissed out of hand. While I was in a fervor planning for FOSDEM this year I did a quick check to see if there were any conferences in the UK that I might be able to go to (my student budget didn't allow for another international trip). I worked with PHP for two of my previous internships, and used it as the base for my most used personal projects (pizza-get and music-get), so seeing that PHP had a conference in the UK was exciting. But there was a problem. A problem to the tune of £300 in the form of an entry fee.

Eventually I found that PHP UK were offering diversity scholarships for the conference, to the tune of travel, accommodation, and the entry fee. That sounds great, but I was pretty certain that I wasn't going to get one, especially as a student when the conference is aimed at professional developers. Well, turns out that if you don't ask you don't get.

Fast forward to February, and I'm on the way to a campaign reception at the Chiswell Street dining rooms with the other scholarship awardees and conference presenters - not only was I at the conference, but I had a unique opportunity to network with some of the best minds of the PHP world! After an insightful evening of wine, food, and excellent advice it was time to retire to the apartment I was staying in for the duration of the event with my roommate (another student awarded a scholarship).

Some of the main track conference talks blew me away. Compared to what I had been to before - FOSDEM and an 'unplugged' conference by RSAC - this was a big budget event. This also meant that there were some talks which one might not expect at a tech conference. There were talks about diversity in the industry, impostor syndrome, and mentoring. These are all really important subjects, and ones which nigh impossible to pick up from a book. I think more conferences should have these types of 'soft' talks (In fact, thinking back to RSAC unplugged the best session by far was Alexis Conran of the Real Hustle describing the psychology of scamming and deception, and not the ones by various heads of cyber security/research).

Aside from being harder to learn, these topics are the ones which get left out (in academia anyway, it was better when I was at a startup) in favour of technical skills. The thing is, I know how to find out about tech stuff - I can use Google to help me figure out that I can use Docker to ship my app - but I'm far less likely to google why it is that all my colleagues seem to know more than me and how on earth I got through the hiring process without them seeing through my fraud. Wait, did I just say that out loud?

To wrap up, I'm incredibly grateful to PHP UK for giving me this opportunity. I didn't think it would be possible to make people feel included in a community of 700 where, to be honest, we had very little in common. But it's worked! One of the conditions on receiving the scholarship was that I pay it forward one day, and you know what? I will. After the conference it dawned on me that one day I'll be able to provide the same eye opening experience to someone, and that's incredible. And also thanks to my mentors this time around, so I guess it's self perpetuating.

(I mentioned RSAC Unplugged a bit here, so I had to include the awesome picture they made of all the conference talks)

It's Not Rocket Science

This week SpaceX landed an rocket on a barge, and filmed it with a drone. The next day it occurred to me: my friend has a rocket, and I have a drone. If it's good enough for Elon Musk, it's good enough for me! Keen not to anger campus security any more than we had to (after recently crashing said drone onto the roof of the Zeeman building), Hersall Common was chosen as the launch site instead of one of the fields at the university.

The first obstacle encountered was the weather, with one launch aborted due to high winds and rain. The second came in the form of two important life lessons:

1) Super Glue does not fuck around

2) Do not volunteer to hold rocket parts while someone else Super Glues them

Luckily the abandoned launch gave me some time to reflect on poor life choices and a sudden lack of skin on my fingertips.

The next day brought fairer weather, so we headed back out to the common with our now fully assembled rocket. Cue us realising that we hadn't attached the nose cone and parachute to the body tube and another half hour of shenanigans with superglue. Finally, we could launch. I didn't realise until this point just how much having an electric ignition system adds to the whole experience. It really felt like we were playing with something dangerous.

There was quite a lot of wind on the common which meant we had to angle the guide rail at about 15° in order to have the rocket go something resembling upwards. It also meant that the drone was grounded. Craft #1 was small and light, weighing in at 42.5g with an A8-3 motor weighing 16.2g providing an average of 8 Newtons of thrust (9.7 peak). That's 0-60 mph in 0.2 seconds (not counting air resistance).

Rocket #2 was a bit heavier (62.4g), with the same motor. Evidence suggests that we need something bigger to get a decent launch from it. I think that's an excuse to go out and buy some more explosives.

And finally, here are the videos from the launches!

A Game of Drones

There is one thing that will, without doubt, induce fear in the heart of any undergraduate computer scientist: group project. The problem is that they come with all the responsibility of paid work, but none of the accountability. Maybe I'll revisit the game theory of Warwick group projects in a later post.

The topic we chose for ours was one I'd been wanting an excuse to explore for a while: quadcopters. After some brainstorming we decided that the best approach we could take given that this was an academic project was to devise some framework for reasoning about drone networks, and to devise a way of writing high level scripts that could task them. I think the particular use case we had as an example was monitoring forest fires.

The problem is though, that the FOSS software available for simulating sensor networks is *really bad* from a beginners perspective. The de facto network simulation application is NS3 (yes, as imaginatively named as you think), but the learning curve is really high. The hands on section of the sensor networks module at Warwick for *third years* spends weeks building up to the point of moving some nodes around. Suddenly it began to dawn on us that we had bitten off rather more than we anticipated.

Upholding a long tradition of software engineers everywhere, we took a fresh look at the problem and decided that it would be easier to create our own simulation software than to learn the intricacies and quirks of NS3. To be honest, it's done wonders for my understanding of the domain, as well as the specific problems we are trying to model. The best example of this probably lies in the communications side of things. If we had used NS3, I would have experimented with a few different message routing models before trying to piece together a conclusion based on what the corresponding Wikipedia articles told me was supposed to be going on. As it stands, I've actually taken the RFC for Ad hoc on demand distance vector routing and implemented it in C++.

Credit: David Richardson

We made a conscious effort with the project (named octoDrone) to keep things as modular as possible. To this end, the simulator, communications processing, programs that run on drones, and scripts that define simulations are all separate and configurable. This payed dividends when it came to deploying our software on to real drones instead of simulated ones, as we were able to swap out the code that simulated the operating environment for one that sent the same instructions to real hardware (I'll cover the deployment in a separate post as it's something I could talk a lot about). The other goal during development was to cut out a lot of the bloat that plagued NS3. Instead of it taking half an hour and a handful of tutorials to visualise a simulation, the application *should just do that for you*. Instead of having to access node components by passing strings with the same name (eugh), you should just be able to access them through code the way you normally would.

At the end of a year of work we're left with a lightweight simulation package that does exactly what one would want a drone simulator to do, and nothing more. Being able to run the same programs on real drones as you do in a simulation is a real selling point (and that it works at all on the drones we had to test on is a point of personal pride). It even got to the point where I seriously considered running my coursework assignment in octoDrone instead of NS3, which serves to show just how far we've come.

GitHub: https://github.com/mcnutty26/octoDrone