A post-cyberpocalyptic RPG about basketball? What's not to like about this game?
The gameplay is solid, with an unconventional battle system, lots of puzzles and secrets abound. It's also hilarious to boot, and even makes a few nods to Space Jam, if you've ever watched that. Highly recommended.
If you can't slam with the best, then jam with the rest.
Monday, January 28, 2008
Thursday, January 24, 2008
Wednesday, January 23, 2008
"ANSI Common Lisp" and bst-remove
I like Lisp. Compared to a lot of other languages, it's pretty damn nice. I don't know it very well, so I'm learning mostly out of textbooks, mostly in my free time. One such textbook is Paul Graham's ANSI Common Lisp.
It's a solid book, it's engaging, but what I really like about it is that it leaves just the right amount of room for free thought. Case in point: I reached section 4.7, which is an example implementation of a binary search tree. Everything was going smoothly until I hit bst-remove. I read through the section, and I understood Paul's approach, which was good: I was making progress.
At this point, I'd just been through Lisp "structs" country, and instead of the lame :print-function for the node struct that just printed out the object/number at that node, I decided to roll my own.
So instead of this:
I wrote this:
Paul mentions in the book that the depth parameter can be safely ignored, but I figured that since it wasn't being used for anything else, I may as well use it myself. Anyway all my version does is print the full sub-tree under the given node with indentation to give it that pseudo-graphical charm. Once I reached bst-remove, this was how I was printing all of my intermediate results with mucking about with my experimental binary search tree.
I stumbled across the error by deleting a node from the far left of the tree, leaving the node above with only a right child, which is fine. It doesn't always happen because the book's algorithm uses (random 2) to try to maintain tree balance. Say if there's a parent node 2 with two children 1 and 3 as left and right sub-trees respectively, then deletion of 2 would pull 1 up, 50% of the time.
Now suppose 2 was the left sub-tree of yet a bigger binary search tree, and the node immediately above 2 is 5. We delete 2 as above, and now let's delete 5, and say 2's successor (1) is chosen to replace 5. There's now a hole where 1 is supposed to be, and the algorithm states that one of the immediate children must take its place. 1 only had one child.
Here's where things go wrong. 1's only child was 3. Since 1 was less than 5, it was a left child to it. Dragging up 1 doesn't cause any problems. However, dragging up 3 to take 1's old place now makes 3 a left child, not a right one like it should be. The tree is broken. It wouldn't have been entirely obvious if I wasn't looking at the tree structure at each point, but I'm happy that I did.
That was last night. Today, a bit of poking around in Paul Graham's website shows this error has been found and corrected in the book's errata. It's the one on page 71. Regardless, I'm happy I spotted that, because it means that I'm learning and paying attention.
My only regret in all this is that I didn't have the tenacity to write a replacement bst-remove before finding the corrected code (linked in the book's errata page.) Thank you intertubes for making me lazy.
ed: I should have included some M-x artist-mode diagrams for this. :)
It's a solid book, it's engaging, but what I really like about it is that it leaves just the right amount of room for free thought. Case in point: I reached section 4.7, which is an example implementation of a binary search tree. Everything was going smoothly until I hit bst-remove. I read through the section, and I understood Paul's approach, which was good: I was making progress.
At this point, I'd just been through Lisp "structs" country, and instead of the lame :print-function for the node struct that just printed out the object/number at that node, I decided to roll my own.
So instead of this:
(defstruct (node (:print-function
(lambda (n s d)
(format s "#<~A>" (node-elt n)))))
elt (1 nil) (r nil))
I wrote this:
(defstruct (node (:print-function print-node))
elt (l nil) (r nil))
(defun print-node (n stream depth)
(when n
(print-node (node-r n) stream (1+ depth))
(do ((i 1 (1+ i)))
((>= i depth))
(format stream " "))
(format stream "~a~%" (node-elt n))
(print-node (node-l n) stream (1+ depth))))
Paul mentions in the book that the depth parameter can be safely ignored, but I figured that since it wasn't being used for anything else, I may as well use it myself. Anyway all my version does is print the full sub-tree under the given node with indentation to give it that pseudo-graphical charm. Once I reached bst-remove, this was how I was printing all of my intermediate results with mucking about with my experimental binary search tree.
I stumbled across the error by deleting a node from the far left of the tree, leaving the node above with only a right child, which is fine. It doesn't always happen because the book's algorithm uses (random 2) to try to maintain tree balance. Say if there's a parent node 2 with two children 1 and 3 as left and right sub-trees respectively, then deletion of 2 would pull 1 up, 50% of the time.
Now suppose 2 was the left sub-tree of yet a bigger binary search tree, and the node immediately above 2 is 5. We delete 2 as above, and now let's delete 5, and say 2's successor (1) is chosen to replace 5. There's now a hole where 1 is supposed to be, and the algorithm states that one of the immediate children must take its place. 1 only had one child.
Here's where things go wrong. 1's only child was 3. Since 1 was less than 5, it was a left child to it. Dragging up 1 doesn't cause any problems. However, dragging up 3 to take 1's old place now makes 3 a left child, not a right one like it should be. The tree is broken. It wouldn't have been entirely obvious if I wasn't looking at the tree structure at each point, but I'm happy that I did.
That was last night. Today, a bit of poking around in Paul Graham's website shows this error has been found and corrected in the book's errata. It's the one on page 71. Regardless, I'm happy I spotted that, because it means that I'm learning and paying attention.
My only regret in all this is that I didn't have the tenacity to write a replacement bst-remove before finding the corrected code (linked in the book's errata page.) Thank you intertubes for making me lazy.
ed: I should have included some M-x artist-mode diagrams for this. :)
Monday, January 14, 2008
The sound of free software
I know this isn't news, but...
Opening an instance of Emacs will never be the same again.
Opening an instance of Emacs will never be the same again.
Saturday, January 12, 2008
slime-close-parens-at-point
So I'm learning Lisp. I'm doing this by using Emacs and SLIME. That's cool, right? This combo is far and away the closest I've ever been to "interactive programming", and the experience is very, very cool. It's quite true when you hear somebody say that you need a Lisp-aware editor to truly experience Lisp. Things have mostly been going smoothly.
Except C-c C-q. This key chord supposedly triggers (slime-close-parens-at-point), which will insert just enough parentheses as necessary to make the whole surrounding expression valid. Before, I was using C-c C-], which dumps as many parentheses to finish all expressions before it, a different matter altogether. Sounds like a time-saver, right?
It would be, if not for the fact that the damn thing doesn't work. Terminal Emacs? Nope. GTK+ Emacs? Nope. In the SLIME REPL? Nope. In a Lisp buffer while SLIME is active? Nope. Why does this one thing not work? I can use other key chords just fine, like C-c C-c to incrementally run a function definition on the spot.
I'm going to do some Googling, but if anybody knows what the deal is, please leave a comment.
Except C-c C-q. This key chord supposedly triggers (slime-close-parens-at-point), which will insert just enough parentheses as necessary to make the whole surrounding expression valid. Before, I was using C-c C-], which dumps as many parentheses to finish all expressions before it, a different matter altogether. Sounds like a time-saver, right?
It would be, if not for the fact that the damn thing doesn't work. Terminal Emacs? Nope. GTK+ Emacs? Nope. In the SLIME REPL? Nope. In a Lisp buffer while SLIME is active? Nope. Why does this one thing not work? I can use other key chords just fine, like C-c C-c to incrementally run a function definition on the spot.
I'm going to do some Googling, but if anybody knows what the deal is, please leave a comment.
Compiz Fusion, Translucency and YOU
So I do a lot of coding and text editing in the terminal. Fire up the terminal by presing Alt+N, type "vim", and I'm ready. I set my terminal background to be translucent, which is handy for seeing stuff through the other stuff you're doing.
The lack of translucency always bugged me about both GVim and Emacs. Neither of those applications seem to come with the option to enable translucency at all, which makes reading or referring to other material a very Alt+Tabby affair. So with the terminal I stuck.
Until now. I was screwing around with modifier keys and the mouse wheel last night, and found out something about Compiz Fusion and window translucency:
Hold down Alt and scroll the mouse wheel to change the translucency of the window the mouse cursor is over.
Handy, no?
The lack of translucency always bugged me about both GVim and Emacs. Neither of those applications seem to come with the option to enable translucency at all, which makes reading or referring to other material a very Alt+Tabby affair. So with the terminal I stuck.
Until now. I was screwing around with modifier keys and the mouse wheel last night, and found out something about Compiz Fusion and window translucency:
Hold down Alt and scroll the mouse wheel to change the translucency of the window the mouse cursor is over.
Handy, no?
Tuesday, January 8, 2008
Dud characters
So I play RPGs. These games have characters, often many characters. But only a few characters are allowed to be in the party, or at least fighting. Those in the party get stronger and stronger, and those who aren't get weaker in comparison.
Therefore, at best, switching characters is an inconvenience: wading through menus, having to choose who to take, and sometimes even having to backtrack to a certain place. At worst, it's a massive pain, as you discover how weak these guys really are.
A while ago, my sister was playing Legend of Dragoon on the PSX. She managed most of the game just fine, but when it came to this one particular boss, not even repeated attempts could get her through. It must have been the fifth attempt when I suggested that she use the dumb, stupid sideline characters that were never used. She beat the boss on the first try.
I was just playing Front Mission 3 on the PSX. So far, I've beaten every battle with flying colours, but this one tiny map with a bunch of powerful wanzers (wanderung panzers, German for "walking tank" and the main unit of the game) were proving difficult. The situation was a bit different, this time I was forced to use one of my dud characters (Pham, for those who have played the game.) My first attempt at the battle failed slowly and dramatically when I got into the unfortunate situation of losing both arms on the two wanzers that were still on the field and ran out of restoration items. I even had these two pilots eject from their walking robots and shoot their pistols at the one remaining threat, but this thing had powerful evasion bonuses, and I ultimately lost.
My second attempt shared nearly exactly the same strategy as the first, but with one tiny difference: I attacked with Pham's wanzer first for each turn. I made this decision after I noticed she had more HP on her robot than my main machine-gunning guy. This tiny difference was enough to seal the battle for me.
So you see, even the dud characters have their time in the spotlight, so don't neglect them.... too often. I do miss the old hey-day of the original Front Mission though, where you could opt to deploy everybody for every battle.
Stupid people, on the other hand...
Therefore, at best, switching characters is an inconvenience: wading through menus, having to choose who to take, and sometimes even having to backtrack to a certain place. At worst, it's a massive pain, as you discover how weak these guys really are.
A while ago, my sister was playing Legend of Dragoon on the PSX. She managed most of the game just fine, but when it came to this one particular boss, not even repeated attempts could get her through. It must have been the fifth attempt when I suggested that she use the dumb, stupid sideline characters that were never used. She beat the boss on the first try.
I was just playing Front Mission 3 on the PSX. So far, I've beaten every battle with flying colours, but this one tiny map with a bunch of powerful wanzers (wanderung panzers, German for "walking tank" and the main unit of the game) were proving difficult. The situation was a bit different, this time I was forced to use one of my dud characters (Pham, for those who have played the game.) My first attempt at the battle failed slowly and dramatically when I got into the unfortunate situation of losing both arms on the two wanzers that were still on the field and ran out of restoration items. I even had these two pilots eject from their walking robots and shoot their pistols at the one remaining threat, but this thing had powerful evasion bonuses, and I ultimately lost.
My second attempt shared nearly exactly the same strategy as the first, but with one tiny difference: I attacked with Pham's wanzer first for each turn. I made this decision after I noticed she had more HP on her robot than my main machine-gunning guy. This tiny difference was enough to seal the battle for me.
So you see, even the dud characters have their time in the spotlight, so don't neglect them.... too often. I do miss the old hey-day of the original Front Mission though, where you could opt to deploy everybody for every battle.
Stupid people, on the other hand...
Monday, January 7, 2008
Thoughts on KDE 4.0.0
off-topic: First look at the unreleased KDE4.0.0 (with screenshots)
In my time in Linux, I've spent some time with KDE, but my heart's always been with GNOME.
I don't remember who I heard this from, but it's absolutely right. I may be a programmer and self-confessed geek, but I'm also very very lazy and intent on getting things done without my tools getting in my way.
If I'm a GNOME user, why on earth would I be interested in the new KDE release? There are only two reasons I haven't stuck with KDE: its interface hell, and the fact that it often looks like butt. Nowadays, spending any amount of time in KDE is the equivalent of setting eye razors as my background.
But it looks like things are changing, if the screenshots are anything to go by. I always said to myself that I'd give KDE another chance if it stopped looking like butt, and it doesn't look like butt anymore. Who knows? Maybe I'll be using KDE this very day next year.
And if that makes me a superficial bitch, then I guess I'm a superficial bitch.
In my time in Linux, I've spent some time with KDE, but my heart's always been with GNOME.
The best interface is one that you don't notice.
I don't remember who I heard this from, but it's absolutely right. I may be a programmer and self-confessed geek, but I'm also very very lazy and intent on getting things done without my tools getting in my way.
If I'm a GNOME user, why on earth would I be interested in the new KDE release? There are only two reasons I haven't stuck with KDE: its interface hell, and the fact that it often looks like butt. Nowadays, spending any amount of time in KDE is the equivalent of setting eye razors as my background.
But it looks like things are changing, if the screenshots are anything to go by. I always said to myself that I'd give KDE another chance if it stopped looking like butt, and it doesn't look like butt anymore. Who knows? Maybe I'll be using KDE this very day next year.
And if that makes me a superficial bitch, then I guess I'm a superficial bitch.
Friday, January 4, 2008
I just finished POWDER
Well that was fast.
And thus, the inappropriately-named FUCK completed his quest to escape the dungeon by killing some demon at the 25th level and retrieve its heart. It's kinda unfair: what'd this demon ever do to him?
Come to think of it, killing that demon was one of the easier fights in my play-through of POWDER. I fought it over the water in my water-walking shoes; I actually had more trouble and took more damage finding the heart submerged while I nearly drowned in my armour.
Some lessons learned:
The following should not be eaten:
Warning is the reason why I appear as a question mark in the screenshot: I can sense myself. Warning allows you "see" all enemies, but only by their relative threat level. Compare this against the power of telepathy, which only detects a subset of enemies ("intelligent" ones) and doesn't show how dangerous they are at all.
There's only one bad one, and that's the scroll of fire. Try not to do too much random scroll reading at low HP.
Anyway, here I am on the surface... I think I'll duck back down into the dungeon for something to eat. I swear that place is like a DIY buffet.
And thus, the inappropriately-named FUCK completed his quest to escape the dungeon by killing some demon at the 25th level and retrieve its heart. It's kinda unfair: what'd this demon ever do to him?
Come to think of it, killing that demon was one of the easier fights in my play-through of POWDER. I fought it over the water in my water-walking shoes; I actually had more trouble and took more damage finding the heart submerged while I nearly drowned in my armour.
Some lessons learned:
Get food, eat food
For variety's sake, I'd chosen Endure Hunger over Clean Kill (leave a corpse with virtually every kill). All the games before that I chose the latter. Now I know why.The following should not be eaten:
- slugs of any kind
- invisible stalkers
- chameleons (unless randomly polymorphing is your idea of fun)
- dragons and elementals (they just give you elemental weaknesses)
Reflection is fun!
In programming and in POWDER. I was lucky enough to get a shield of reflection early on, and it basically makes you impervious to any ray-based magic or dragon's breath attacks. They're more common than you'd think.WARNING
Helms of warning > helms of telepathy.Warning is the reason why I appear as a question mark in the screenshot: I can sense myself. Warning allows you "see" all enemies, but only by their relative threat level. Compare this against the power of telepathy, which only detects a subset of enemies ("intelligent" ones) and doesn't show how dangerous they are at all.
Beware cockatrices
The single most annoying enemy in the game. It petrifies, and it attacks on sight. I used wands of sleep to get around them, as well as divine intervention (which can sometimes restore you.)Cave trolls
They revive. You can tell because attempting to eat their corpses always fails. I supposedly killed 25, with other kill counts running only up to about 10 or so, but it looks like it counts re-kills too.Faith
Each level-up gives you the chance to worship a deity. Choose one and stick to one, because they'll do handy things like heal you, purge poison, revive petrification, and give you free things. None of that tribute bullcrap in other roguelikes.Zap unknown wands at monsters
Most wands have a negative effect that will harm you if you zap yourself, except the wands of light, digging, speed and invisibility, and perhaps teleportation. Most are just medieval pistols.Read all scrolls
Unlike wands, virtually all scrolls have some sort of positive effect. Pick up a lot of exotic items, and read a scroll of identify, and suddenly you can see how awesome your inventory really is, while avoiding cursed-item landmines.There's only one bad one, and that's the scroll of fire. Try not to do too much random scroll reading at low HP.
Anyway, here I am on the surface... I think I'll duck back down into the dungeon for something to eat. I swear that place is like a DIY buffet.
Thursday, January 3, 2008
POWDER
When I first stumbled across this title at The Linux Game Tome, I was half-inclined to believe it was something to do with drug-smuggling. To my pleasure/disappointment, it was a roguelike, which, come to think of it, tends to have the same addictive quality.
Like any other roguelike, you run around in a tile-based dungeon and beat stuff up until you die or complete whatever psychotic quest the creator has assigned to you. Unlike a lot of roguelikes, this game is not only available on Windows and Linux, but also comes in GameBoy Advance and Nintendo DS ROM flavours. In fact, the game was originally designed for the GBA, which shows in its restriction to 4-way movement and the fact that a context menu is available for all actions.
It raises an interesting point: why do dungeon crawlers suck so much on consoles?
It's not the addition of nice graphics. I think nice graphics are a good thing, and certainly something that a lot of games could benefit from. It can't be the controls, since the controls in POWDER are quite workable.
My theory is that the game development teams are too preoccupied with the 'random' concept that is intrinsically present in roguelikes as a whole. The very term "roguelike" is coined from the game "Rogue", which has been around for decades. The field has gotten used to the random concept, and often pushes ahead to add their own individual flair, such as ADOM with Tower of Fire and underwater levels, and Nethack with the many and varied ways to do things with other things. In POWDER, worshipping deities actually makes a difference, and the gameplay is deceptively simple, hiding a large and varied core. Looks like it was pulled straight out of the VGA era though, graphics-wise.
Console dungeon crawlers are just that: dungeon crawlers. The developers get it all wrong, nearly all of the time. I couldn't stand more than 10 minutes of any version of Azure Dreams, because the levels all looked and felt the same. The items hardly varied, and the effects were uninteresting. In POWDER, I can throw a knife straight up, just to fall back down on my head and stab me. It's totally useless, but it's amusing and shows that the creator put thought into the game. I don't think I've ever come across an effect in a console dungeon crawler and thought, "Wow! That was cool!"
It seems a bit strange, but it's the non-random bits of roguelikes that make them really stand out. POWDER delivers.
Anyway, there are four versions of POWDER available: Windows, Linux, plus GBA and NDS ROMs. If you're after something for your cell/mobile phone instead, look into Dweller (looks like the main site has fallen into disrepair, but you can still find it in Google's cache if you search for "dungeon dweller". First hit.).
Like any other roguelike, you run around in a tile-based dungeon and beat stuff up until you die or complete whatever psychotic quest the creator has assigned to you. Unlike a lot of roguelikes, this game is not only available on Windows and Linux, but also comes in GameBoy Advance and Nintendo DS ROM flavours. In fact, the game was originally designed for the GBA, which shows in its restriction to 4-way movement and the fact that a context menu is available for all actions.
It raises an interesting point: why do dungeon crawlers suck so much on consoles?
It's not the addition of nice graphics. I think nice graphics are a good thing, and certainly something that a lot of games could benefit from. It can't be the controls, since the controls in POWDER are quite workable.
My theory is that the game development teams are too preoccupied with the 'random' concept that is intrinsically present in roguelikes as a whole. The very term "roguelike" is coined from the game "Rogue", which has been around for decades. The field has gotten used to the random concept, and often pushes ahead to add their own individual flair, such as ADOM with Tower of Fire and underwater levels, and Nethack with the many and varied ways to do things with other things. In POWDER, worshipping deities actually makes a difference, and the gameplay is deceptively simple, hiding a large and varied core. Looks like it was pulled straight out of the VGA era though, graphics-wise.
Console dungeon crawlers are just that: dungeon crawlers. The developers get it all wrong, nearly all of the time. I couldn't stand more than 10 minutes of any version of Azure Dreams, because the levels all looked and felt the same. The items hardly varied, and the effects were uninteresting. In POWDER, I can throw a knife straight up, just to fall back down on my head and stab me. It's totally useless, but it's amusing and shows that the creator put thought into the game. I don't think I've ever come across an effect in a console dungeon crawler and thought, "Wow! That was cool!"
It seems a bit strange, but it's the non-random bits of roguelikes that make them really stand out. POWDER delivers.
Anyway, there are four versions of POWDER available: Windows, Linux, plus GBA and NDS ROMs. If you're after something for your cell/mobile phone instead, look into Dweller (looks like the main site has fallen into disrepair, but you can still find it in Google's cache if you search for "dungeon dweller". First hit.).
Wednesday, January 2, 2008
Stupidity? Meet opportunity.
According to some source I just pulled out of my arse, a blog is born every two seconds. As if we didn't have enough already.
Here's what I'm interested in and therefore post about:
Here's what I'm interested in and therefore post about:
- old-school retro games
- computer programming
- lol internet
- other stupid geekery
Subscribe to:
Posts (Atom)