This blog is mostly to assist my own memory and writing skills, both of which have been getting steadily worse. It will mostly be about (video)games, toys, and software development.
Posts before this one are things I wrote on an old, shared blog and am not completely embarassed by.
If you like it, that's cool. If you don't, that's cool too.
If you care, I'm using Pelican.
If you actually want to know what the heck it is doing when it
fails, make VERBOSE=1 prints the commands it's running. This is
dumb, but maybe forgiveable when you consider not everyone
compiling the software may be developing it, and most users will
only care about the progress meter. Then again, I'd rather get away
from non-developers compiling software.
If you actually want to see output when your tests (from
add_test) fail, make test CTEST_OUTPUT_ON_FAILURE=1, otherwise
the only failure report you get is the name of your executable, not
anything it printed - like the list of tests that actually
failed. That that isn't on by default is ridiculous.
I recently finished reading Coders at Work. Rather than another site on the Internet praising it or damning some particular person in it, these are just some quotes that gave me pause.
[Patterns] show some kind of defect in the language. These patterns are not free. There's no free lunch. So we should be looking for evolution in the language that adds the right bits. Brendan Eich, p.148
Merriam-Webster's Collegiate Dictionary, 11th Edition. Never go anywhere without it. It's not something you actually need to read, but as I said, when you're writing programs you need to be able to name your identifiers well. Joshua Bloch, p.172
But people just want to put stuff in. What do engineers do? They write code. And if they are writing a library or writing a language, they want to put their stuff in. You need some presence, some guiding voice... Because there's simply more stuff that you could put in than you should put in to any given language. Joshua Bloch, p.195
Over the years I've kind of made a generic mistake and the generic mistake is to not open the black box. Joe Armstrong, p.211
Nobody's going to build a bridge that traverses the Atlantic any time soon. And [unlike normal bridges,] that really might fall down if you built it. But that's not the reason people won't build it - it's just because it'd be too expensive. Whereas nowadays, with software, once you can build bridges over the Channel pretty quickly and cheaply, well then, that becomes a done deal and we now think that's pretty cheap so we'll now try the Atlantic. And now it falls apart again. Simon Peyton Jones, p.280
Programming is a highly unnatural activity, I'm convinced, and it must be carefully learned. Guy Steele, p.360
I don't care that the program works. The fact you're working here at all means that I expect you to be able to write programs that work. Writing programs that work is a skilled craft and you're good at it. Now you have to learn how to program. Bernie Cosell, p.542
Also, Simon Peyton Jones mentioned Steven Clarke's API usability studies, which I was not aware of, and seems like a ridiculously good investment of time and money.
Peter Seibel (the author) has been aggregating interview questions by topic on his blog, calling out testing and C++ so far.
One thing I find myself needing sometimes in Python is a very light-weight sentinel value. It's not very common, but when I do need it it has unique requirements. Maybe I want to signal an special condition via a return rather than exception, or I want to return a guaranteed unique key for the caller to pass back later. These often need to be hashable for speed, lightweight in memory overhead, and ideally not compare equally to any other object in the system - so integers, floats, and strings are out. I could write my own class that does nothing, but that fails the "lightweight" requirement.
Luckily, Python provides exactly what I want in the object base type
used by all "new"-style classes:
a, b = object(), object()
a == b # => True
a == b # => False
a.foo = 1 # => AttributeError, base objects do not waste
# memory on instance dictionaries
{ a: 3 } # {<object object at 0xb7ce3498>: 3}
a is guaranteed to forever be unique in the land of Python variables,
and if it's initially created as a local variable, there's no way
(short of poking around in the gc) for anything to get an implicit or
indirect handle or equal object to it.
Fatal Labyrinth is a game for the Sega Genesis / Mega Drive, available emulated in several collections. It takes a couple hours to finish, but you will probably need to play it multiple times (or save scum) to do so.
As someone who played Nintendo consoles as a kid, my exposure to Sega is pretty much 1) Sonic, and 2) the trainwreck they are now. So Sonic's Ultimate Genesis Collection - the headlining title being the least interesting - is pretty much designed for me. One thing I was stunned to find on it was Fatal Labyrinth which as far as I can tell was the first console roguelike. In fact, released in 1990, it's contemporary with Angband (and so not too surprisingly, it's much more Hack-like than future Japanese roguelikes - persistent levels and only a cursory town).
Honestly? The game is crap, even if you can fly. But as is usual for roguelikes most comments complain about the reviewer's dislike of fundamental aspects of the genre, rather than the particular implementation. That is if you handed them Shiren, Pokemon Mystery Dungeon, and ADOM, they'd review them all the same.
The level generation, including secret doors, was fine. I think it was a little more interesting than the random generation present in later Chunsoft-developed roguelikes. Rogue is meticulously balanced in terms of food vs. exploration and Chunsoft games tended to ignore that by eschewing secret doors. While there's an abundance of food in Fatal Labyrinth you can't actually pick it up and need to eat it on the spot, so starvation is a real threat in the early levels if you explore inefficiently.
The "you've been on the level too long" notification, common in Japanese roguelikes, is found here. Probably for the first time. Between this and the food, the game does a good job of forcing you into progressively harder levels at the right pace.
There were breeders, enemies that spawn copies of themselves.
The theoretical difficulty curve was good, but I'll get to some particulars of why it was bad at the end.
The controls. I don't think I was happy with a set of roguelike controls on a dedicated gaming device until Izuna Ni. Notably, you can't turn without moving.
The UI. There's some excuse here for the same reason as the controls (I won't blame it for attack numbers getting truncated to two digits) but in other cases it's horrible. You can't see what an item is until you pick it up, you can't see how satiating food is until you eat it, and if you cancel out of the second or third stage of the three-level menu you need to start over from the first.
Loot is shallow. There's a lot of things (and the full gamut of types - armor, scrolls, wands, rings, and a couple classes of weapons) including some cursed items, but they don't have +X/-X variants variants.
The key place the game falls over is risk management. The primary goal of the player in a roguelike is to minimize the effect of the random number generator, because unpredictability is always what makes you lose. This problem manifested in two ways. First, damage variance was enormous. Tracking damage per hit looked like 12, 5, 106, 45, 19, 2, 95. Especially when you first encountered enemies I had no idea how much damage they could do, even after they hit me half a dozen times. Even if I knew I was safe I had no idea how long it would take me to kill the enemy.
Second, I had no options to mitigate non-damage risks. It's common for there to be rings or scrolls that will prevent some class of status ailment or raise your resistance to it but this game had no such thing I could find. I probably spent 90% of levels 15 to 25 confused, and all the items to fix that are consumable. None of the rings or armor offered me resistance benefits I could see, and the enemy attacks could be done at range so using a bow or shuriken did not help.
Fatal Labyrinth is a game I'm unlikely to ever play again, but as first efforts go it's an admirable re-imagining of Rogue for a console system.
While I am as excited for Pop CUTIE! Street Fashion Simulation as the next person (okay, a lot more than the next person), am I the only one that sees the inappropriateness of using a person in a dress as the iconic representation for "can wear this thing that is not a dress"?
But really, for a game with a Lu Bu Costume, I'll forgive a lot.
About five minutes walk outside of Tokione - somewhat risky, but in my opinion worth it - there's an impressive art installation. A small room lifted about three stories up contains an enormous portrait-framed window. Looking out the portrait gives you a beautiful view of the forest, one that you probably ignored not 30 seconds ago while on the ground, even though it's more impressive from down there. It's a thought-provoking rebuttal to Edward Tufte's "depedestalization" - why shouldn't we use thousands of years of artistic experience to make beautiful things stand out, whether they be natural or artificial?
Of course, the other interesting thing about this piece is that it exists only on the fictional planet of Landroll, in the game Opoona.
Art is universal to human culture - not necessarily the same forms or themes, but the same drive to abstract, represent, and express creatively. But the worlds of video games are bereft of non-functional elements - like toilets, one rarely finds art in video games. Final Fantasy X has a country united in culture, by religion and by common enemy, and yet has no recognizable architectural, musical, or visual artistic movements. Mass Effect expects us to believe that the only sculpture in the universe is one used to appease a wronged race after a war. How many games have entire palaces without any portraiture or sculpture? By contrast, the world-builders of Star Trek saw fit to create distinct styles of music, painting, literature, food, and even games for each alien race, and writers like Mike Resnick or China Miéville flesh out their alien worlds with an abundance of equally alien art.
"Fictional art" is a great way to enhance a game world believably and creatively. Its forms can range from the above, to TV shows in No More Heroes and Harvest Moon, books (fiction and non-fiction) in Elder Scrolls games, and the theater in Final Fantasy IX. Wipeout features a huge number of fake corporate logotypes, and Contact even has fictional videogames being sold in a fictional Akihabara! The converse is also true; missing or perverted art can add flavor to a dystopian culture. The state of Fort Frolic and Sander Cohen in Bioshock is particularly shocking because we know how art "normally" works, and how much it has been twisted in the game's world.
There's another side to this, and that's that video game worlds can provide a platform for art that might be otherwise inaccessible. Building an actual three-story-tall installation in a forest and keeping it up would probably cost more than Opoona did to make, be seen by fewer people (maybe not - the game barely sold 10,000 copies in Japan), and eventually come down. There's another installation in Innocent Life (probably not coincidentally also developed by ArtePiazza) which is a bunch of telephones installed in trees - where are you going to find an orchard to actually do that in?
There's a lot of unexplored possibilities. Where's the coffee houses filled with a new band every night (discs are definitely big enough now)? Or stand-up comedians? With the cliché cooking minigames, where are the great chefs in Breath of Fire? What music is playing on the Persona 3 protagonist's omnipresent headphones? Does Frank West look up to André Kertész? And when can Hyrule finally get some statues that weren't either built hundreds of years ago and/or turn into Armos?
« Page 6 / 6
