Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - AgingMinotaur

Pages: 1 [2]
Traditional Roguelikes (Turn-based) / Abura Tan, compiled for Linux?
« on: August 15, 2013, 05:56:19 PM »
Some of you remember Abura Tan, a promising RL set in a fantasy/western setting of "cowboy knights and lurking horrors", or something like that. It's been almost ten years since the last release, which is available as sources or a windows binary. Running Linux myself, I've been testing it a bit in a DOS emulator, but it does crash at intervals. I've not managed to compile it, but some other person might have had the skill to do it, so I figured I'd ask around here. This hominid has it running on a Raspberry Pi, but my compile-fu is so very, very weak.

As always,

Temple of the Roguelike / Main page error
« on: April 13, 2013, 06:36:10 PM »
If I try to direct Firefox to lately, I end up at an error page with url that says: "The website you were trying to reach is temporarily unavailable. Please check back soon. If you are the owner of this website, please contact Technical Support as soon as possible." Opening works …

As usual,

Early Dev / Land of Strangers
« on: April 03, 2013, 01:04:58 PM »
Name: Land of Strangers
Developer: Aging Minotaur
Environment: Windows (exe), Linux (deb), Python+pygame


Edit: This post left mostly unedited, but the download links should point to the most recent release. Check out later entries for more updated info about the project.

So, I didn't release anything for the 7drl (this year either), but the jam gave me some momentum to start a new project, currently entitled "Land of Strangers". It's a western themed RL that aims to incorporate some board/card game mechanics. I've uploaded a very early version, set in an endless desert populated by gunmen and scorpions. This version should give a pretty clear picture of how marksmanship and card mechanics are going to work, although there's no real game yet. Still, I'd appreciate all and any comments at this point – which is why I am writing this post.

My plan right now is to implement some of the ideas I was kicking around in my head prior to and during the 7drl week. After that, if I can convince myself that the idea scales well, I'll probably expand the game. It may also turn out it should just remain a tiny RL shooter, though.

Some of the current features include:

* Hitpointless/simplistic RL on a hexagonal grid,
* infinitely expandable world map with various enemies, obstacles, etc.,
* inventory-less, skill-less action system,
* pseudo-elaborate system for marksmanship,
* dual wielding revolvers while almost sober!
* Distributed as Python sources or Windows binary (binaries for Linux and OSX coming up)

As always,

Other Announcements / Roguebase currently down?
« on: February 19, 2013, 06:57:06 PM »
Anyone know? I try to open it at, but only get a placeholder page.

As always,

Off-topic (Locked) / Happy new year
« on: December 31, 2012, 04:48:03 PM »
The best of wishes to everyone in the year of the snake. Got to run now; bringing the kids over to a friend's to watch the fireworks and get peacefully wasted. See you in the next one.

As always,

Programming / Hexagonal UI (numpad-less)
« on: July 18, 2012, 11:42:07 AM »
Hey all. I'm in the early design phase of what may become a new game, planning basic features, UI, etc. I might like to implement hexagonal movement, but am at a loss as to how to do so, assuming not everyone has a numpad. Now I'm hoping to spawn some debate about the topic, to the benefit of myself and maybe others.

Some possible solutions include:

1) Mouse controlled: Sure enough, but the game should also be playable with the keyboard only, as God intended.

2) vi-keys: As if! Allowing the player to rebind the keys is a Good Thing, so vi-freaks and other weirdos can get their fix, but this is hardly a good default.

3) "weadzx", "uihknm" or some other vaguely hexagonal-shaped cluster of keys: I do find it's a bit of a shame to leave the arrow keys out of it. For one thing, it means a new player has to spend time consulting the manual/help before being able to play at all. Also, keyboards of different nationalities have different layouts. For instance, "weadzx" wouldn't work on a German keyboard.

4) Shift+arrow rotates 45°: Shift+up for northeast, shift+down for southwest, etc. Some games have this, and sooth to say, it does the job. On a hexagonal map, it's obvious from the outset that you're supposed to be able to move diagonally (as opposed to an 8-directional map, where some will just gleefully keep to the four cardinal directions). The problem remains that it's hardly obvious.

5) "Chords": Ie. simultaneously pressing up and right to move northeast, etc. Works well in games with continuous maps. In your typical RL, a problem would be how to handle keyboard input. If the program accepts commands the moment a key is pressed, it might become fiddly: If you want to move southwest, and press the down key a fraction of a second after the left key, you'd end up moving west once before turning southwest. Conversely, if commands are processed when a key is released, you'd have to repress the directional button(s) for every turn you wanted to move, which might become tedious.

