Blog: June 2024

Most of these posts were originally posted somewhere else and link to the originals. While this blog is not set up for comments, the original locations generally are, and I welcome comments there. Sorry for the inconvenience.

Origins 2024

We went to Origins Game Fair last week and played a bunch of new-to-us games (and a couple familiar ones). Some notes (not full reviews):

Wednesday

  • Alhambra: The Red Palace (Queen Games): On your turn you can take money, buy tiles to expand your tableau, or take some special actions depending on conditions. I don't know which parts of this are the base game (which we've never played) versus the expansion. (There are soldiers who can be placed on your walls or sent to do tasks; that feels expansion-y.) Fun but not outstanding; I might look up the base game, which I've heard good things about.

  • Empire Builder "pot luck": We did this last year too. There's a train-gamers club that runs a bunch of games. For this, they showed up with game sets (higher-end custom builds, not the games we own) for many of the "crayon rail games" (Empire Builder, EuroRails, et al), and interested people self-organized into games of whichever ones they were interested in. We ended up in a three-player game of Iron Dragon. We all had some bad luck at various times and the final score was way more lopsided than the board positions would suggest, but I had fun. (But sigh, I was one turn away from delivering that load of dragons for 66 gold, which might be the highest payoff in the game.)

Thursday

  • Natural Chaos: two-player game with the feel of tic-tac-toe, rock-paper-scissors, and a capture/replace rule that adds complexity. Ok, not long, might not have a lot of replay potential.

  • Lacluck's Revenge (?): This was a vendor demo. Cooperative dungeon-crawl game, simple mechanics (for what we saw, anyway), maybe aimed for a younger crowd? We played a prototype; there's a Kickstarter.

  • Maglev Metro: We enjoyed this a lot and bought a copy. You're building a network, collecting resources (with preconditions), and building your "engine" to be able to take more/better actions. There are public goals and secret goals. The game is very nicely produced; in particular, each player has a stack of "track" tiles that are transparent other than one stripe, and they're all slightly offset from each other, so players can build in the same hex and you can still see everything. That's clever. Also, the boards where you're collecting pieces have slight indents so that you're not worrying about accidentally scattering things. Thoughtful physical production values, in other words.

  • Wingspan with an expansion (name unknown): We played Wingspan last year, bought it, and have played several games with friends. This session had an expansion that added a "wildcard" resource type and some special rules around it, also adding cards and replacing the game boards to account for that. I don't think the expansion carried its weight, but the session was fun. I seem destined to win Wingspan at Origins and mostly not at other times. (I won the game last year and also this one.) This game had some very nice component upgrades; I don't know if they're commercially available. There was a much better birdhouse, which sent us looking online and it turns out Etsy and others can solve that for us. (I was going to try to build my own, but I don't have the right tools so we'll probably just buy one.)

We attempted to have a late dinner at Barley's, a popular pub across the street from the convention center that gives away custom glasses every year, but they were very crowded and understaffed so we bailed.

Friday

