Messages

1

Temple of the Roguelike / Re: Moving away from BlueHost

« on: March 22, 2013, 12:51:07 PM »

A redirect on http://roguetemple.com/forums would be nice. Toss this in the directory's .htaccess:

Code: [Select]

RewriteEngine On
RewriteRule .* http://forums.roguetemple.com/ [R=301,L]


2

Programming / Re: Random Roguelike Town

« on: December 22, 2012, 12:32:00 AM »

This is for FFHtR, right? Why not take FFH buildings and put those in? For instance...

- Elder Council. Provides... identification? Scrolls, spellbooks, spells? Historical lore?
- Library. Obvious enough.
- Mage Guild. The more arcane alternative to the two above.
- Monument. Different cities could have monuments inscribed for different gods that could give you blessings.
- Catacomb Libralus: Every spellbook and scroll anywhere ever :p
- Hunting Lodge. Adventuring companions, light equipment.
- Inn, Tavern. News from the world, adventuring companions, quests.
- Herbalist. Cures and potions.
- Obsidian Gate. Free transport! Comes in kinda late in FFH though and I don't know when this game is set...
- Harbor. Exotic items.
- Grove. I assume that building a grove, given how expensive and late-game it is, involves not just planting some trees but founding a whole temple and all. Powerful nature-related stuff.
- Infirmary. Maybe a very cheap source of healing?

And so on and so forth. Really, if you stretch things a little you could get pretty far mostly only using buildings from FFH and maybe its modmods.

3

Programming / Re: Importance of persistence

« on: August 30, 2012, 11:23:31 AM »

26 bytes. That's a hell of a not much to work with. Haskell on 64-bit machine takes 40 bytes to store a string consisting of one character... 40 bytes plus the memory needed to actually store the character itself. How lucky we are to live in this time.

That's a tough one!

You might use a procedural algorithm to generate a list of loot locations.  Then you could use a couple of your precious variables as bitfields to indicate which entries in the list are still there.  You'd not be able to let the player drop things, but I don't think that would be a problem.  They pick up a +1 sword, it only replaces what is in their inventory if it's better than what they have?

Yea, I'd do that, and not let them return to previously visited levels as was already discussed.

You could get pretty far with this, I think. One problem you might have is that, well, suppose you use all of your leftover memory so you have 208 possible items in the game. Let's also say that you somehow manage to fit in equipment slots that are indexes into the item list. Let's say your weapon is at index 200. Okay, that's fine. You just start with the seed and generate all the 199 items before it and throw them away (or, more likely, pull out enough values to get it to the state where it would be when generating the 200th item). I'm not sure how slow the Atari 2600 is, but I suspect that you don't really want to generate hundreds of items' worth of random numbers every time you're using an item's stats. What you want is to be able to get the nth random number quickly.

http://mathoverflow.net/questions/104915/pseudo-random-algorithm-allowing-o1-computation-of-nth-element has a few approaches that might work. The latter seems especially nice - you just use a hash function as your PRNG, and to get the nth random value, you compute hash(seed+n). But try it without this first, I really have no feel for what's "a lot of computation" on ancient computers and this might be completely unnecessary complexity.

4

Programming / Re: Resizing Terminal Screen

« on: August 30, 2012, 10:49:11 AM »

One thing that I wish existed is Urwid for languages other than Python. ncurses is really low level, it doesn't do much beyond reading characters and putting characters on screen cells. That's exactly what you want for things like drawing the map screen and other such things that you need fine control for, but rather annoying when you want to implement an inventory menu for tefirst time. The Curses Development Kit is too high-level and inflexible - for instance, it has a menu widget that's probably fairly easy to use, but that also draws borders for you (which mightn't be what you want when you are working with a limited amount of character cells and want a visual style of your own), sets up a set of default keybindings that I'm not even sure you can change, etc.. Basically, ncurses does too little for you, while CDK does too much for you.

