Topics

1

Programming / Oh boy, adventures in rebinding variables!!! (Python)

« on: May 17, 2014, 02:51:41 AM »

That sounds like a fantastic name for a roguelike, incidentally.

So, I'm having a number of problems, and I suspect they are related to my limited understanding of how variables are bound and re-bound.  I don't understand why the following code:

count = 0

def increment(x):
    global x

2

Programming / Generating a list of unique random numbers

« on: April 12, 2014, 03:46:32 AM »

So, I've been trying to understand random dungeon generation, and have really gotten sidetracked on a tangent related to generating lists of random numbers.  It's driving me crazy, and I can't go forward with working on making an actual roguelike until I can resolve the questions I have.  Sorry if this question isn't as directly related to programming a roguelike as some of the others on this board, but I know you guys/girls and I think you are my best chance for getting an answer that I can understand.

I want to generate a list of unique random numbers in the following way:

1. generate a random number
2. check to see if it is already in the list
3. if not, append it
4. if so, chunk it and go back to step 2

I *don't* want to do something like this code that I wrote:

from random import randint

random_list = []

random_source_list = [i for i in range(10)]

print random_list

print random_source_list

while len(random_list) <= 9:
    random_index = randint(0, len(random_source_list) - 1)
    random_list.append(random_source_list[random_index])
    random_source_list.remove(random_source_list[random_index])

print random_list

print random_source_list

It works, but I want to be able to accomplish my goal in the way that I stated previously.  Nor do I want to append a random number to the list, check for repeats, and then delete repeating numbers until I get a list of all uniques.  I already came up with a way to do it like that, but it just seems sloppy to me to use trial and error.  And I don't want to use classes either.

I realize these criteria must seem arbitrary, but this is something that I'm trying to figure out as a personal challenge, and it's about to drive me nuts.

3

Design / Really, really basic libtcod question

« on: March 15, 2014, 02:07:40 AM »

EDIT:  Arrgh, I meant to post this in programming.  Sorry.

I'm trying to understand this code (which is from the roguebasin python + libtcod tutorial):

import libtcodpy as libtcod
 
#actual size of the window
SCREEN_WIDTH = 80
SCREEN_HEIGHT = 50
 
LIMIT_FPS = 20  #20 frames-per-second maximum
 
 
libtcod.console_set_custom_font('arial10x10.png', libtcod.FONT_TYPE_GREYSCALE | libtcod.FONT_LAYOUT_TCOD)
 
libtcod.console_init_root(SCREEN_WIDTH, SCREEN_HEIGHT, 'python/libtcod tutorial', False)
 
libtcod.sys_set_fps(LIMIT_FPS)
 
while not libtcod.console_is_window_closed():
 
    libtcod.console_set_default_foreground(0, libtcod.white)
 
    libtcod.console_put_char(0, 1, 1, '@', libtcod.BKGND_NONE)
 
    libtcod.console_flush()

If libtcod.console_init_root(SCREEN_WIDTH, SCREEN_HEIGHT, 'python/libtcod tutorial', False) initializes the console, and libtcod.console_flush() displays the changes that I have made to it, why doesn't the console stay open in a script with just these two commands after libtcod.sys_set_fps(LIMIT_FPS)?  It looks almost like you have to use while not libtcod.console_is_window_closed(): to keep the console open, but I thought that line was essentially asking the question "is the console window open?" not giving python the command "keep the window open".  So, what is the bare minimum of commands necessary to keep the console window open and what the heck is the mechanism by which they work? 

Is python looping through the commands after while not libtcod.console_is_window_closed():  LIMIT_FPS times per second, or does the console just stay drawn until it gets a command to change what it displays and is flushed? 

Yes, I could ask this on the libtcod boards, but after a brief inspection of how complex the topics there are, I think I am too embarrassed to.

4

Programming / Realism in Roguelikes

« on: November 13, 2013, 04:44:29 AM »

Since Xecutor's recent topic about "legalized experience and item farming" turned into a discussion about the role and implementation of realism in roguelikes, I figured that it might be worthwhile to create a new topic devoted to that subject. 

There are a least two parts to what I have to say.  Here is the first one, and if anyone is actually interested in what I have to say, I’ll get into the second later.

I think it is reasonable to say that you have to prioritize what realistic aspects to include in a roguelike, because complete realism, or even anything close to it, is impossible.  I think that as you add more realistic elements the game does obviously becomes more realistic, but I think that the returns also diminish with each new element.

Take the idea of attributes, for example.  When I think of increasing realism, increasing the number of attributes used to describe the PC is the first thing I think of.  The PC is arguably the most important part of the game world, so it seems reasonable to start adding realism there. 

Lets use the system of attributes in ADOM as an example.  It has 8 visible attributes (I think), one of which is dexterity.  There is no agility attribute per se.

I think it would be more realistic to have a separate attribute for dexterity and agility.  This is because fine movement, performed relatively slowly, using mostly hand muscles (lock picking, some forms of craftsmanship) probably develops independently from coarser, faster movements, performed with large numbers of muscles over the entire body (leaping, dodging, running).

But, the problem is that there really aren’t that many tasks that would use this new, more specific dexterity attribute.  There’s lock picking, pickpocketing, playing music…And that’s about all I can think of.  The game isn’t improved in any significant way by its addition.  If having just dexterity simulates reality with 99% accuracy (just to make up a number here) having dexterity and agility might increase the accuracy of that simulation to 99.9%.  I want to believe that matters, but I'm just not sure it does.

Even if you did decide to go ahead and implement a separate dexterity and agility attribute, there’s no reason to stop there.  For greater realism, you could separately assign each limb attributes, like strength of muscle contraction, speed of muscle contraction, coordination, and endurance.  Perhaps the hands could even be separate from the rest of the arms to account for manual dexterity.

So, the question is, where do you stop?  How realistic is “realistic enough?” How many attributes and skills describe the PC accurately enough to create a sense of immersion?  If it does make sense to add a bunch of additional attributes, how do could you communicate all this additional information to the player in a clear, concise way?  And, incidentally, should each attribute be equally useful?  Can having a perception score of 20 rationally be made as beneficial as having a strength score of 20?

By the way, I do think it would be cool to add the more detailed attribute systems that I was just describing, I’m just not sure there’s actually any merit in doing so.