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.

Messages - tuturto

Pages: 1 2 [3] 4 5 ... 18
Programming / Re: beyond python and curses
« on: February 23, 2016, 07:23:37 AM »
Might be a bit of overkill, but I have had fund with PyQt ( There's also PySide (, with slightly different API (very close to PyQt still though) and licensing. It's portable, fast and generally pretty nice.

Programming / Re: [Python] Looking For Some Good Examples
« on: February 19, 2016, 09:44:53 AM »
Probably I'm not the best person for judging the code - as I said in my first post, I started new project recently just for learning 'good coding' techniques. I'm not the python guru - these roguelikes which was generally mentioned earlier usually have code that looked very bad at / from first glance. You know, Writhing Mass of Code :) But if you want to I could give a glace at pyherc code, no problem.

It would be great. Especially since you aren't a Python guru. My hunch is that it's easier to write code that is readable by very experienced programmers than by not very experienced programmers. And different set of eyes is always a different set of opinions and ideas, which is what I'm really after. If you're willing, there's also some ramblings at: where I tried to maintain more or less up to date documentation about overall structure of the code and various parts.

Not claiming to be the best person for the job nor claiming guru status, when it comes to Python I consider myself a journeyman/retired hobbyist.  However, I dropped by your repo and poked around. 

I liked what I saw.  Good commenting, seems to have good test coverage, the unit tests looked useful, the code base is organized, and it uses good solid Pythonic practices as far as I can see.  If I spent enough time I could probably nitpick something :)  There was nothing that jumped out at me as being "NO! WRONG!".  All in all, looks better than some of my own work.

Thanks, it's always nice to hear that your codebase isn't an eldritch horror :) There's always something that can be done better of course, but it's good to keep those things as small as possible.

PS: couple of suggestions to consider; you might want to include the target version of Python in the file header info, and along the same lines, you might want to note somewhere a new Python programmer might see that the .hy files are for the lisp extension.  Newcomers probably aren't aware of the various add on file extensions that they might run across, pyx files, hy files, etc.

Right, good call. The project probably isn't the easiest to start hacking because of all different file types and such. I'll write an extra paragraph in readme for things like that.

Programming / Re: [Python] Looking For Some Good Examples
« on: February 18, 2016, 05:26:36 AM »
First - roguelikes rarely has a good code. I checked large amount of code of open source python roguelikes and I didn's see any with really good code. Even my own ;)

If you aren't super-busy, would you want to give a glance at: (or at least at the parts written in Python, Lisp side might not be relevant in this topic) and put in your two pennies worth about the code? It's my first Python program of any significant size and getting some feedback would be super-cool and might be relevant to Hashiba too. Concrete examples about good or bad code is often better than just an abstract concept. I understand if you don't want to do this or don't have time of course.