At least based on its documentation (I haven't actually used it), Urwid is the only console UI library I've ever seen that's actually based on modern UI library concepts. If you want padding around something, you pack it in a Padding widget, if you want borders you put it in a LineBox, and then when you use a Text or Button or BarGraph or whatever widget inside it, it draws nothing more on the screen than what you asked for. It handles laying text out into rows, it has mouse support, etc. the standard stuff. Being that it works on the widget level, it handles a lot of the trouble of resizing for you. It of course has deep support for extending the existing base of widgets and reusing as much code as possible to do that.

Oh, and just like basically every other UI library out there, instead of having the programmer call input functions and block on them, it has its own main loop and you write event handlers on your widgets instead. So, instead of saying do_inventory_menu() and doing stuff with its return value, you call up the inventory menu and place it in focus, so that coming input events will go to that menu and its event handlers (well, more correctly, they go to the topmost widget first and down through its children to the inventory menu until some widget handles the event and stops it from propagating further). I understand that mightn't go over well with developers who are so... libertarian... that even libtcod's really pretty low-level console is too much, and a lot of the reasons why UI libraries take control of the main loop are somewhat moot for roguelike interfaces anyway, but all the graphical programmers are living with an evented approach and they seem to be doing just fine.

5

Programming / Re: Monster spawning algorithm

« on: August 30, 2012, 08:33:50 AM »

Monster spawning is likely to be some form of a weighted random choice in most games. Well, I'm not sure how many games use it explicitly, but it's likely to be there in some form, and the method is general enough that at least explaining it should be a good way to get you started. The obvious implementation is putting all of the options in a list and iterating over that list twice (one example I found by googling), which should be easy enough to write and more than fast enough unless you have hundreds of thousands of monster types in your game.

Using weighted random choice reduces your question to what should be the probability of each monster type spawning, and that depends entirely on what kind of a game you want to make. Giving a very high frequency to monsters whose challenge level is close to the dungeon depth gives you more controlled, tunable gameplay where you know exactly what the player is going up against at each depth. Making the choice looser - for instance, you could simply have the depth work as a cut-off such that the probability of spawning any monster beyond that is zero, and have uniform spawn probabilities otherwise - gives breezier gameplay where the deeper the player is, the more they're facing comparatively shallow-leveled monsters (and the more of a relative threat a monster of their actual depth is, of course!).

Then you just tune and twiddle as necessary. Maybe give monsters a base frequency (so that red dragons are more common than turquoise spotted mechano-dracolichs, regardless of which one's a greater threat) . Maybe instead of single depth you could give them a level range, and multiply the base frequency by (say) a thousand if the current level is within the range. Or define spawn probabilities as second-degree polynomials of player depth. Have extra multipliers for themed levels, so that maybe the warrens level has a ten times bigger chance of spawning goblins. Have the super extra dangerous mid-game level have a high chance of spawning very out-of-depth monsters. Etc., etc.. Probabilities are simple and powerful things, you can do a lot of stuff with them once you get used to them.

6

Programming / Re: Good Settings for Free-Roam RogueLikes

« on: August 27, 2012, 10:11:43 PM »

One day I want to play a roguelike made by a historian of the medieval era. Or at least a developer who could play one on TV. You know, less automaton horses (warning: tvtropes link) and sword-wielding adventurers, more debate over whether the dog-headed men of the east have souls or not. Less grand castles and kings and knights, more barons with maybe one good warhorse. Less generally Anglo-Saxon countryside, more Kievan Rus' or Sultanate of Rum. Or something even crazier like Mali (with salt as the game currency, of course) or China or the declining Maya civilization... it's really a sin to use a word like "medieval" without qualifiers to describe a setting when there are so many cultures, so many societies, so many mythologies to draw from.

For a taste of what I'm trying to get at, try Alamut as a straightforward example of forming a setting based on medieval history, or UnReal World which is all about survival in Iron Age Finland. I don't think people should knock the idea of developing a setting by just choosing an underused historical place and time and rolling with it. Where there are people and societies, there are stories, there are dangers, there are myths, more than enough to make a game out of.

7

Other Announcements / Re: Share your ideas for 7DRL

« on: March 09, 2012, 09:26:39 PM »

I wasn't going to participate, but then I kind of got the picture from the latest Roguelike Radio episode that if you are a Real Man (or a Real Woman) you can still make a 7DRL even if you had plans to live a life otherwise. So I guess I'll be doing this, announcement on rgrd tomorrow and all.

I was thinking of a roguelike that takes the Paradox Mage class concept from TOME4 and supercharges it. You can time travel into the past - maybe a few dozen turns at most (I don't know yet how much memory it will take to store the previous game states the way I intend to) and change past events. AI actors will respond to you in the past, but previous versions of yourself will be completely oblivious to your existence. Causing changes in the past will increase your Paradox resource, and the more you've changed the past from the original timeline, the more Paradox you will build up. Just like in TOME, a higher Paradox powers up your spells and strange powers but also makes gameplay more dangerous and chaotic, and it takes concentration over time to reduce your Paradox. I have a weird science fiction explanation for all this planned out, too.

8

Programming / Simultaneous turns?

« on: February 28, 2012, 05:54:44 PM »

Just wondering - are there any roguelikes out there with a simultaneous turn system? Well, not a true simultaneous turn system where all actions are resolved fairly - I've seen Diplomacy's resolution rules, and trying to make even a simple game like that work with fair simultaneous turns seems to lead to horrible logical contraptions. But how about roguelikes with an initiative system? That is, every actor chooses an action and rolls initiative, and then those actions get resolved in initiative order.

As far as I can tell, the big downside is that simultaneous turns are harder to program. Instead of just changing the game state from the interface and/or AI code, you actually have to make a representation of actions and separate code to produce actions and resolve them into the game state. And since the world might have changed between when the action is selected and when it's resolved, you have to make the representation and the resolution code flexible enough that they can "guess" the "intent" of an action. For instance, if the player enters a walking action in a direction where there's currently a monster, that definitely has to be represented as a "bump this monster" rather than a "walk in this direction" action, because they mean entirely different things if the monster has moved away by the time your turn is resolved. And it's still not necessarily clear what that means either - what if the monster dies before you can attack it? What if bumping friendly monsters swaps places with them rather than attacking, and the monster becomes friendly before the player's action is resolved? What if the player in fact was expecting the monster to move away and in fact wanted to just move into that tile afterward?

The upside, though? There's a lot of interesting little things you could do with a concept of initiative and a certain sort of concept of simultaneity. You could design gameplay based on controlling initiative. Taking an earlier initiative slot could obviously have a great many uses - dodge out of the way of attacks, get to control your positioning better, hit things before they get a chance to hit you so that they don't get to hit you at all on the turn when they die, etc.. Taking a later slot probably could be useful in some cases, too, for instance for making sure that you moving next to a monster happens *after* that monster's turn so that it doesn't get a chance to hit you that turn. For that to happen there'd have to be some kind of a "reaction" mechanic so that, say, if you were just moving into a tile but a hostile monster takes the place before your action is resolved, you attack that monster instead. It would be kind of breaking the concept, but it would be interesting nonetheless if there were also a  "fast thinking" ability that could also allow the player to actually pick their actions at their time of resolution - no, I don't know how this would work if your initiative depended on what action you were actually taking.

Less importantly (but I'm mentioning it anyway since it amuses me), it would mean you could run your AIs in parallel as long as they're thread-safe and don't modify the game state. I'm pretty sure it doesn't matter for the vast majority of roguelikes, but it might be an appropriate design for the next Dwarf Fortress.

So far though I'm just curious if anyone's got experience of doing this or trying to. It seems more trouble than it's worth, but roguelikes cover a wide range of designs, so there's always a chance that someone's done it. Would be interesting to hear how it worked and try the game out.

9

Traditional Roguelikes (Turn Based) / Re: Fabula Divina Alpha releases unleashed

« on: January 28, 2012, 01:33:41 PM »

Can anything be done about game window constantly stealing focus (on Linux)? It's not much use for it to run windowed when you can't actually do anything in a different window...

10

Programming / Re: Cellular Automata

« on: January 24, 2012, 04:29:36 PM »

Yeah, I figured the only thing left to solve is figuring out how to replace lone #'s with a random item character.  And the ncurses thing. I figure the easiest way is to just save the output to a string, then print the string using ncurses when I need that level.

FWIW I believe the common ways to do that are either to just... do what you said, or have a function (or a member in the appropriate class, etc.) that returns what's in a given tile and call that function on each tile you're going to render. Not much of a difference really, but the latter can be more flexible.

11

Temple of the Roguelike / Re: All hail getter77, moderator of the boards!

« on: October 07, 2011, 07:13:55 PM »

The spam was getting a bit annoying. But I think we'll have ourselves a nice and clean and presentable forum from now on! (... and if we don't, I recommend adding more mods, I've gotten used to thinking of forums with visible spam on them as next to abandoned)

12

Other Announcements / Re: Roguelike Radio podcast

« on: September 27, 2011, 03:03:54 PM »

Strongly agree on the pointlessness of the tactics feature in ADOM. It's nearly always obvious what tactics are best to use (save some oddities like using aggressive tactics to train shields). And then, even worse, once you've conditioned yourself to do things like always mash f7 before running away from a fight, you get frustrated when other roguelikes don't let you power up your character so cheaply like that .

Madness/Featurecreeper is a nice example of a game with a light clock, although one with the same problems as food clocks in most roguelikes: It's pretty tight early on, but later on you tend to have at least a torch if not a lamp available pretty much all of the time.

edit: On the portability of console roguelikes, is it not possible to just make platform-specific batch files that open a terminal window with the game in it? It's not pretty but I know that at least DoomRL's Linux version does that.

13

Traditional Roguelikes (Turn Based) / Re: Infra Arcana release 8

« on: September 20, 2011, 08:56:04 PM »

Well, obviously DoomRL is DoomRL and Infra Arcana is a different game, and honestly it's probably best for aiming and vision to be exactly as permissive. But as it is, DoomRL has more permissive aiming than vision, meaning that for instance:

Code: [Select]

######
.....A
@#####
... here you can not see the A, but you *can* shoot at it. In that game it can be an essential tactic. But I don't know if I really want a mechanic like that to spread to other games...

14

Traditional Roguelikes (Turn Based) / Re: ARRP 2011: Magog 001

« on: September 20, 2011, 08:39:49 PM »

Having some trouble running this. After or when it loads text/text.factor, I get an error saying "The image refers to a library or symbol that was not found at load time". I can't seem to find out where it says *what* library or symbol is missing though.

15

Traditional Roguelikes (Turn Based) / Re: ARRP 2011 EmoSquid Update Released

« on: September 20, 2011, 08:30:10 PM »

I think the game might be having some problems with my multimonitor setup, it always starts on the main screen (1366x768) at the full size of the screen, which cuts off the bottom of the interface (possibly because my other monitor is 1280x1024 so it might be getting the height from that). Any way to set a custom resolution?