6) Explicit facing and separate command to move/bump: Combined with 4) or 5), but pressing a direction would simply rotate your guy. There would be a separate key to advance (or bump, as it were). In winding corridors and the like, you'd probably want to automatically change directions when appropriate, as seen in Jeff Lait's 7DRLs and other games. As a small boon, this would make flow-breaking "zap in which direction"-prompts unnecessary, and might solve some issues I have with bumping in general, if well-designed. But I can foresee a lot of people having a problem with this solution. as it does increase the number of keystrokes significantly.

That's be about as far as I've come in considering this. I'd be happy to read what you guys might think. On a side note, I read Darren's "designing for non-RL-ers" with interest, and I think that text's defense of hexagonal movement is heroic. But in the context of making a truly "accessible" game in the terms outlined, I still ask myself whether four-directional movement isn't really the only plausible way to go. ;)

As always,

I know the era of great discussions concerning RL definitions is more or less past, but it just struck me that an important feature of most (all?) great RLs is that the player character works as a paper doll, with all the inventory slots for armor etc. Wearing and wielding the right stuff is an important strategic factor in Rogue and onwards.

It's not that I think the Temple definition should be revised, or anything, but I don't think this was much discussed in the Berlin interpretation, either, if I recall correctly. So I just wanted to see if the claim could spawn any discussion :) Any good counter examples? Thoughts on this feature?

One could certainly experiment with this sub game (to call it that), but I think, much like identification, it's not something you can just take out of an otherwise Roguelike game without considering how and why.

As always,

Programming / Any thoughts on explicit facing?
« on: September 19, 2011, 09:22:49 PM »
I'm considering whether explicit facing would be a good design desicion. What I have in mind, is a system where changing directions costs time. You would probably press left or right to turn, and up to advance. Some pros and cons as I figure:

+ circumvents attack-retreat strategy against slow opponents
+ may make stealth more playable (move past when guards look in the other direction etc.)
+ directional actions (open, zap) are executed with one keystroke, instead of command+direction
- movement more cumbersome, AI-wise
- can't be done in ascii – and sprites will have to be drawn facing every direction (yawn)

What say ye? Any thoughts on explicit facing, from the perspective of the player or the designer?

As always,

Traditional Roguelikes (Turn Based) / Squirm A.0.3.1
« on: December 03, 2010, 03:02:51 PM »

After long and many delays, a new version of Squirm is now out the door. At this point, the engine is almost at the point I had hoped for it to be for the ARRP ;) Various vicissitudes, both technical and personal, set me back with regards to game development.

This update is not very content heavy (although the overworld level should be of more interest now), but fixes several bugs. I think now that most or all show stopping bugs (crashing bugs as well as bugs that result in unwinnable game positions) should have been squashed. I hope to add more content for the next release (whenever that may be ::))

For those interested, the changelog can be found here:

Downloads here:

A.0.3.1 is currently only downloadable as sources. I'll whip together a Windows binary later tonight or during the weekend.

As always,

Early Dev / SQUIRM A.0.3 (alpha release)
« on: April 23, 2010, 10:22:19 PM »
(cross-posted to rgrd)

I am pleased to announce the very first alpha release of Squirm. Squirm is written in Python, and the game is opting to attend the first Annual Roguelike Release Party in September. The working title for the September release is "Nadir Expeditions".

At this moment, Squirm is a playable dungeon crawl with a win condition. It is also lacking and buggy in important ways. With the current release, Squirm is going into a feature freeze. Until September, I won't add any features, but will concentrate on fixing bugs, adding content and tweaking the existing engine. "Nadir Expeditions" will be a shortish roguelike with room for expansion. If time will allow me to develop Squirm into something even close to my original vision, remains to see.

Some features:

* Hunt pancakes and impress swashbucklers!
* Cutlery-clinching cannibals!
* Randomly generated centaurs!
* Guaranteed no orcs or rings!
* Simple (but utile?) interface ...

The game is designed to have static levels, with no respawns and no natural regeneration. There is no food clock, and no cash. There are a few side quests that pop up from time to time, in addition to the (macguffin based) main quest.

It's a bit scarace at the moment, but I think the game already has some merits. With this release, I am earnestly hoping for feedback from the community. Of special interest is comments regarding technical issues, and comments about the interface and the basic dungeon crawling experience.

Python sources (requires Python 2.* and Pygame) and Windows binaries, as well as some screenshots and development notes, can be gotten here:

As always,

Programming / A world without money
« on: November 01, 2009, 01:39:29 AM »
I've been trying to think up an alternative way to implement economy in a RL. I think the classic RPG trope of "collecting all the gold you can, and buying stuff at fixed prices" can become boring, and even slightly offensive ("Kill'em all! Take their stuff!") For my own game, I wanted something different, so I made a choice to leave money out of the picture, but I would also like some sort of economy, to implement encounters like peddlars, toll bridges, and so on. Besides, collecting treasure can of course be made fun.