Programming / Re: [Python] Looking For Some Good Examples
« on: February 17, 2016, 04:41:05 PM »
Wanting to learn from good code is a good idea. But you can also read any code and spot both good and bad practices and learn from both. Most likely as your skills develop over the time, your views on what is good or bad code will change too. So, I would just read code and try to learn from it and most importantly, learn from what you write, both good and bad. Also, good or bad code is somewhat subjective matter. Ask ten programmers and you get a dozen opinions. Someone might argue that only the most generic and flexible codebase is good, while other argues that everything can be hardcoded if it just solves the problem at hand. I guess it depends on what you want to achieve: write a game, learn to program, learn more about designing and architecture, etc (I chose not to write an engine, but a programming language for writing a roguelike, so it's extra slow progress).

The only thing you really need for writing a game is stubborness anyway. Everything else is secondary and can be substituted with some more stubborness and will to stick with it. And remember to have fun too while you write your game.

Off-topic (Locked) / Re: Songs from your country
« on: January 04, 2016, 02:30:30 PM »
Speaking of Finnish music, I think Finlandia by Sibelius is pretty cool composition:

Do you want to use the same seed everytime game is played and have the world to be the same? Or do you want to select a random seed, based on something keyboard/mouse noise, time, etc. and use that? Because if latter, then it usually doesn't matter if the player actions change rng state. From their point of view, the game would still have unique world, that was generated just for them to play and they wouldn't be able to affect the creation in a feasible way.

If you want to use the same seed for every game and avoid player actions altering the world state, you could still generate levels one by one and have them come out the same. Just store a random seed for each stairs and reset rng with that seed when generating next level. Because random seed comes from rng originally, which had that specific seed you chose to use, it should always be the same. No matter what player does on the level will affect that seed and change the next level, even if there are multiple stairs that can be taken in a single level. Basically the same thing the original Elite does, but in a simpler scale.

Design / Re: map with complex numbers
« on: December 01, 2015, 07:08:09 PM »
Lots and lots of good stuff in replies. It's true that 4 dimensions would probably be too much for players to handle, especially if they could freely move to all directions. From the computer point of view though, it shouldn't be more complex than 2 or 3 dimensions. Path finding works in the same way for example, just with one added dimension. Sure, it would take more memory to represent the world, but I suspect the difference wouldn't be too much for modern computers to handle. I'm using sparse representation of the map (dictionary, with coordinates as key), so only the locations that contain anything or can be visited take memory.

I like the idea of world slowly morphing to something different the further you travel in the imaginary domain. Creatures would slowly become something different, as would the loot. That could be pretty neat risk/reward mechanism for players. And I totally love the idea how traveling would work differently. Whole geometry could be different, allowing quick travel and shortcuts for characters who know what they're doing. Others would get lost and in harm's way of course.

Design / Re: map with complex numbers
« on: November 25, 2015, 07:59:24 AM »
Fair point with the altitude. Altitude is something that is visible all the time though, and I was thinking more of a hidden realm, with strange items and creatures. 4 dimensions would be a bit much to move in, true. It would probably be quite disorienting and cumbersome. Moving on a 2d-plane is easy with cursor keys or mouse, moving in 4-dimensional space not so much I guess.) But it sure would be grand to come across a deep chasm and actually see it continue deep down in the bowels of earth.

(Big reason for not having real altitude is that I'm terrible with graphics and thus using premade tiles that are top down. Having real altitude would be pain with those, forcing player to cycle from z-level to another. Isometric or even 3d-graphics would help with this, but I think it's beyond me at the time being.)

Design / map with complex numbers
« on: November 24, 2015, 11:02:08 AM »
I was playing with ideas and started thinking of having a world where coordinates wouldn't be integers "(x, y)", but complex numbers "(x+ai, y+bi)" . Technically this should be pretty easy thing to do, but design-wise I'm in a loss. What would that kind of world even look like and how would moving and such handled? Easiest probably would be if actions would mostly be on the real part and in some special circumstances imaginary component would come into play. There could be creatures that can move in imaginary part and sometimes come through to real world. Or there could be warp rifts here and there that would allow moving in imaginary direction. With correct tools or potions, player could have access to imaginary world, or could at least sense what is happening near him in that direction. Or maybe that imaginary space could represent alternate worlds, that would be close to real one, but different in some aspect. The further you are from the real world, the more different the world would be.

But like I said, this is currently just an idea and a very vague one even. Feel free to throw me even the craziest ideas regarding to this, maybe it will push me over to actually take this in use.

Design / Re: Sorting order of inventory
« on: November 09, 2015, 09:51:41 PM »
What about adding items at the end as the player picks them up (sort them by the pick up time essentially) and letting player to move them around in inventory afterwards?

Programming / Re: GUI library experiences
« on: June 09, 2015, 06:53:21 AM »
Qt isn't bad choice either in my experience. Very easy to get started and create applications with default controls. And when they aren't enough, you can always write your own (although this is something I haven't had to do).

Programming / Re: LambdaHack and new content
« on: May 31, 2015, 09:24:32 PM »
Played around with the a bit and they seem useful. Most of the time I'm perfectly happy to let the squad members freely pick up all the times and mostly decide what they want to do. But as you said, things like setting ambushes require more fine control and there these tactics help quite a bit.

Programming / Re: LambdaHack and new content
« on: May 28, 2015, 09:27:46 PM »
I don't mind if henchmen are doing these tasks by themselves. In case they find something that I would rather have on leader, I can always later manually move it.

Sure, but when you switch the leader to another actor, the previous one can spontaneously decide to get rid of that item and/or equip other items. ;)
Another solution would be to let player mark items with an inscription {henchmen off} so that the henchmen AI knows it may not touch them. Post-5.0.

