Messages

61

Programming / Re: BearLibTerminal: a pseudo-terminal window library for roguelike

« on: July 06, 2016, 11:57:36 AM »

Code: [Select]

pip install bearlibterminalAnother step to enlightenment. Works (or should work) on Windows and Linux, 32 and 64 bit. OS X package is not built yet, my virtual machine with OS X is such a pain.

Use it like this:

Code: [Select]

from bearlibterminal import terminal

The __ members are useful meta variables that have their place in the python langauge

I was talking about single-underscored members of a module. Like terminal._library which should be considered internal:

62

Programming / Re: Help with opening libtcode

« on: June 30, 2016, 01:25:55 AM »

The question is, well, vague so it is hard to guess anything.

Try to run the program from the console window (cmd.exe), this usually produces some informative output in case of error. Run cmd.exe, navigate to the directory your program is in and run it from there. Also if the app is a python script then you'll have to manually run 'python smth.py' command, console won't start the interpreter by itself.

63

Programming / Re: BearLibTerminal: a pseudo-terminal window library for roguelike

« on: June 25, 2016, 10:15:35 PM »

This happens because libBearLibTerminal.so is not in the place the wrapper looks in. With default PyBearLibTerminal.py wrapper, the library binary may be either in default system path, or in the same directory as wrapper. The easiest way to fix that is to copy the .so to the source directory. If you want to have it somewhere else (e. g. /src and /bin separate) then you may add a new path directly to the wrapper (_possible_library_names variable).

Indeed, pip package should fix that as the binary (installed with the package) will have a well defined location. I'm working on that.

Why does PyCharm show members starting from _ in its intellisense? Aren't they considered hidden by convention?

64

Design / Re: Corridors considered harmful

« on: June 22, 2016, 04:18:09 PM »

It is interesting that you bring up the concept of a dungeon as a fixed kind of thing.

More like 'established' kind of thing. Dungeon is rooms plus passages between them. This is close to what dungeons would be IRL (or believably close to that). Without corridors you end up with paper-thin walls like in reaver's example: looks nice but I'll argue it is not a dungeon. Basement of a castle or level of a magically constructed tower maybe?

This becomes a question of terminology. In the end, there are a whole lot of different map/level designs, with and without corridors. There is nothing wrong with using ones without. But corridors are an element of established design (usually going by the name 'dungeon'). It's just some designs have features you'll have to be careful with. Long and boring paths in a maze. Pillars in an abandoned temple you can dance around. Annoying traps in a tomb. I'm sure there are a lot of things one may fail to balance besides corridors.

As an additional point against corridors, they are a poor use of space.

I'll agree on the point that poorly made corridors (long and featureless) provide a questionable element of design. A lone path going across half of the map is just a failure. It might be a good enough reason to throw that generator away.

65

Programming / Re: Generic algorithms for complex data?

« on: June 22, 2016, 10:52:21 AM »

What if you want to use other struct than Cell?

Then, well...
template<typename T> void Calc(T* array, bool T::*field);
Though precalculating sets of coordinates is okay if you can wrap the code logic around that.

66

Programming / Re: Generic algorithms for complex data?

« on: June 22, 2016, 12:28:14 AM »

You can instruct the routine which member to use. Even without templates.

struct Cell {
    bool light;
    bool fov;
    ...
};

void Calc(Cell* array, bool Cell::*field) {
    ...
    Cell& p = array[j];
    (p.*field) = true;
    ...
}

Calc(cells, &Cell::light);
Calc(cells, &Cell::fov);

67

Design / Re: Corridors considered harmful

« on: June 22, 2016, 12:09:55 AM »

I'm in the 'better AI' camp.

Corridors are essential in the generic dungeon theme. Dungeons are literally rooms and corridors in various proportions. If you remove the corridors, it is not dungeon anymore but something else (ruins, garden, town, etc.). Obviously there is nothing wrong with it, you can always have a game without dungeons. But when you do have dungeons, corridors are not at fault, no more than rooms.