Discuss. You don't even have to read the rest of my drivelling post, but I'll begin anyway:

A simple idea would be to implement some kind of barter economy. You give people gifts, with a special command, or by dropping stuff next to them. This pleases them, and they might do favours in return (which then displease them back towards a neutral bias). I'm sure this could be used for some interesting effects. Different critters like different loot (knights are happy to get weapons and armor, but not impressed with low-level stuff; farmers like food, tools, clothing), and might do different favours and give different gifts. Critters like shop keepers should be coded to haggle in a meaningful way. For instance, the player picks up what s/he wants, and starts dropping stuff s/he wants to pay with. When there's enough loot on the ground to satisfy the shop keeper, the player is allowed to leave the shop.

A different idea I had was to try and operate with a "wealth" trait (in my system, it would probably be a skill). This would be tested whenever you need to perform a transaction, like buying something or paying a tribute to the local temple. If you botch the skill roll, your "wealth" skill value is bumped down, and/or you don't get the benefits you wanted to pay for. ("Sorry, you don't have enough money to buy the foo.", "Is that supposed to be protection money? Get him, guys!") Great rolls would result in getting the benefits without a decrease in wealth (because the required prize is just small change to you). The idea was that wealth could be increased by recovering treasure from the depths. If you come out of the dungeon with a gold crown and four books, this might be taken as a representation of the loot you bring back. Wealth could be increased, and the stuff might as well even stay in the player's inventory. That way, you can furnish your house with the bounty you have from your adventures.

There are some loop holes in this "wealth skill" idea, however. First of all, you need limited inventory space, so that it's annoying to lug around useless stuff like sculptures. And it would only work with nonpersistant or semipersistant dungeons. If the player can just keep a stash at level 1 of every new dungeon, and carry out everything bit by bit, it's just pure grind. I thought about having perishable dungeons, that you can only enter one time. They would behave as persistant dungeons, but once you return to the surface, the staircase/portal disappears. Your adventure in that dungeon would be over; you failed or succeeded, and brought back no more than you could carry, but at least you survived, and there's bound to be another dungeon entry around here somewhere. This could be an interesting system, but of course it's a decision that affects the whole game in a big way.

And there are other issues I haven't really found a solution to: How do you avoid that the player just tries to buy the same sword one million times, until he lucks out on the skill roll? You might let shop keepers close their shops after the player has (tried to) buy anything. This kind of fits in with the time horizon implicit in "perishable dungeons". Buying would be a betting game, where you assess how much you can afford, and you get one shot at paying. The shop keepers would then reopen once the player ascends from the next dungeon. But this might lead to a kind of stairhopping, unless the player is punished for not completing a dungeon, or something like that. And besides, it strikes me as a "feature" that could easily just be annoying. Failing to buy healing remedies for your next expedition, just because of an unlucky die roll, would probably not be so pleasurable. But if it's perfectly balanced, the player should always think, "Ok, I got too greedy, and now I'm being punished for it." :)

Rambling as always,

Other Announcements / Shockfrost
« on: September 25, 2009, 12:53:34 PM »
It struck me after having written a message in the Difficulty thread that it contained an unconcious reference to an idea of Shockfrost, that legendary spewer of ideas. This had me reviewing the old Shockfrost-thread on rgrd. Even though Shockfrost is a classic of RL paraphernalia, he's not referenced so often, so here's a reminder, to the benefit of new and old readers alike. Read the Roguebasin article on Shockfrost here. And here you'll find the extraordinary discussion thread.

With that, I'll shut my ugly face and leave the talking to Shockfrost. If any discussion comes out of this, I might chime in later.

As always,

Programming / Inept question about probability
« on: September 15, 2009, 05:46:53 PM »
EDIT: some crude testing suggests that my code works just as it should. Sometimes it's better to think things over twice before posting for help. Ah, well ...

Sometimes I'm feeling very stupid. Like ... just about now. Someone with a clearer mind should be able to help me out with this one.

I'm reworking the parts of my code that picks a random element from a set (of monsters, or items, or something else). First, the possible choices are put in a python dictionary, where the key is the name/identifier of the element, and the value is the relative probability of that element showing up. Something like this, in other words: {'sword':1, 'croquet club':2, 'knife and fork':4} In this example, croquet clubs should be twice as probable as swords, and cutlery four times as probable. Here's what I'm uncertain about:

Code: [Select]
def draw_lot(pd): # pd is the dictionary of stuff
    full_prob=reduce(lambda x,y : x+y, pd.itervalues()) # adds all values,
            # ie. sets full_prob to 7 in the example with the weapons
        choice=random.randint(1,full_prob) # a number between 1 and full_prob
        while 1:
            k=pd.popitem() # pops a random key+value from the pd dictionary
            if k[1]>=choice: # k[1] is the value, ie. 1, 2, or 4
                return k[0] # returns name of picked item

