The title of this blog post is a mixed metaphor. It’s a mashup of two common programmer idioms, sharpening the axe, and shaving the yak. I’ve been doing both this week, but before I get into that, I’ll define the terms.
Sharpening the Axe actually comes from a quote attributed to Abraham Lincoln: “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” When googling around for how this applies to programming, it seems a lot of folks have (for some unfathomable reason) latched onto the phrase “sharpening the saw” instead. I can think of four general categories of specific activities this could mean:
- direct study — Ie., reading a book on a language or API, or reading and/or studying some relevant source code. Anything that directly applies to some programming task you have to undertake.
- indirect study — This could include reading more generally about programming or related “industry” news, or learning a new language you will not immediately be using, or any other research not directly related to your current task list but (hopefully) teaching you something tangentially related.
- architecting — This could be formal, in that you’re writing a document or outline, or putting together a task list, or just more generally thinking about the task(s) you have at hand. (I find I do my best architecting in the shower.)
- practice — Writing code, but not code you will be using. I’m not much for this one, but I’ve heard a lot of good programmers say they write something once, throw it away, then write it for real. That sounds like a lot of extra work to me, but who knows, it is definitely easier to write something the second time. I’m not sure it’s guaranteed to be better though.
Yak Shaving is a more complex and subtle problem. Jeremy H Brown defined it in a usenet post in 2000 as “what you are doing when you’re doing some stupid, fiddly little task that bears no obvious relationship to what you’re supposed to be working on, but yet a chain of twelve causal relations links what you’re doing to the original meta-task.” The programmers Stack Exchange has more on the definition and history of the term yak shaving.
So what have I been doing this week?
I’m working on iCloud syncing for ActionGo, my next game for Apple TV and iOS. In a way, this is already shaving the yak, since I’m really only working on that because the Apple TV doesn’t support filesystem saving, and iCloud is their recommended solution. But after only a day or so of work, I found out that it does support NSUserDefaults key/value saving. (Up to 600 K, plenty for a saved game or two.) Since I’d already planned on implementing iCloud as key/value, so long story short, now I’m doing both. (Which is of course better, because it’ll work offline too, just without the syncing.)
But I’ve never done iCloud syncing before. *queue sharpening sounds* There are at least a couple of ways you can store data there, key/value, or document-based. Key/Value is definitely preferred for my use-case (a bit of state data for games in progress, and storing overall meta-game statistics), so I focused on that, but even then there are a bunch of different ways to go about it. Consensus seems to be that it’s really easy to get working, but almost all the blog posts and resource sites I read focused on that initial experience and I didn’t end up finding anyone who went into best practices.
So here’s the yak shaving rabbit hole (oooh, a third metaphor?): I’m using Generic Game Model for game state, which already had saving implemented on iOS using the built-in saving functionality that BaseModel provides. But it turns out that I was using an old version of BaseModel, so I had to update that. Then I wasn’t happy with how BaseModel implements its NSUserDefaults storage, so I re-wrote that. Then I wrote a wrapper that handles the syncing to iCloud whenever a key is added to NSUserDefaults (storing an associated NSDate value also, so I can just keep whatever’s latest), and only just now I’m finally getting around to testing. (Only I’m not so much, since I’m writing this post right now instead.)
When is your axe too sharp?
While “researching” this post *more sharpening sounds*, I ran into this critique of Axe Sharpening from a java.net blog post back in 2005:
But for me, the big problem with “axe sharpening” is that it’s recursive, in a Xeno’s paradox kinda way … to sharpen the axe, you need a sharpening stone… But to get there, you need to build a dog sled… But to use a dog sled I need snow, so I need to go to town to get a snow cone machine. I grab my trusty yak to help you haul the machine from town. But it’ll be summer before I get to town, and I don’t want the yak to get to hot, so I shave the yak. In mid February, I proudly lead my shining, bald, shivering yak into my quarterly progress review…
I had the privilege to present this talk at MN Developer Conference this afternoon.
The talk is partially a re-hash of a talk I did back in 2011 on iPhone Games Programming, and it’s partially a re-focusing of a talk I did last year on Generic Game Model (my small collection of Objective-C classes for game development).
Tonight, a chess variant is sitting at the top of r/gaming. That itself is probably newsworthy, but watch the video below of Speed Chess (apparently unveiled at the Tokyo Game Show 2015) to see why I’m now dying to play this real-time chess played on a touchscreen.
Oh, and don’t worry, I’ve mined a ton of other good videos from the reddit thread so you don’t have to!
- In this one, the new chess (no, not that one) is about to be released. (This was a little slow at first, but gets pretty good, I felt.)
- This Chess reviewer had me laughing out loud.
- I’ve definitely seen this BBC skit about how to play chess properly before, but it was worth a re-watch.
- Finally, this scene is apparently from a UK sitcom called Bottom.
And while I’m at it, I’ve been eagerly anticipating Chesh for at least a couple of weeks now. I’ve been waiting to say anything about it here until I played it, but the since I wanted to post the Speed Chess video above, I felt it deserved inclusion in this post. Here’s the trailer:
From what I’ve gleaned from the internet, it’s a random chess variant with hundreds of possible pieces. I like the glitch-tank aesthetic. Remains to be seen whether I’ll also like the randomized gameplay.
My good friend Nate was kind enough to playtest 3 out of four of the pyramid games I posted yesterday (we didn’t play the party game), and the results shouldn’t be terribly surprising, but they were generally disastrous. In short, none are ready for prime time. (But on the upside, none were complete throw-aways either, and all have potential!) Here are my notes:
Action / Movement Programming — This suffered from the problem where the player has the advantage, so nobody wants to make themselves the second-to-last player. This meant there was little incentive to try and make the target shape. We did play with a pretty cool variant / modification where there are 9 “goal cards” (in a 3×3 grid), and any 4 cards in that group can be the goal. The rule about “modifying” the programmed cards was very confusing to Nate, and I had to clarify / re-explain it several times. There was also confusion about being able to modify pieces on the gameboard, and I think adding an action that would allow you to modify (swap?) existing pieces would probably help. None of this fixes the disincentivization to make the goal shapes. We talked about maybe not replacing the cards. Also, I just had the idea to maybe only take one of the cards instead of all of them, so most of the shape would still be there, but it would obviously need modifying. Maybe then you also get points at the end of the game for collecting “sets” of a single color card. We also played on a very large gameboard (not quite a full chess board, but it was with the triangular chess boards that are sometimes used for looney Pyramids), and I think we could have just played on a 4×4 grid, and it would have been a tighter and better game.
Action Point Allowance System — This game suffered from the rules allowing you to totally screw yourself. If you didn’t play a combination of either 1) two 2-pip pieces or 2) a 1-pip and a 3-pip, you were giving yourself a serious disadvantage later in the game. I think the rules should just specify you can play one of those combinations. Also, the player who played first had a huge advantage, not because they played first, but because as the rules are written, they also got to play last. I think making both players play only a 2-pip on their first turn might mitigate that problem. Another issue was that we played on a 3×3 grid, but never really used more than 4 towers. Another rule change I’m considering is to make the players fill the grid first, before playing higher levels on any tower… or possibly just to play on a 2×2 grid. (Or both.)
Area Control / Area Influence — Finally, as I’d hoped, this game seemingly has a lot of potential, but we ended up not playing it while we spent like 20 minutes discussing how the captures could work. (Rules as written do not specify capture rules, and I thought I’d just make something up quick about surrounding groups, and we’d see how it plays, but turns out there are too many different possibilities!) It would take me a long while to write all the things down that we discussed, but briefly, we talked about: Switching it to allow ONLY swaps of cards with pieces on them (then you could capture from a swap or a placement). Allowing piece movement to capture, with cards containing pieces of the opposite color “frozen” in their place, essentially “locking” neutral spaces on the gameboard as kind of a suicide move. Finally, if we allow swapping cards with pieces on them (which I think is a good idea), I think maybe it should only be allowed if they have the same (or possibly only if the opponent’s card has lesser) pip counts. Maybe that parenthetical should always be true, which would mean you could only move cards that have pieces on them, since by default all the cards start empty.
I don’t know when I’m going to get around to revising the rules as written, but hopefully in the not-too-distant future!
At least partially inspired by another BGG user’s lofty goal of 1 new pyramid game a month, around January 1st I had the even-more-ridiculously insane idea to make a goal of designing a new pyramid game for each game mechanic on Board Game Geek. There are 51 unique game mechanics on BGG, so that’s LESS than one a week. Totally do-able, right?!
Of course, I promptly forgot all about that idea, until I stumbled onto the first couple in my design notes earlier today. I spent some time subsequently flushing them out and writing a couple more, and so without further ado, here is a link to the in-progress results: pyramid games for every BGG mechanic.
So far (as of this blog post) there are only 4 rule-sets in a “completed” state. I have notes for two others, but they haven’t been written up yet, which means they may not even be playable. At least one of those not yet present require a custom game board (the one for Roll-and-Move).
This idea came, originally, hot on the heels of a renewed interest in pyramid games because I’d helped conceive and design these pyramid cards, a set of playing cards for icehouse/looney pyramids. (The card artwork, — ie, bulk of the work — was done by my sometimes collaborator August Brown.) At the time, I’d thought up a few different game ideas, but it turned out that none of them were really all that fun to play. A statement that may of course also be true about the ones in the link above. YMMV. Two of the designs listed below (and flushed out in the link above) use the cards. I think the ideas in the doc are better than the original pyramid card ideas, but they are still as-yet untested. Anyway, here are some brief summaries:
Acting mechanic — In this game, players take turns choosing a board game, and without revealing that game’s name, set up and play that game with looney pyramids. They cannot talk, and the other players must try and guess which game they are playing. Subsequent players cannot choose the a game that has been previously selected.
Action / Movement Programming mechanic — This game is a combination of seeing patterns in pyramids and using your hand to manipulate pieces on the gameboard. Game play happens in rounds where a “goal pattern” is decided, and players then simultaneously try and choose actions that will manipulate the board to create the “goal pattern” there.
Action Point Allowance System mechanic — This abstract strategy game is played with 4 action points per turn. (With the first player only allowed 2 points.) Some suitable small grid is chosen for the playing field, and each player takes a “stash” of icehouse pyramids and takes turns playing pieces onto the gameboard. At the end of the game, the board is scored and players win based on number of pips that are visible in their color.
Area Control / Area Influence mechanic — This 2-player go-like game is played on a board created with pyramid cards. Cards make up the gameboard, and pieces are placed to “secure” the territory. This is the game I’m most excited about / interested in playtesting.
I’ll post again about this project after I make more progress.
Why working 5 or 6 hours in the AM is WAY less productive (for me) than working 7 or 8 hours throughout the day
First of all, I sort of wondered if this would happen. I’m not a morning person. I’ve never been a morning person. I used to tell people I worked with that I couldn’t manage to get anything done before 10 AM, not because I wasn’t awake, but because I couldn’t convince my brain that I was awake. It took an hour to get into the groove, maybe.
But just now I came up with a new theory.
In the past, I’ve had days where my morning is productive, but also days where my morning is unproductive. Possibly in disproportionate amounts, but let’s assume for a minute they are in equal frequency. On the days where my morning was unproductive, I am often aware of this, and compensate by trying to work extra hard (or be extra focused) in the afternoon.
Additionally, I am a lunch guy. I never eat breakfast. This is relevant because, probably due to blood sugar (or something else, who knows), if I don’t eat, and I’m really hungry, I notice my productivity really drop. (Hey, it JUST occurred to me that my lack of eating breakfast might have something to do with my lack of productivity in the AM. I never claimed to be smart.) Anyway, lunch is the most important meal of the day for me, if I don’t eat lunch, I often end up scratching my head at 2 pm, wondering what I’ve done with the last two hours.
So now, if I find that I’ve had a non-productive morning, I push myself hard to get more done… often “working” through lunch, (or through when I should be eating lunch), and then realizing that I haven’t been productive even while trying to be extra productive.
The new difference, and the productivity KILLER here, is that now I am done working around 2:15. So if I didn’t have a productive morning, even if I do eat lunch, I’ve only got like another hour or so of work remaining to try and be extra productive. I can remember days in the last couple of weeks where I’ve had exactly this revelation, and it’s been pretty demotivating.
Perhaps this is just the latest in a long line of thoughts justifying my lack of productivity. In short, writing this post: was it procrastination? Or productive?
I have too many projects going right now. I wrote up these descriptions earlier, so I decided to post them. These are roughly in order of priority. (Although the last three are essentially just “on the backburner” for now.)
1) I want to get an update to Root Down pushed out that adds an AI player, as well as universal support. The AI isn’t good in any sense of the word, but it’s good enough to surprise me when I’m not looking too hard. I’m not sure if I’ll try and improve it, or if (more likely) I’ll just release it as is to move on to the next thing. (The universal support is about 80% there, and I should have that submitted sometime tomorrow or early next week.)
2) Last year I did some preliminary work and got my very first game (Go-Tetris) playable on iOS. It’ll be called ActionGo. Since the new AppleTV announcements yesterday, I now hope I can push this out sometime in the near future, with AppleTV support.
3) Similar to Root Down, I’ve had an update to ActionChess in progress for several years. Not taking the time to do it right means that I’ve got to untangle a large pile of spaghetti code to get it done, but the update will add 1) Universal support, 2) One or two minor added game modes, 3) A major new game mode that is more of a “static puzzle” game. I’m calling it puzzle mode, and may also release it as a stand-alone app.
4) I’ve got another action puzzle game in the works that is currently without a title. This is not a board game mashup, but does mash another game genre into the mix. I have an artist (possibly two) I’m collaborating with there.
5) I’m rather slowly trying to learn Unity. I have a project I’m going to make in it, since I agreed to work on a touchscreen version of Entrapment, (the great abstract strategy game by Rich Gowell). So far, I’m a bit hung up on some of the Unity best practices, but I can’t wait to make some progress when I can focus on it.
6) Finally, I have a series of playground games I’m working on. Don’t want to go into too many details, but essentially it’s a playground video game.
Hopefully I can bang out some of these app updates in the next couple of weeks, and focus on ActionGo until the new Apple TV comes out. I’m also experimenting with some cross-platform frameworks. I’ve played a bit with OpenFrameworks, and have also spent some time looking into OpenFL (HAXE). In theory either would allow me to publish games for iOS & Android at least, and whatever other platforms they support.
So, I made a webpage/toy to generate a pseudo-random abstract strategy game description. It’s pretty much just mad-libs style text substitution, but randomly chosen from arrays of strings I’ve brainstormed. I started with a short paragraph and now it generates three paragraphs for each game. There’s a lot more I’d like to do with it, including maybe generate actual playable games. (That would be a lot of work though.)
For the last couple of weeks, I’ve been citing an offhand comment some eyeo presenter made about the importance of experiencing “awe” regularly in your life. After getting over that slight discomfort I always feel when citing sources whose sources I absolutely don’t know, I’ve been finding it an easy justification for all kinds of actions and decisions I make.
So I did some googling. This interesting slate article by an “emotion scientist” suggests that the state of awe provokes thoughtful reflection and skepticism. This makes sense to me because I think one thing I find so appealing about “awe” are the big ideas. And big ideas give you perspective. If I’m contemplating the nature of the cosmos, that bug I’ve been working on for the last few hours seems rather less important. (Which I’d argue often helps to solve it, but that’s another blog post.)
This Atlantic article cites a Stanford study published in 2012 whose title says it all: “Awe Expands People’s Perception of Time, Alters Decision Making, and Enhances Well-Being” This huffpost piece cites a paper written in 2013 with another telling title: “Approaching Awe, A Moral, Spiritual And Aesthetic Emotion.”
This quest for awe is absolutely why I made it a priority to go to eyeo festival this year. It’s why I went to Northern Spark last night, and stayed up ridiculously late looking at art. The eyeo presenter that I quoted said it’s why we go to museums. Finding awe is often what drives my decisions around what to work on when I have spare time, and what to spend my recharge time doing in my evenings and off hours. Now I just need to figure out how to trigger it with the games I make.