Author Topic: LIBTCODPY (Doryen Library) keyboard input question  (Read 9536 times)

rabbit

  • Newcomer
  • Posts: 4
  • Karma: +0/-0
    • View Profile
LIBTCODPY (Doryen Library) keyboard input question
« on: October 22, 2014, 08:07:57 PM »
Hi there,

First post here - hi! I did search a few terms and didn't come up with anything that might answer what I was looking for, so here we go :

Over the last month or two I've been trying to get into roguelike development ---- have some experience in programming but not in a long while so I'm basically a beginner again.
I'm using python and following the roguebasin tutorial. My question is this --- I'm about a half way through the tutorial, and have been making a turn based roguelike with it. Up until I think lesson 7, I was using code like the below to handle keyboard input whilst also waiting for turns (ie. moving once per turn, not constantly):

Code: [Select]
def handle_keys():
global fov_recompute
key = tcod.console_wait_for_keypress(True)

if tcod.console_is_key_pressed(tcod.KEY_KP8):
player.move(0, -1)
elif tcod.console_is_key_pressed(tcod.KEY_KP2):
player.move(0, 1)
elif tcod.console_is_key_pressed(tcod.KEY_KP4):
player.move(-1, 0)
elif tcod.console_is_key_pressed(tcod.KEY_KP6):
player.move(1, 0)

So here -- what's the ''key = tcod.console_wait_for_keypress(True)'' thing? I mean - I know what it's doing, I know it's assigning the variable ''key'' the value of ''tcod.console_wait_for_keypress(True)'', right? So that seems to make it so that it knows to wait for an individual keypress to move, rather than allowing one held down to keep the character moving constantly, right? EXCEPT - the variable 'key' isn't referenced anywhere else in the code. So what's it doing? I don't get what it's doing? And then tcod.console_is_key_pressed(tcod.KEY_KP8) & etc - none of them reference it, they're just keypress checks. So how are those two parts linked? I don't understand what they are doing there, what the interplay between the two is. It seems like the 'key = tcod....' line is setting it up to be done in one way and then it's done in a different way entirely?

Thanks for your time.

f

LindaJeanne

  • Newcomer
  • Posts: 22
  • Karma: +0/-0
    • View Profile
Re: LIBTCODPY (Doryen Library) keyboard input question
« Reply #1 on: October 22, 2014, 09:38:41 PM »
Hi!

I'm not familiar with the inner workings of this library, but I think I can partially answer your question :).

this is using object oriented programming, which can be counterintutive if you're not familar with it -- as you've discovered!

'tcod' is an "object". With object-oriented programming, you can create 'objects' which maintain a state (that is, store the value of several variables internally), and also have their own methods which act on them.

Thus, 'console_wait_for_keypress' and 'console_is_key_pressed' are functions belonging to, and acting on, the tcod object.

What I suspect is happening here is that the 'console_wait_for_keypress' is waiting for a keypress and then storing it's value internally within the tcod object. It also passes the key as a return value, but this is just 'extra'.

The 'console_is_key_pressed' functions are then probably checking against this internal value. So, the intial function was neccesary (to wait for the keypress, and to store the value internally), even though the 'key' variable isn't used.

'KEY_KP8', and such, are constants stored within the tcod object, those fucntions are comparing the internally stored key-value against the various constant values.

Hope this helped a little bit? It's hardly a comprehensive introduction to OOP, but hopefully it removes at least a bit of the WTF.

rabbit

  • Newcomer
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Re: LIBTCODPY (Doryen Library) keyboard input question
« Reply #2 on: October 23, 2014, 05:42:31 PM »
Hi there, thanks for your reply, really appreciate it!

Yep - I did understand that about the KEY_KP8 etc being constants, and about tcod being an object and everything after a dot being a function relating to an object. I just didn't quite get - and still don't (would you maybe be able to detail this slightly more for me?) quite understand how the key = tcod.console_wait_for_keypress(True) bit works.

My problem is - I understand that they've set the variable key and then assigned it that value. But I just don't quite understand how if it's not then being called at any point, if it's not being referenced and brought into being, how it has any effect. It seems like it's being set up but then never enacted.

That said, it's just occurred to me (thanks to your message putting into  writing some concepts which I'd mostly grasped but didn't quite have a nice mental image for) that maybe it's just the fact that within tcod itself this stuff is already defined. And so all that's needed is to reference it, essentialy setting the dominoes falling within the tcod module itself, and that's how it works. That's a guess, anyway.

I have looked a few times through the code of the tcod module but... well, it's definitely a long way above my understanding so far.

Thanks again for your help.

Aukustus

  • Rogueliker
  • ***
  • Posts: 440
  • Karma: +0/-0
    • View Profile
    • The Temple of Torment
Re: LIBTCODPY (Doryen Library) keyboard input question
« Reply #3 on: October 23, 2014, 06:22:48 PM »
I'm not sure if it's related but I use stuff like

Code: [Select]
if key.vk == libtcod.KEY_ENTER or key.vk == libtcod.KEY_KPENTER:
So I kind of use the key variable. I built my roguelike too on top of the same tutorial.

rabbit

  • Newcomer
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Re: LIBTCODPY (Doryen Library) keyboard input question
« Reply #4 on: October 23, 2014, 06:45:42 PM »
Yep, this code is actually from a slightly earlier lesson than the one I'm currently up to. I've been keeping backups of my progress as I go and going back and rewriting them after a while as a way of hammering it in and trying to see how my knowledge and understanding is progressing. At the point I've gotten to now in the tutorial (have just finished part 8), I'm actually using ''if key.vk == KEY_KP8'' and the like to control movement - the entire way of handling keyboard input and movement has changed.
That was actually originally what I came on here to ask about, but I decided that I understand that side of things a lot more, almost completely, whereas this I can sort of grasp but don't feel confident enough with it that I'd be able to reproduce it myself from scratch... and that's the point of all this, after all... I want to have it all understood so that I'd know how to do this on my own, without needing to take it from a tutorial or something similar online.

LindaJeanne

  • Newcomer
  • Posts: 22
  • Karma: +0/-0
    • View Profile
Re: LIBTCODPY (Doryen Library) keyboard input question
« Reply #5 on: October 24, 2014, 04:53:10 PM »
That said, it's just occurred to me (thanks to your message putting into  writing some concepts which I'd mostly grasped but didn't quite have a nice mental image for) that maybe it's just the fact that within tcod itself this stuff is already defined. And so all that's needed is to reference it, essentialy setting the dominoes falling within the tcod module itself, and that's how it works. That's a guess, anyway.

Yup, based on the code shown,

tcod.console_wait_for_keypress(True)

would have worked just as well as

key = tcod.console_wait_for_keypress(True),

but it can be kind of a habit to grab the return result just in case you need it later.

rabbit

  • Newcomer
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Re: LIBTCODPY (Doryen Library) keyboard input question
« Reply #6 on: October 28, 2014, 07:36:11 PM »
Righto, thanks!

I've just this evening finished part 13 of the tutorial. Reading it and going through it, I feel like I've understood 90% of what I've done comfortably. But now that I'm finished I'm .... I'm like a deer caught in the headlights. Am not sure how I want to proceed *at all*. My first thought was that I wanted to add tooltips but ... well, that's totally beyond me. So I'll park that for the time being and am thinking maybe of just tidying up the code and introducing a deeper skill system. But then before I get to that I feel like ... well, I don't know. This, I think, will be another question for another thread.

Thanks, all.