This works pretty fast, but I'm unsure as to whether it produces the intended effect. Will it actually return clubs twice as often as swords, and cutlery twice as often as clubs? I feel like I've a short circuit here somewhere, but I can't wrap my mind around it. So, any help regarding this would be appreciated.

As always,

Programming / (un)acceptable memory usage
« on: April 06, 2009, 05:16:59 PM »
Here goes: Actually kind of a support question from a n00b :-[

I've been working on this roguelike, (badly) written in python+pygame. I have no formal training as a programmer, instead learning as I go along, and focusing on effect rather than good programming habits. At the outset, it seemed a good idea to make "everything" (monsters, items, walls, etc.) instances of the same class. This does indeed provide me with a very flexible system, but it turns out to have its down sides. At the moment, I am concerned with memory usage. Even an "empty" instance of this class, where all variables (a little more than 70) are set to False, takes up about 5.5 kB of memory. Obviously I don't understand how python handles memory, since I can't understand why. Does the functions defined in the class (more than a few) take up space, or something like that?

A few days ago, a single dungeon level would take up more than 50 megabytes of RAM. That boggles the mind. Even after some ugly tweaks, a level with monsters, treasure and various features requires something like 5 mB. This leaves me with a potential application that will eat up hundreds of megabytes for a reasonably long game.

So I hope I might benefit from the wisdom of more seasoned programmers. Is it to be expected that python objects take up this crazy amount of memory? Are there some generic, nifty tricks to reduce memory usage that I should know of? Or simply a doc describing the basics of how python allocates memory (articles I find on the web, seem mostly to focus on particular cases)?

Any hints (or just friendly ridicule) would be greatly appreciated.

As always,

Classic Roguelikes / The greatness of Crawl
« on: January 14, 2009, 11:20:00 PM »
Sorry if I'm rambling.

First of all: Congratulations to this year's winners of ASCII dreams' Roguelike of the year. Last year saw Dwarf Fortress take home the gold. I never dared to play DF. Instead I like to envision it as sort of a "Finnegan's Wake" of roguelikes, a piece of work you should only approach after intense meditations. This year, one of the recognized "major roguelikes" prevailed, demonstrating that quality never goes out of style, even in these modern times.

The sense of having a canon of the genre, is very strong in the roguelike community. We have the classics: Nethack, Angband, etc. Amongst the slightly younger roguelikes, there are some bodies of work that are recognized as major (I consider games like ADOM and Crawl "young" in this sense, although they certainly feel like modern roguelikes, even today). Of all the most celebrated games of the genre, Nethack and Crawl are the two I know the least.

I haven't been playing much of any roguelike recently, but I had a period this summer when I started playing Crawl. As I'm tinkering on my own project, I've been asking myself questions about what makes a good roguelike, and recently, I found myself thinking about Crawl again. I can very much understand Crawl's popularity. At the same time, I don't experience the same thrill as I did when starting to play Angband (my first rl) or ADOM. Maybe the genre is growing old on me, or Crawl just doesn't suit me as well as some other games.

To my mind, Crawl's greatness comes perhaps with the polish. It is such a carefully crafted game. I must honestly say that I find the interface slightly baroque (I never understood why taking off jewlery and removing a piece of armor needed separate commands). But once you get to know it a bit, it makes interaction with the game very smooth. One of the things I dislike about ADOM, for instance, is all the tedious voyages up and down already explored dungeons to reach the different way points (going down the caverns of chaos after clearing the tower of eternal flames, etc; so one of ADOM's greatest strengths is also a weakness). Crawl commands like Shift-X are pure genius, I think.

Compared to some of the more ideosyncratic roguelikes, Crawl could be called dry. I never played a roguelike that felt more "intelligent", if you know what I mean. The brilliant logic of the interface is backed by a setting that is frugal, while still fascinating to explore. One could almost call it realistic. Even with the weird mixed-up randomnesses you end up guiding down that dungeon (which always takes you by surprise, in the end), there is some suspension of disbelief. The game seems to be built on a vast amount of experience. Where the creators of Rogue were really dabbling in the dark, exploring a very new territory in game design, Crawl's designer was already schooled in the classics.

On the one hand, I can think that Crawl is too conservative for me. But I must admire it's stringency. I will no doubt continue to crawl now and then, thinking maybe I will one day learn to walk.

So, I guess I propose that Crawl owes much of its popularity to the smooth interface. Then again, I never got any deep in the game. For instance, I've not yet drawn the attention of the gods.

Feel free to enlighten me with your own experiences and thoughts on the subject. What makes crawl great (or not so great), in your views?

Pages: 1 [2]