Beer for brunch is fine, right? We were there at opening time, after a morning seminar, and that worked much better.

  • Seminar: Punish your players with landscape science: presented by a geology professor, a survey of how a variety of environment hazards "work" and how you might handle those effects as a GM. We talked about volcanoes, tsunamis, rip currents, a kind of landslide where a whole plateau moves (I forget what this is called), and several other things I don't now remember. Interesting food for thought; didn't take notes. Presenter's web site, includes a link to his book Landscapes for Writers and Game Masters: Building Authentic Natural Terrain into Imagined Worlds.

  • Gems of Iridescia: Fairly lightweight worker-placement game: mine gems of four different types to assemble the components to buy ("restore") artifacts; public and secret conditions for scoring victory points. Playable; has rough edges. The game is not out yet; the session was run by the designer.

  • Rolling Freight: Rail-building game with limited contracts and a random component. You have a pool of dice with different colors on the faces; those colors correspond to actions you can take and places you can build, so what you can do at any time depends on what you rolled this turn. You can buy a limited number of upgrades that either let you use your dice more effectively or give you more dice. In addition to building rail you're also trying to make deliveries, on as much of your own track as you can but you can use other players' track (and they get points for it). It feels like a good game in general (I'd need to play it a couple more times to judge it), but the board is difficult to see things on. Some board deficiencies might be things I could fix with the right stickers and Sharpies.

Saturday

  • Brass: Birmingham: Outstanding. We had ordered it online before leaving the convention. This is an industrial/economic game: you're trying to build a commerce network, producing goods in response to demand from other players and figuring out what to build to use your limited resources most effectively. Where/what you can build is governed by the cards in your hand. Turn order is set by spending: bigger spenders go last in the next turn.

  • Savage: A social game related to Werewolf/Mafia/etc but with better mechanics and a little randomness. Hidden-traitor games aren't my favorite, but this game seems to do it better than some others.

  • Dwarven Rails (2024): a lighter-weight network-building game with investment in rail companies. This is a "cube rail game", a term I had not heard before but maybe it's meaningful to my readers. You're building a network, but more importantly, you're building to increase the value of the companies you own stock in, so player alliances come and go. I ended up winning this by half-again the next highest player (who I thought was beating us all), and I don't entirely understand how that happened. The game has a lot of potential but also some issues. Our session was run by the designer, so feedback was received.

We also went to a two-hour seminar that was kind of rambly and was plagued by technical problems, so I'm not going to say more about that.

Sunday

  • Zhanguo: The First Empire: Complicated optimization game. It has a lot of room for strategy but was pretty overwhelming on a first play. (Having one teacher cover multiple tables was a tactical error on the part of the organizers, in my opinion.) Some of that might be "Sunday morning at the end of the convention" fatigue, some was definitely being the slowest player at my table, and a little was vision. Mostly, there were a lot of details to keep straight, and I admit to feeling relieved when it turned out the timeslot was an hour shorter than I thought it was (this will end soon). The game is very well-made physically except for one poor color choice in certain tiles.

Queen Games was running a limited special through the entire convention: present a coupon to get a (random) free game from their catalog. We've played and enjoyed several of their games, so this was interesting. People lined up for this before the hall opened and we didn't try (they limited the number each day), but on a whim, we stopped by Sunday morning on the way to our game, almost an hour after the hall opened, and there were only a couple people waiting and they still had games. They were down to their last ten and only had one option left, so we didn't get to see what the other games on offer were, but we now own a copy of Pirates, which looks light and cute.

Documentation for developers

Because of some organizational changes at my job, rumor has it that developers are going to be asked to contribute to writing technical documentation. Some developers on my scrum team were a little, err, concerned about that, so I wrote up some notes (and compiled some links) about our tools, conventions, and so on. I also included a philosophy section that is not specific to our product or company. I feel like I've written "tech writing basics" several times over my career; here's one more collection of quickly-compiled notes (far from complete).

--

I don't have time to develop a course in technical writing, but here are some thoughts as they occur to me.

Document the contract, not the implementation. You're deeply immersed in the implementation and might be tempted to pull content from the design spec. Instead, pull it from the functional spec. Think of the implementation the way you think of the private classes that probably make up most of it: that's for you (and you're free to change it), not for users to depend on. You expose interfaces in the code to protect the implementation; think of the doc as one of those external interfaces.

An awful lot of technical documentation that has probably frustrated you talks about "what" but not "why". We do need to describe the "what", like what all the parameters are, preconditions, interactions with other parameters/functions/etc, but ideally you wouldn't stop there. Put on the user's hat and ask: why would I want to use this? What problem does this solve? Good documentation starts from things the user is trying to do and then shows how to use (probably several) functions/statements/features/settings/etc together to do it. With luck, your functional spec starts there too, so you're not starting from scratch.

There are a few main types of documentation in most doc sets:

  • Reference pages: a complete description of each individual "thing" (class, function, command, etc) in a consistent layout with minimal distractions. Use outbound links for other supporting material.

  • Task doc: how to do a specific thing, usually a sequence of numbered steps. Keep it focused; the user is going to be going down the list probably typing (or cutting/pasting) the commands in the code blocks.

  • Troubleshooting: there isn't much of this in our doc, but some of our top-level categories end with a troubleshooting section. I build these up over time based on bugs that turned out to be pilot error, feedback from support, edge cases I notice in tests, and so on. Sometimes a functional spec calls out limitations up front and I add a troubleshooting section that approaches that limitation from the other side.

  • "Guide" doc: a mix of overviews, conceptual doc, and scenarios. This doc usually covers the "golden path" and should not try to be exhaustive (that's what the reference doc is for). You'll see some older doc in (location) that mostly repeats the reference pages without adding much; don't emulate that.

(Some doc "frameworks", like DITA, slice up the world a little differently: reference, task, concept. I naturally think my division is a little more on-point for the kind of doc we're writing, but it's just one person's opinion.)

Good examples are gold. Bad examples are tedious. One person's good is another person's tedious, but asking the question is the first step: what purpose does this example serve? Examples don't need to be exhaustive like unit tests; examples illustrate, and they show clearly how to do tricky things, but you don't need the combinatoric explosion of all possible arguments and parameter values in the doc. Examples, like doc, should be as concise as possible while still accomplishing the primary purpose.

When writing examples, it's helpful to users if you can attach some meaning - instead of an ML function operating on columns c1, c2, and c3 in table t1, can you imagine a scenario where people would actually use it and mock it up instead? Particularly for long or multi-step examples, it's easier if readers can hook onto some semantic hints, even small ones. This helps with the "wait, which one was c2 again?" backtracking that happens when reading subsequent explanation or steps. Your examples might not be completely realistic, but try for some "realism flavor".

Scrum-master philosophy

I've mentored a few other scrum masters and am writing down some of my so-called sage advice for coworkers. This part isn't specific to our organization, so I'm posting it here and not just behind a corporate VPN.

--

Philosophy

The scrum master and product owner should work closely together and ideally be able to complete each other's sentences stand in for each other. As scrum master I'm not the one who makes decisions about priorities and technical direction, but I should know enough about everything we're doing to ask questions and prod gently. The SM and PO are partners and each strengthens the other. Have 1:1 conversations with your PO alongside the team discussions.

Asking questions is a great, non-threatening way to prompt conversations. Think Socrates.

According to Agile (not just SAFe, the specific framework we use), part of the scrum master's job is to remove roadblocks. In my opinion, a key aspect of this is a style of "servant leadership" -- if there are things that "anybody" can do and other things that require expertise, then to the extent possible, as scrum master I should take the former so that other team members can do the things that only they can do. This is why I do easy server backports, participate in PR reviews, and help with functional testing, none of which fit into my official job description.

To an outside observer a scrum master might look a lot like a project manager, but you're embedded in the team, not coordinating things from outside. You do need to do the management stuff, but don't let it keep you from being part of the team too. You know the work, you know the people, and you know how to talk with the latter about the former.