Are corridors abused? Do they give the player too big of advantage? Probably you are doing it wrong. Try to imagine yourself in a similar situation. Would you really flee to the fairly narrow passage in case of danger? No, that would be one of the most dangerous places instead, badly illuminated space without freedom of movement. In the best case scenario your foe will walk away and you will waste time and supplies. If they will circle around and surround, you're screwed. If they barricade the exits and throw/breathe something in, you're screwed. If they lay some trap-like mech at the exit, then you're now trapped in and, well, screwed. One of them may go and bring a huge spear you can't do much about. Call the archer or even the caster. From the time you went into the corridor you've given up the initiative. Nope, an open, well-lit place with obstacles is the best from a tactical perspective.

If something is abused, it is because it is not balanced. Add a reliable gun to the primarily sword-fighting game and everyone will use the gun. Same with corridors, players expected to abuse them if there are no disadvantages. You just need to either give dungeons up or fix the source of the problem, depending on your priorities.

68

Off-topic (Locked) / Re: I'm moving to linux.

« on: June 17, 2016, 11:49:59 AM »

it seems that you don't get the scale of an OS. <..> It's developed by thousands of engineers, it has millions of source code lines. In 15 minutes you may discover all changes in Notepad, assuming that you use that program often enough.

I think you are getting to this from the wrong end. Or consciously making it absurd. The code base is complex indeed but you are not the kernel developer, are you? What changes from version X-1 to version X from the user's perspective? Start button placement? A second spent to idly wonder why. Network center dialog design? A minute to familiarize with new location of IP address. Search dialog looks slightly different? Doesn't really matter, you're there for search results only.

What I'm getting about is that in the usual workflow you generally interact with just a tiny subset of the OS. This subset varies somewhat from user to user but it is rare to someone actively use even quarter of dialogs, menus and utilities of the OS. For the infrequent tasks (expand disk volume, flush dns cache, disable system component, etc.) you either figure it out or google the method because it is just not worth to remember. Does it really matter how much clicks you have to do to restart printing service or which menus to traverse? Under one minute you find the way, restart the damn service and successfully forget about that. Because it is not the actual work you're doing. The 'work' is Photoshop, Eclipse, Starcraft II, Facebook, etc. Everything not related to it just not worth the time. Will I become more productive by remembering every single control on every single dialog in the OS?

That's what I've meant under 'around 15 minutes in total'. 5 minutes to find the icon on the new desktop and about 10 more in the next few months while looking for this or that a few times.

69

Off-topic (Locked) / Re: I'm moving to linux.

« on: June 16, 2016, 05:26:13 PM »

I certainly never had that "some essential application is not built for your release anymore". It really doesn't happen if you install software from the distro's official repository.

It depends =/. I may be a bit biased here but with my work primarily related to multimedia development, packages like cmake, mercurial, gcc, vlc, ffmpeg, gstreamer, etc. stop being updated in repository fairly fast. 'Stable' releases are a bit too stable and regular 'unstable' releases are prone to break things. All I've wanted to say is that in this department Linux is worse that Windows which mostly touches the system UI.

MS is forcing us to move ot their newest OS and we lose a lot of time just on learning where the f***g buttons and menus have gone to.

I may be rude here, but this is just stupid. No, seriously, just how much do you need to re-learn with each Windows release? A couple of buttons and dialogs, around 15 minutes in total? Every mobile app or web site shuffling its UI and workflow almost constantly and everyone adapt like nothing. You do not need to study buttons and menus, you just use it as a tool it is.

IE is a different thing. Microsoft has always been setting their own rules rather than following open standards.

The problem with IEs was that developers (not Microsoft, other developers) were forced to support more versions and provide their products adapted for the older ones. This is counterproductive, with either the cost of the product going up or the product being made with correspondingly outdated technology. This is more or less the same with OSes: either more effort to support everything or forsaking some user share.

70

Off-topic (Locked) / Re: I'm moving to linux.

« on: June 15, 2016, 09:49:19 PM »

Why C pointers can't be overwritten the same way?

My guess is
1. The pointer to a vtable is placed fairly predictably and near every other object.
2. vtable itself consists of pointers to functions so you are guaranteed to actually run the code if you manage to overwrite it.
Then again, objects contain only the pointer to a table, not the table itself. It should be hard to modify the table with this additional indirection.

Today Microsoft needs to force us to update. That's not a good sign.

