Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[alexandertnt]

IDLE does have code completion (unlike notepad), but from my experience it is slow and not very useful.

Notepad++ is probably the best lightweight replacement.

[postal83]

Has anyone ran PDCurses under SDL?  I can't seem to get this to work?  I also don't understand where the curses output window surface would be drawn to?

[dennislp3]

How does one manage a real time roguelike?

namely how can I make an action take X amount of seconds and how would one go about handling time passing? Connect passage to FPS? Or System clock?

IE I want it to take 5 seconds to chop a tree or 5 seconds to use a skill etc

More over how about something like tree/plant growth over time?

[alexandertnt]

How does one manage a real time roguelike?

namely how can I make an action take X amount of seconds and how would one go about handling time passing? Connect passage to FPS? Or System clock?

IE I want it to take 5 seconds to chop a tree or 5 seconds to use a skill etc

More over how about something like tree/plant growth over time?

Making real-time programs is more complicated. The best way to understand real time games is that they are very very fast turn based games where each turn takes a fraction of a second.

Most game-making-facilities will provide some sort of timer or something to manage the FPS of the game. You would use this in a loop (sometimes called a "main loop"). For example, with PyGame a general main loop for a generic game could be something like

Code: [Select]

clock = pygame.time.Clock()
fps = 60

# Enter game loop
while program_is_running:
    process_user_input()
    process_logic()
    process_physics() # If applicable
    update_graphics()
    clock.tick_busy_loop(fps)

(I don't know if libtcod provides similar functionality, but even if it doesn't there is nothing stopping you from using PyGame's Clock with libtcod)

With this code, you know that each "tick", or each time process_logic() is called, 1/60'th of a second has passed (or to generalise it, (1/fps) of a second has passed). So if you wanted to take 5 seconds to cut down a tree, you could count from zero with an integer (increasing the counter by 1 each "tick"), and by the (fps * time_to_complete_in_seconds) frame, or in this case (60 * 5) = 300'th frame, 5 seconds has passed. This has the advantages of using integers over floats.

If you wanted to move something, say have it move x units-per-second, it would be the reciprocal of the fps (1/fps) multiplied by x, ((1/fps) * x), or (x/fps). So given the player's position is stored as a float  (which is quite reasonable in a tile-based game) something like

Code: [Select]

player.move_right((6/fps))

with this, the player player would advance 6 units right for each second the game was running.

When working out which specific tile it is in for whatever reason (for example rendering), just floor the position (using python's math library, "math.floor(pos)"). So if your player was at location X 15.7, and location y 7.4, you would render them at (15, 7). Likewise, (15, 7) would be considered an occupied tile, an enemy trying to walk into that tile might attack the player.

If your game slows down (for example you have a billion cubes being physics simulated), then the game will start playing in slow motion. You can avoid this by updating the "fps" variable dynamically.  But for a roguelike, it is unlikely you would have to worry about this (plus it introduces inaccuracies).

[dennislp3]

Sweet found the proper functions (I think).

Easier than I thought (soon to eat my words of course). Essentially just have to tie every actions to FPS which is easy enough (+1 or 2 lines of code per action)

Essentially each action adds a number that decreases by one per frame. No action can be taken while this counter is above zero. Or of course certain things could be tied to an increasing number which I suppose works better for chopping trees or something so you get the product at the end of the loop instead of the start.

[Soadreqm]

You'll probably want things to happen before, during and after the woodchopping process, but that shouldn't be too hard. Just tell the "chop wood" function to wait every now and then. Tell the player that he's started chopping down a tree and add some numbers to the time counter. Once he's ready to take another action, check if he's been interrupted, and wait some more. Repeat until finished.

[Infuriated]

I've always wanted to learn how to program, I've got a million ideas in my head and I've expanded on all of them (mostly eureka moments out of nowhere) and I'd like to say I could probably piece together a decent document to push me adrift with some direction.

My problem is, I dropped out of high school and even before then I was a pretty lousy kid because I grew up with migraines and by the time that was resolved I was already well past recovering from my situation. I bring this up because my math (anything high school level, basically) knowledge is extremely primitive. I also lose interest in stuff very fast, I probably have some kind of attention disorder but who knows.

This usually boils down to the same result every single time. I'll lose interest in tutorials very early due to the fact everything mostly seems to be copying the code examples and less doing - I like doing, lol. If by some miracle I get over that hurdle, they tend to throw some pretty technical stuff at me that I'm simply not equipped to handle.

I've looked at a few languages and I've heard quite a bit from people just by reading conversations on related boards/threads over the years, and I've pretty much settled on Python+Libtcod or perhaps Java (but that's kind of last resort, honestly). I know of some good tutorials, one actually got me pretty far (compared to previous attempts) in Python, enough that I could have made a crude DoS-window choose your own adventure kind of thing but eventually life came up or I couldn't understand a presented problem. (Don't really remember)

