Monday, February 18, 2013
I am a sucker for roguelikes. Most roguelikes fall into a very standard template - the very name of the genre describes derivative works inspired by an old classic, “Rogue.” New games may change the theme or improve the graphics but few fundamentally deviate from the norms established long ago in classics like NetHack, Ancient Domains of Mystery, or Angband.
Despite some strong recommendations, I initially wrote off Tales of Maj’Eyal (ToME) as another such clone, albeit one designed for newcomers to the genre. After a few playthroughs I see the differences though - interesting design decisions throughout the game kept me wondering “what if” and coming back. Take inscriptions, for example, ToME’s response to healing/mana potions. From their own documentation:
… inscriptions (infusions and runes) replace potions and scrolls. The design goal behind inscriptions is to eliminate the time spent by the player “farming” potions and scrolls in weak zones, in order to make a run at a tougher zone. They are unlimited in use, but have cooldowns attached, so you must carefully time your use of them to survive. Unlike many other RPGs you cannot rely on a large stack of potions to get you through a tough battle.
That level of care in design permeates the game. Classes are designed to be familiar, and yet each one has unique mechanics that keep me coming back. Many of the standard or monotonous aspects of roguelikes have been streamlined (no cursed items for example, yay!) so that you can focus on the interesting bits.
Great games are a continued series of interesting decisions. In that light, Tales of Maj’Eyal is a great game. If you like roleplaying games new or old, I recommend you check it out. ToME is a free, open-source project, and you can download it for virtually any operating system at http://te4.org/download.
And remember, as with any roguelike game: dying is fun.
Thursday, January 10, 2013
On the great podcast Hardcore History, Dan Carlin recently had this to say about the invasion of Russia (emphasis mine):
The Mongols first showed up [in Russia] in the winter of 1237. It should be noted that almost everyone in history has tried to avoid fighting in Russia in the winter. Hitler was perhaps defeated because he couldn’t. Napoleon did everything in his power to be done with military operations before the Russian winter hit. The Mongols waited until the Russian winter came before they started operations. Because in the winter of 1237, once the lakes started freezing and the rivers started freezing and the marshes froze over, it turned all the natural barriers against an invader into highways for a people like the Mongols. It made them better.
The Mongols were a nightmare that the west proved completely incapable of handling. In part this was due to how the Mongols seemingly did everything wrong in Western eyes. An individual European knight could easily best a single Mongol warrior,. Mongols didn’t bother to maintain supply lines and establish clear control of their conquered provinces. They split their armies into multiple, smaller groups rather than concentrating their forces.
Yet the Mongols turned each of these weaknesses into strength. They trained their troops as teams, not individuals, and turned meager soldiers into fearsome groups. They broke into armies small enough to live off the land rather than maintain supply lines, making them incredibly mobile and able to strike multiple fronts at once.
Unfortunately the Khans turned this mindset towards one of the largest genocides in human history, so not everything in their example is admirable. Nonetheless, this passage gave me pause to reconsider my natural barriers and weaknesses, and how I might use unconventional thinking to turn them for advantage, to make me better.
Last week, I grew frustrated with the available options to make and share shopping lists with people. I didn’t want someone to have to create an account, choose from curated selections, or any other hassle. I wanted people to make a list and instantly be able to share it with whomever they like.
So I created Lister!. It offers no frills, no security, and no guarantees (doubly-so as it is backed by an in-memory Redis store). But it’s probably the absolute simplest way to share a list. So get listing!
If interested, Lister! is written in Clojure and the source is available at github.com/citizenparker/lister. There’s a bevy of problems in the code and in the app (the HTML5 features I use aren’t supported in Android, most frustratingly for me) but it will have to wait a bit.
A few people have sought my advice lately on leadership. Specifically, I’ve gotten high marks for delivering while also giving people freedom to work as they see fit. While I would caution anyone against cargo culting my practices as yours, I’m happy to share what little I know.
Be advised - I don’t pretend to be a master, merely a student.
Beyond business strategy (which is outside the scope of this article), the goals of leadership are primarily reducing turnover and increasing productivity. Of course there’s a number of other secondary goals that are crucially important, like fostering a great company culture and happy employees. However, I view those first two as preconditions or boons for nearly every other goal you may have.
You can’t do much better than making sure you pass the Rands Test. Seriously, go read that right now. I’m about to expand on a couple of his points, the two I see as the absolute bare minimum for a leader.
1:1 meetings may be the single most important thing you can do as a leader. Not only do you get an opportunity to address problems before they become problems, but they help make for super-motivated employees. When individuals can speak up and can collectively see a difference, this leads to a variety of positive outcomes, especially in preventing turnover (see “Speaking Up vs. Being Heard: The Disagreement Around and Outcomes of Employee Voice” for more details). It’s also an opportunity each week to relate an employee’s personal goals to the group’s goals and thus boost personal investment in the work.
It’s also crucial that each member of the group understands the overall mission and their role within that. This speaks somewhat to motivation, but is generally a huge productivity boost. The reason comes down to initiative.
Harvard Business Review’s classic article “Who’s Got The Monkey” (paywall w/ summation here) outlines the following levels of employee freedom:
Your employees can exercise five levels of initiative in handling on-the-job problems. From lowest to highest, the levels are:
- Wait until told what to do.
- Ask what to do.
- Recommend an action, then with your approval, implement it.
- Take independent action but advise you at once.
- Take independent action and update you through routine procedure.
For maximal productivity, you want your employees to operate at the last three levels. However, they can’t do this effectively without a great understanding of the mission and how they play into it. Reinforcing this at every opportunity (team meetings, status updates, etc.) keeps them at those higher, more productive levels.
Two Golden Rules
When all else fails, I fall back on these two maxims: “Manage others as I would want to be managed” and “Unblocking my team is priority #1.” When I’m in unknown territory, I try to imagine how I would want my own managers to treat me and go from there. I also make clear to my teams that no meeting or other priority is so important that it trumps helping them. Not only does that help keep people immediately productive, but it’s also a motivation boost to see your team lead drop everything to help debug a problem when you are truly stuck.
Anyway, if you find this useful, please do let me know and I can write a few more on the subject.
Huzzah! In roughly 3.5 hours, Ludum Dare 24 will begin. I’ll be participating again in the loosest sense of the word. As with my “game” for LD23, I am going into this deliberately unfamiliar with the frameworks I’ll be using. Any ideas you may have about “fun”, “playable”, or “complete” should be checked at the door.
If you have any interest or background in programming, I strongly encourage you to participate. If you set aside all goals except “do your best” this is a tremendously fun event. Anyone of any background can participate.
I’ll be writing my entry in Clojure and libgdx this time around. I’m excited for a couple of reasons. First, this will be my first opportunity to play with LightTable (pictured above) on a real project. Most importantly though, game programming is typically the poster child of mutated state - nearly every element you see when playing a game mutates-in-place over time. I’m very curious to see how well or poorly I can translate Clojure to this domain.
If you want the gory details on my progress, you can find that on scoopsy.com. Otherwise I’ll post a summary eventually.
TO THE CODES!