Methods aside, I think it is fairly understandable where Microsoft is coming from. People are conservative and lazy and would stay on outdated OSes for who knows how long, which would force commercial software vendors and in turn Microsoft to continue support those platforms. Which is frankly a waste of resources. Web developers had it with their IE zoo not so long ago, so no thanks =).

I hate updates. Somehow they always mean replacing something that works with something that doesn't.

I've used Linux for a long time (mostly for work) and from my experience the sheer amount of things that simply change and stop or begin to work each noticeable release just doesn't compare to the mild annoyance of Windows >_<. Choosing and 'freezing' some stable Linux release only works for servers. On desktop everything go out of date pretty quickly and sooner or later you are forced to update because new versions of some essential application is not built for your release anymore. Then you can try to continue to maintain some things by hand but this is a huge step down in user experience.

71

Design / Re: Info line idea

« on: June 12, 2016, 02:31:03 PM »

We need games that take everything that was good in roguelikes and go beyond it.

I wholly agree with this.

Is there even possibility to make a list of things that "was good in roguelikes" to go beyond that? "Deeper plot", "better mechanics" and all other "innovative ideas" is just blah blah. Actually making the game will come to making very specific choices where no one will be able to "take everything that good" because there is no universal "good" (well, except the utterly basic things like no bugs or readable font which are not worth mentioning). Trial and error and some measure of common sense seems to be the only way.

72

Design / Re: Info line idea

« on: June 09, 2016, 05:21:52 PM »

It's like the Russell's teapot. Here is an imaginary game no one can see because reasons, now try to prove it doesn't surpass the ADOM =)

73

Programming / Re: Libtcod can go jump in a lake

« on: June 06, 2016, 12:26:15 PM »

doulos05, if console window (fonts, sprites, etc.) is all you need from libtcod, then you may find BearLibTerminal useful. It does not have a proper pip package yet, but it is just two files (.so and .py) which should be fairly easy to set up. And well, as the library's author, I am somewhat interested in how it would work on chromebook.

mushroom patch, isn't libtcod python package just a wrapper using the .so? Default (bundled with the source) setup.py indeed tries to compile the library but it should be way easier to just compile the library in a regular way and then copy the python files =_=.

74

Design / Re: Info line idea

« on: June 06, 2016, 12:07:40 PM »

How do english-speakers call trolls which are so well-fed (or lazy) they stop being subtle? In russian they are called 'fat' trolls. Some are so fat they do not fit into the thread anymore and practically ooze out of your screen. This talk about professionals and long-term development is so fat it leaves smears on the screen each time it comes up x_x.

Actually, I'm genuinely curious about the term. The russian one is more or less language-specific with 'толстый' ('fat') being the simple antonym to 'тонкий' ('thin') which is 'subtle' in russian. I've googled a bit but couldn't find any direct analog.

75

Programming / Re: BearLibTerminal: a pseudo-terminal window library for roguelike

« on: April 22, 2016, 09:37:00 PM »

An update. Say, 0.14 (these numbers were mostly arbitrary right from the start).

1. Alt key issue should have been resolved. I've added the TK_ALT keycode with corresponding input event and state always available. By default the library will intercept some key combinations, but this can be turned off with 'input.alt-functions' option.

2. Resource loading has been cleaned up a bit. Now anything can be loaded from a memory buffer by specifying <address>:<size> pair instead of a filename, like this:

Code: [Select]

terminal_setf("font: %p:%d, size=8x16, codepage=437", buffer, size);
terminal_setf("0xE000: %p:%d, raw-size=%dx%d", pixels, W*H*4, W, H);Because consistency. Also why decode embedded images to pixels when library can do that already.
Note that 'raw-size' is a required option for raw bitmaps now, since library need to know that is is not a file somehow. More or less documented.

3. Extra fonts management looks decent at last. Extra/alternative fonts is when you can use additional styles alongside the main one, like italic for emphasis or some ornate square one for menu.
It should be very straightforward now:

Code: [Select]

terminal_set("font: UbuntuMono-R.ttf, size=12");
terminal_set("italic font: UbuntuMono-I.ttf, size=12");
terminal_print(2, 1, "Its eyes are [font=italic]glowing[/font].");