So in closing... Should I just give up? It's hard for me to muster motivation when I know my attention span is a wreck and the additional math(etc) hurdles tend to fuel the aforementioned problems even more. Anyone out there like me and got over it somehow? I need some hope or closure, lol. (be honest please, the "you can do it!" kind of thing doesn't really help by itself )

I'd also like to add, I'm far from retarded/slow, I'm just lacking an education. Programming always seemed desirable to me, the creation aspect aside, I love to fiddle and problem solve but I've yet to find a graceful transition into programming that doesn't utterly stomp on me at some point before I've learned enough to mess around on my own.

Thanks for your time, folks.

[Girlinhat]

It seems an odd idea, but I've just learned how to crack open Python and make a roguelike.  Because of this, I get the feeling "I can make a tutorial better than what I mostly learned off."  A lot of very experienced coders write tutorials with info that new users don't intrinsically know, so things get glossed over or misplaced.

[alexandertnt]

It seems an odd idea, but I've just learned how to crack open Python and make a roguelike.  Because of this, I get the feeling "I can make a tutorial better than what I mostly learned off."  A lot of very experienced coders write tutorials with info that new users don't intrinsically know, so things get glossed over or misplaced.

You should write a tutorial, or some general information on what you have discovered from following other people's tutorial. Since you have just finished/still going with them, you can probably best identify the hardest aspects of starting out and make it easier to learn/follow. Most the issues I had was with the C++ tutorials, and all their unexplained namespaces/includes/argc/v etc made looking at tutorial code the equivelant of standing at the foot of Mt. Everest, and looking directly up at the peak.

I've always wanted to learn how to program, I've got a million ideas in my head and I've expanded on all of them (mostly eureka moments out of nowhere) and I'd like to say I could probably piece together a decent document to push me adrift with some direction.

My problem is, I dropped out of high school and even before then I was a pretty lousy kid because I grew up with migraines and by the time that was resolved I was already well past recovering from my situation. I bring this up because my math (anything high school level, basically) knowledge is extremely primitive. I also lose interest in stuff very fast, I probably have some kind of attention disorder but who knows.

This usually boils down to the same result every single time. I'll lose interest in tutorials very early due to the fact everything mostly seems to be copying the code examples and less doing - I like doing, lol. If by some miracle I get over that hurdle, they tend to throw some pretty technical stuff at me that I'm simply not equipped to handle.

I've looked at a few languages and I've heard quite a bit from people just by reading conversations on related boards/threads over the years, and I've pretty much settled on Python+Libtcod or perhaps Java (but that's kind of last resort, honestly). I know of some good tutorials, one actually got me pretty far (compared to previous attempts) in Python, enough that I could have made a crude DoS-window choose your own adventure kind of thing but eventually life came up or I couldn't understand a presented problem. (Don't really remember)

So in closing... Should I just give up? It's hard for me to muster motivation when I know my attention span is a wreck and the additional math(etc) hurdles tend to fuel the aforementioned problems even more. Anyone out there like me and got over it somehow? I need some hope or closure, lol. (be honest please, the "you can do it!" kind of thing doesn't really help by itself )

I'd also like to add, I'm far from retarded/slow, I'm just lacking an education. Programming always seemed desirable to me, the creation aspect aside, I love to fiddle and problem solve but I've yet to find a graceful transition into programming that doesn't utterly stomp on me at some point before I've learned enough to mess around on my own.

Thanks for your time, folks.

Programming is generally not as math-knowledge-intensive as one would think (It does depend on the program, a simple roguelike is pretty advanced-math free, whereas something like a physics simulation is very trigonometry-heavy). Programming does, however, use a similar mind-set to maths (logical thinking).