True, that has actually even happened while I have been playing. Currently I don't find it too annoying. I try to avoid micromanagement and just worry about one character's equipment at a time.

This one I haven't done yet, but should. Does weight of a thrown object affect to damage or distance any way? Or would it be better if I would assing maluses to very heavy weapons?

The weight only affects the distance of throwing. Additionally LH melee weapons have attributes like 'toVelocity 40' in their ifeature field that limit the throwing velocity further. But, e.g., a dagger realistically can be thrown quite far. OTOH, not being balanced for throwing, it can hit with the wrong side, so additionally I add 'AddHurtRanged (-60)', which makes it as weak as a dart, but travelling much slower and closer. That balanced well with the durability, I guess, so the darts are not made obsolete once you find a few daggers.

Good to know, thanks.

Programming / Re: LambdaHack and new content
« on: May 28, 2015, 04:16:16 AM »
Thank you again for the report. It's fixed now on branch master. I couldn't reproduce it, because I never use the 'e' command available when the game shows me the description of an item (the noun-verb command). Instead I use the standalone 'e' command and only then pick the item to equip, changing display modes as needed (this is the verb-noun command).

Great, I'll upgrade to the latest version soon I would think.

EDIT: I upgraded to latest version this morning and had the computer to play couple campaign games. Looking good to me. I'll play more in the evening when I'm home.

BTW, you probably noticed that your henchmen (non-leaders) sometimes move items from equipment to pack, etc. Would you perhaps prefer to reserve such item management for yourself and only allow them to autonomously pick up items? Or perhaps you'd prefer to only pick up items with your leader? If the former, I'd need to separate the picking up skill from the current item management skill, so this is post-0.5. The latter can already be accomplished by changing fskillsOther of playerHero.

I don't mind if henchmen are doing these tasks by themselves. In case they find something that I would rather have on leader, I can always later manually move it.

Another thing: I just remembered that the ranged damage bonus (AddHurtRange) aspect only applies to the item in question, not to other items. The aspect comes into play only when the item is used as a missile. The logic is that when the missile hits, bonuses are calculated as if the missile actor hit the target actor in melee. The only tweak is that, instead of the melee damage bonus, the ranged damage bonus is taken into account. In the future, when missiles comprise of many parts, the bonuses of all the parts will naturally be taken into account, since all the parts are carried by the missile actor.

That's different than for AddHurtMelee and AddArmor*, which are summed over all items of the original actor, as can be seen in the ! screen. That's intentional, only the bonuses on the ammo and perhaps on the launcher should affect the ranged damage, which otherwise easily gets overpowered and also induces equipment micromanagement when switching from ranged to melee combat and back again. (That's also how, e.g., Angband does it.) I wonder how to prevent confusion both in the UI, the player guide and in the content code naming. Perhaps when launchers are added to the game this will settle down and become clearer, but I'm open to suggestions already.

So, items that add AddHurtRange are useless in equipment, they can as well be kept in the pack and thrown when appropriate.

Right, good to know. I need to change some of my items (close combat manual comes to mind first) to reflect this. This distinction makes sense now that I know it.

This is also why I have huge AddHurtRange maluses on the melee weapons in LH --- this prevents their use as super-ammo (they have large damage dice and they are durable, unlike normal ammo). And, OTOH, this doesn't affect other items, so keeping them in equipment doesn't make other ammo weaker.

This one I haven't done yet, but should. Does weight of a thrown object affect to damage or distance any way? Or would it be better if I would assing maluses to very heavy weapons?

Programming / Re: LambdaHack and new content
« on: May 27, 2015, 05:48:12 PM »
I didn't have save left for the time the problem first occurred and when I tried to reproduce it, I couldn't get it to manifest. Kind of an odd situation there, but I'll keep my eyes open and see if I can get it to occur again.

Pages: 1 2 [3] 4 5 ... 18