Messages

1

Programming / Re: Procedural tileset nicener: Wangscape (v0.1)

« on: June 07, 2017, 05:30:31 PM »

Different games need natural-looking borders more (Civ series) or less (chess). Distances are easy enough to see if the game has optional grid lines.
Currently development is focussing on features rather than fine-tuning the example configurations, but we'll make the example borders a bit more subtle before the next version

2

Programming / Procedural tileset nicener: Wangscape (v0.1)

« on: May 30, 2017, 02:26:09 PM »

Wangscape is an open-source program which converts rectangular terrain tiles into corner Wang tilesets with natural boundaries. Version 0.1 has just been released with Windows and Linux support, and can be downloaded here: https://github.com/Wangscape/Wangscape/releases/tag/v0.1.

Corner Wang tilesets are described well at cr31.co.uk. Civilization 2, Civilization 3, and Freeciv make extensive use of them.

Wangscape generates tiles using coherent noise. A noise map is made for each corner, and each pixel in the output tiles blends pixels from the input tiles according to the noise values. The noise values are made by combining libnoise modules, to ensure that borders match and to make the output fully user-customisable. For more details, see Wangscape's algorithm document.

Wangscape is an open source (MIT-licensed) project written in C++/Python/JSON, and contributions (bug reports, example configurations, documentation, code) are welcome. See CONTRIBUTING.md for more information.

3

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

« on: May 25, 2017, 09:58:25 AM »

If you have two kinds of display elements, their grid spacings are coprime, and you don't want to use a 1x1 cell size, then you can draw one kind of display element (text) grid-aligned using print() and the other kind (graphics) all at (0,0) with composition and pixel offsets.
I don't think there are any benefits to making text and graphics so mismatched in a terminal game, though.

4

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

« on: May 23, 2017, 09:14:32 PM »

You could use a grid with 4x12 cells, and configure the font with "size=16x16, spacing=2x1". Then square symbols would need 3x1 spacing.

5

7DRLs / Corpse Stacker [7DRL 2017] [Success]

« on: March 13, 2017, 03:11:13 AM »

Corpse Stacker

github
windows



Zombies enter from the sides of the level, they raise the terrain height when you kill them, you need to make a stack of 10.

Needs Python or Windows.

6

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

« on: March 07, 2017, 02:22:27 AM »

Update time: 0.15.0 (Windows / Linux / OS X / PyPi)

The main (but still minor) version bump comes from a slight change in printing function. Not sure what had I been under while first implementing that, but until now text wrapping/aligning was done via in-text formatting tags:

Code: [Select]

terminal_printf(2, 1, "[bbox=%dx%d][align=center]%s", w, h, str);To make things even messier, print() was returning either width or height of a string depending on the presence of bbox. While there is some logic, the overall it is just... ugh.

Now print() (or a variant of it if no overloading available for the language) accepts width, height and alignment parameters explicitly and always returns both dimensions:

Code: [Select]

y += terminal_print_ext(x, y, width, 0, TK_ALIGN_DEFAULT, message).height;And same goes for measure().

Could you update http://foo.wyrd.name/en:bearlibterminal:reference#print with the new print() signature? It still talks about the "[bbox=*]" syntax, without giving any examples, so it's quite misleading.

7

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

« on: January 08, 2017, 04:13:08 AM »

Thanks for continuing to develop this library

More than once when working with bearlibterminal I've needed to implement maps that scroll smoothly. The included demo application also has a smooth-scrolling sample. The problem with implementing this in BLT is that when the display is offset by a fraction of a tile, there are more tiles to be drawn than there are slots in the terminal. There are two ways around this:

• Use composition, put all the tiles at (0,0), use the pixel offset to control where they appear.
• Use composition, put most of the tiles in the correct slots with uniform pixel offsets, put one row and one column in the wrong slots with different pixel offsets.

Both methods "work" and don't seem to have any performance implications, but from the perspective of code readability I would prefer to be able to put each tile in its own slot. That's not currently possible because characters can only be put inside the terminal's boundaries.

Would it be possible to extend the terminal storage, writing, and drawing outside the bounds imposed by TK_WIDTH and TK_HEIGHT? Just one row and one column would be enough for this purpose, but another option would be to have a configurable number of extra rows and columns on each side. This could be helpful when drawing 2.5D terrain where tiles could be N rows off the bottom of the terminal but still be high enough that they should appear on the display.

Here's a discrete dimetric heightmap drawn with BLT. It probably would have been easier with a configurable number of extra rows on the top and bottom.

8

Programming / Re: Rule libs for managing statuses & attributes?

« on: October 26, 2016, 10:32:45 PM »

I recently started on a prototype for a Python library that creates relationships between simple values. It was targetted more at incremental game mechanics than roguelikes, but the idea was that you could set variables and combine them into new ones, and you could later change any of them and have the new values propagate changes. Like a spreadsheet with variable names instead of a cell grid.
So you could do things like this:

Code: [Select]

Strength = Variable(18)
WeaponDamage = Variable(10)
RealDamage = Strength + WeaponDamage
print(RealDamage) #28
Strength += 1
print(Strength, RealDamage) #19, 29
I made wrappers for all the functions in the math module, a fake Boolean class that returned the correct result from the unary ~ operator (since Python boolean operators aren't compatible with this concept), and started on support for containers wrapped in this kind of Variable object.
But I couldn't figure out how I wanted iteration to work (if I wanted it at all) or what syntax I wanted to reuse groups of variables and make systems change over time. I decided to skip solving for unknown variables, since that's what SymPy is for.

The project is on the back-burner for now, because it won't be useful in my procjam or NaNoGenMo projects.

9

7DRLs / Re: The Trapped Heart

« on: March 14, 2016, 05:49:34 PM »

Darren, did you wait for topic 4999 to appear before you pressed the Post button?

10

7DRLs / Re: Glorious Bastet (7DRL 2016)

« on: March 14, 2016, 04:19:48 PM »

So, Glorious Bastet was a glorious failure. I have a lot of engine code that will see further use, a nice map generator, an @ walking around on it, and some very basic tiles. Hopefully this will turn into something with gameplay at ARRP 2016.
Screenshot:

Download, if you'd like to take a tour of the maps: https://dl.dropbox.com/s/smc73c1vmfwfmq9/GloriousBastet.zip

11

7DRLs / Glorious Bastet (7DRL 2016 - failure =)

« on: March 07, 2016, 09:35:27 PM »

Hello! Just announcing my 7DRL for this year, Glorious Bastet. It's going to be about various species of felids doing ritual combat in a ruined Egyptian temple in order to gain long life and political power (or die in the process). So far I have a design document a few hundred lines long and no code, but hopefully that'll change before the end of the challenge!