I had similar patience issues when I began programming. What got me into it was entering a competition, that would assume zero knowledge and give you tasks to complete each week. Since it had a deadline, I suddenly needed to get the program done on-time and I couldn't just say "Oh, I will just learn it later". It was also hands-on. Instead of just "Hey, here is code that does X, now understand it and move on", it would actually require you to understand it, and test your understanding of it (while allowing you to practice).

Give yourself a time-limit to complete a tutorial. Try to make a deriative of the code.

My suggestion is, if you have all these ideas, compile them into a document of some sort. Design the aspects of the game and any other relevant information into a human-readable document. Something that if someone reads, they can see generally get what the game is you have in mind. This can be a huge motivator to begin learning to programming, and it can also make visible what you specifically have to learn/do.

Remember though, start of simple. You will not be able to code a life-simulater that you can do absolutely anything in etcetc when you start off (or even ever really, it is far to time-consuming for a knowledgable programmer to do). Make a pong clone, tweak it. Make a simple platformer of some sort etc.

It will take time and patience, unfortunetely there is no escaping this. You just really need to practice, practice, practice. Make tons of programs, doesn't matter how terrable they are. Ask questions if your stuck.

[Girlinhat]

I've actually found one of the big things, is to make functions whenever it's rational to do so.  You basically need user-defined functions for two reasons.  1: It's a unique piece of code that you'd like to keep separate from the main chunk so that you can access it easier.  2: It's frequently-used and you'll be saving number of lines by making it into a quick-use function.

For instance, making a map is generally nice to have in its own function.  It should only be called once, really, but it's neat and tidy to have it put away somewhere clean.  Meanwhile, I've put direction keys into their own function.  You can be moving, gathering, attacking, looking, etc.  Instead of "if moving and key_up" and "if gathering and key_up" I've just moved all the key handling into its own function.  So now it's "if moving: get_key_direction()" and I take a LOT of if-else chains and toss them into one little function.  Cuts out dozens of lines of code.

[Mephisto]

I've finally gotten around to hacking on my roguelike project. I got kind of fed up with how libtcod seemingly changed how it functioned between 1.4.x and 1.5.x, rendering all of the tutorials useless. Therefore, in what Larry Wall might describe as laziness, impatience, and hubris at the same time, I'm starting from the ground up using just pygame. So far, it's a dream.

Right now, I'm sort of using a variation on DF's method of faux-ASCII in that I'm using one of libtcod's public domain tilesets. Each entity's tile image may be defined separately in whatever "raws"-type system I end up using. My system also supports any number of 2048-tile images, meaning you'll never run into DF's issue with tilesets where, for instance, the letter 'o' is replaced with whatever you decide a well should look like. In theory, this should allow me to eventually implement some sort of facing functionality ala UnReal World.

The end product may not end up as robust as libtcod, but it will do exactly what I need it to.

I'm currently working on some little tech demos, but there's nothing really available yet besides tileset creation. What does work works wonderfully at the moment.

[Andir]

I've actually found one of the big things, is to make functions whenever it's rational to do so.  You basically need user-defined functions for two reasons.  1: It's a unique piece of code that you'd like to keep separate from the main chunk so that you can access it easier.  2: It's frequently-used and you'll be saving number of lines by making it into a quick-use function.

It's also great to write functions when you have a block of code that needs to be in a particular order and/or all performs a basic task.  It helps segregate your thought processes into "This block of code is going to do X" and then you name your function that.  It makes code much easier to write and read later.  If you can get away with it, program from the top down by writing out what methods you'd like to call then fill them in: (pythonish)

Code: [Select]

map = createMap(seed)
player = createPlayer()
player.pickStart(map.getCities(race = player.race))

Or something like that.  The methods won't exist yet, but you get a general flow and it should dictate what's going on without need for excessive comments.  After you get that much, go into 'def createMap' and start the same process over again:

Code: [Select]

map = []
startRoom = spawnRoom(sizeMultiplier = 4)
halls = startRoom.spawnHalls()
for hall in halls:
    if random.seed(10) < 3:
        nextRoom = hall.spawnRoom()
Of course, most of the above code is just rambling (and why would you pick a starting city if you are generating a dungeon in the createmap?  whatever), but it gets you thinking about what you want to do and how you want to go about it.

[jhxmt]

Out of interest, how would people (conceptually) go about dealing with multi-turn actions in a turn-based roguelike?

I've been batting this around in my head for a while, and I'm thinking that there are four types of actions that a player (or NPC) can take:

• Instant/1 turn actions: things like attacking, moving, throwing something, etc.  These can be resolved instantly, on the turn that the action is initiated.
• Multi-turn actions that can be interrupted and then continued later: like building a constructed wall in DF - if a wall takes seven turns to build, you can start building it, continue for a couple of turns, get distracted and wander off, then return later and finish it in four turns, rather than having to start from scratch.
• Multi-turn actions that can be interrupted, but need to be started from scratch: like casting spells in most D&D-like worlds.  If a spell takes six turns to cast, you get four turns into it but then get attacked and distracted, you need another six turns to cast it - you can't pick up where you left off.
• Multi-turn actions that can't be interrupted: I couldn't really think of a good example for this, but I guess if you were treating things like 'be comatose' as a player action then marauding bad guys could attack them all they liked, the action would carry on for however many turns the player is due to be comatose for.

The first one is easy to deal with (and is the norm in, for example, the Complete Roguelike Tutorial for Python and Libcotd, which is what I'm working through at the moment too). 

The second, third and fourth ones are trickier - particularly so if you want NPCs, as well as just the player, to be able to to multiple-turn things.  I'm guessing you'd want every 'actor' (player/npc) to have an action queue and/or timer, so that when the actor takes an action it a) gets the action placed in its queue if there's nothing there already, and b) gets the required number of turns added to that action's timer.  Then, every time that actor gets a turn, if it's not interrupted then decrease the action timer for the action at the head of the queue by one (and complete it once it hits zero).  If it is interrupted, then what occurs will depend on what type of action it is.

Any of that sound vaguely sensible (or even coherent)?  I'm relatively new to game programming in general (and roguelikes in specific), so the above may be just so much hot air. 

Edit: the reason I'm talking about an action 'queue' is because I can see instances where being able to queue up more than one action would be desirable - and this could help out with the interruptable-but-can-be-continued actions.  "Build a wall" could actually be a task made up of multiple actions - "build the first 25% of a wall", "build the second 25% of a wall", etc, with each action automatically queueing up its successor until completion.  Maybe.  Or not.  Hell, I'm still trying to get my monsters to die properly! 

[Andir]

You could have work units.  Some action would take 1 work unit which would be added to a work queue.  You could do several work units in a turn (say 5).  Walking a square could expend 1 work unit that can not be used for other tasks.  If you wanted to have longer jobs you'd give them 20 work units and the task would not be complete until all work units were "removed" from the entity.

So the way I see it:
You decide to build a wall.  It will take 20 work units to finish.  A builder is 5 squares away, he burns one turn getting to the wall (5 work units to walk 5 squares) and the next 4 turns building it.  If he walks away from the wall it remains in an unfinished state until someone else returns to complete it.

[Girlinhat]

I'd work off Cataclysm's style, which I understand many emulate.  The game has two units of time, "turns" and "movement points".  Your speed determines your MP.  You get MP per turn.  For instance a human gets a standard 100 speed, and a shambler zombie gets 70.  Also for instance, walking over grass takes 100 points.  So the game starts, the first turn starts, and the human gets 100 points and the zombie gets 70 points.  Since both have positive numbers, they both get to move, player first because why not.  Player walks over grass, spends 100 points, and has 0, so the player's turn is over.  Zombie moves, consumes 100 points, and is left with -30.  All actors have 0 or less, so the next turn happens.  Player gets +100, zombie gets +70, for totals of 100 and 40.  They both move, so it's 0 and -60.  Another turn, so 100 and 10.  The both move, so 0 and -90.  Now, the turn happens, and the human gets 100 and the zombie gets -20.  The player has positive movement points, so the player moves.  The zombie owes points, so the zombie skips his turn and doesn't move.  The player moves and gets 0, the zombie doesn't move, and stays at -20.  The turn happens, and the human gets 100 and the zombie goes to 50.

A little long-winded of an example, but this is a solid way to handle long-term actions.  Like attacking with fists could take 50 turns, making it quicker than walking, while swinging a sledgehammer could take 250 turns, inuring a heavy delay.  Speed can also be affected by things, like in Cataclysm if you're hurt, your speed goes from 100 to 90, so instead of getting +100 per turn, you only get +90, so you've been slowed down and will skip 1 turn out of 10.  Not to mention this also meshes well with different tile types, like if stone floor is smooth and quick, so it's 80 cost, but a fence is actively in the way so it's 200.