Topics

1

Development Process & non-technical / Plans for 2023?

« on: January 17, 2023, 12:02:52 AM »

Greetings, hope you all have had a good start of the new year. Although the turn of the calendar year is really an arbitrary date, many pause around that time to reflect on where they're at and the path ahead … So I thought maybe someone would jump on a thread about plans and ideas for the upcoming year.

I'll go first, there's not so much time for RL dev these days, but I do get in a little bit; still tinkering on my cowboy fantasy rl Land of Strangers, where I've been rewriting a lot of the engine (cleaning up and porting to Python 3 and pygame-2, as well as adding native terminal support : ) It's been a while since the last release, so I hope to get a release or two out in 2023. Maybe even start a git repository.

Atm, I have a very stripped down version where I still haven't ported some of the more involved systems, like map generation and complex NPC behavior. To have a roadmap, I may essentially remake an earlier version of LoSt, that played out in a mine (you're a mine slave trying to escape). I can copy some of the old content and get basic map generation and AI. The scenario can also function as a sort of tutorial if I scale it well, and it can open up into the overworld through a literal exit if you beat the mission. There will also be the main option to start in the overworld, of course. Once systems are up and running, I'll be pulling in most of the content from the old version, and then start adding more new stuff again (more missions and encounter templates, though one of the things I still really don't know how I will design, is dialogue).

What about you? Post about yer games.

As always,
Minotauros

2

Temple of the Roguelike / Maintenance and codex updates

« on: August 10, 2020, 03:25:39 PM »

Commenting the recent updates, but I didn't want to clutter the official thread.

Hefty piece of work, well done, Slash. I like the new forum theme, and hope the under-the-hood stuff makes your life easier. The rearranging of the subforums seems sound enough. Although it's a bit sad to see Off Topic go, it has really been lost for so long anyway, so it almost doesn't matter at this point. It would be a blessing if the tide of spambots could be kept at bay. I also applaud the explicit encouragement of Rogue-lite discussion. Although I hardly play -lites myself, I like to read about and sometimes try them, as there are a lot of interesting design overlaps.

Also, I see you gave Krice the boot Don't know it it's permanent or what the details are. I'll say that I have found Krice to be an acquired taste, with actual input on the topic of RLs, even if his wording is a bitch a lot of the time, and I personally almost always disagree with him (and have admittedly myself been a bitch about that on occasion). Having said that, there are numerous examples over the years where he stepped way over the line with regards to blatant racism and sexism/homophobia (etc., but those two in particular). So I think I can grok that there is a rationale behind the ban.

As a general principle, it's not always possible to keep a community inclusive by having no rules of engagement. If someone makes statements that will make other members feel directly threatened or abused, it may be right to have OP either comply to a level of respect or else face a ban, rather than allowing those other members to just leave in silence.

As always,
Minotauros

3

Temple of the Roguelike / Security warning when entering temple forums

« on: June 15, 2018, 09:17:11 PM »

I'm getting a security warning when I access the forums (not the blog) lately. Firefox and Epiphany requires me to press an extra button to proceed, because

This does not look like the real https://forums.roguetemple.com. Attackers might be trying to steal or alter information going to or from this site.

Just thought I'd mention it

As always,
Minotauros

4

Traditional Roguelikes (Turn Based) / Land of Strangers #13 (One Crawled out of the Foxhole)

« on: May 03, 2017, 11:04:05 PM »

LAND OF STRANGERS
alpha open weird wild west fantasy cowboy RL

Get yer downloads here!

Released: Version 11 (Mercury Bubblegum)

This is an interim release of LoSt, preceding a hefty rewrite of some of the systems. I wanted to start refactoring from a clean cut, so to speak, so I'm publishing what I have to date. In other words, LoSt is still in alpha. Compared to #10, this version contains some bug fixes and a bit of content. The most spectacular feature is perhaps that you can now gain followers by choosing the "Populist" shtick.

Comments are always appreciated, on appropriate forum threads, per email, or you can fill out the in-game survey that I added as an experimental feature in this version. It'll be interesting to see whether that garners any response, and if I can use it to guide and motivate further development.

As always,
Minotauros

CHANGELOG
BUG: Couldn't pick up lead slugs when pockets were full
BUG: Buggy inventory interface if pockets were empty
BUG: Critters turned invisible when spending props
BUG: Could see through walls at certain angles
BUG: (Serious) bug that made game pick invalid kits
BUG: Bug that printed nonexisting plants and obstacles
BUG: Spitting bush had forgot how to spit
BUG: Some instances of NPCs getting stuck repeating one action
BUG: Crashed because game tried to draw outside the screen
GAME: Player can now start with up to two shticks
GAME: Some props can be used directly from inventory (experimental)
GAME: Prompt to abort extended actions when hostiles enter line of sight
GAME: Commandline options to set world seed
GAME: Scrollable menus (needs polish, but should work
GAME: Cleaned up the log area a bit
GAME: Can save multiple characters in the same world
GAME: Default field of vision now set to 11
CONTENT: Renamed "derringer" as "pepperbox gun"
CONTENT: Fleshed out animal species a bit
CONTENT: Weapon prefixes
CONTENT: Added some skills, props, places and critters
CONTENT: Backstory generator now spits out terser texts
AI: Added more bias switches: annoy, please, exalt
AI: Action calculation for fields of battle plants should be quicker
AI: Gain followers (experimental)
AI: Most beings now set to stay at home or roam their native region
AI: Toolwielders now better at choosing their weapon
VAR: Added an in-game survey
VAR: Various tweaks and fixes

Edit: Download links

5

Other Announcements / Granted, the last couple of years were a bit rough ;)

« on: December 20, 2014, 10:49:09 PM »

I just want to take a minute of silence, in contemplation of the Ascii Dreams' annual RL of the year poll.

As always,
Minotauros

6

Programming / Weighing the dice

« on: July 03, 2014, 11:23:07 AM »

In my game, most dice rolls are compared to a probability expressed as a fraction. Eg. you have a 1/3 probability of missing your shot or a 1/6 probability of scoring a critical hit. Right now, I just do something like this:

Code: [Select]

def roll_die(numerator,denominator):
   die_roll=random.randint(1,denominator)
   if die_roll<=numerator: return True
   else: return False
This "just works", and on a simple enough level for even me to understand, but I've been thinking about drawing dice rolls from a set pool of results. This would mean results are more stable over time, but should still allow for streaks of bad/good luck and so. Accompanying functions might look something like:

Code: [Select]

result_pool=[]
for i in xrange(1,601): result_pool.append(i) # insert numbers 1 though 600 into list
def roll_die(numerator,denominator):
   die_roll=result_pool.pop(random.randint(0,len(result_pool)-1) # pops a random number, removing it from the list
   result = Fraction(die_roll,600)
   prob = Fraction(numerator,denominator)
   if result<= prob: return True
   else: return False… and whenever result_pool gets empty, refill with numbers 1-600. This kind of solution is commonly used, though I don't exactly remember it's name at the moment. (I'm using something similar for monster placement in the upcoming release, and it yields a nice and balanced result: RNG can still screw you over during map generation, but you won't get either levels devoid of life or levels that are just cramped with enemies.)

A few questions:

* How large would you deem it reasonable to make the result_pool list? A smaller list yields more predictable results, obviously. The base probability for most actions is 5/6, and I can't imagine any probability going below 1/60 or above 59/60, so I can probably go as low as that – len(result_pool)==60, that is. But the player shouldn't be "counting bullets" either, in the sense of being able to know that "currently, my nominal P=1/6 in practice translates into P=1/2."

* Would it be a good idea to keep separate result_pool lists for the player and for other critters? If the idea is to "even out" the results a bit, the player can still get screwed if pulling all the bad results while mobs pull all the good results. I guess keeping one list for the player plus allies, and one list for opponents, seems fair.

Any thoughts? Maybe I'm just wasting time thinking about this. I definitely think it makes sense to nudge stuff like encounter/treasure tables in this way, but not so sure it really has much to say for tactical dice rolls. And too much predictability is not a good thing, either.

As always,
Minotauros

7

Off-topic (Locked) / Vagante

« on: June 20, 2014, 11:27:28 AM »

Hey, check out this sweet Spelunky-like Vagante: download alpha, and here's a dev log. And, it works in Wine

As always,
Minotauros

8

Design / Suspension of disbelief in tutorials

« on: June 04, 2014, 02:41:03 PM »

Posting about in-game tutorials here might hopefully give rise to some heated discussions. Typically, RLs don't feature tutorials, but I guess a "modern-styled" RL should be able to bear the burden. My question to y'all is mostly how you think one should strike the balance between immersive and techincally informative in such a tutorial. In particular, I'm thinking the tutorial mode could be just a starting scenario tailored to teach the player some basic concepts. Consider how analyses of some classic games emphasize how the starting levels often have some kind of teaching function. Eg. The first jump teaches you how to jump, then comes a second hurdle to make you understand the next important concept, etc. This is nice because it makes the player feel as if s/he's playing the game from the very outset. On the other end of the scale, you have really annoying tutorial modes with some disembodies voice going: "Now, to see if you've mastered movement, go over to the spot marked X. Then pick up the X by pressing "," (the comma sign (often (but not always) located to the right of Space (should be a really wide key on your computer)))."

In my RL of yore, I started implementing tiny side-quests in the village, intended to teach basic concepts. For instance, you could meet a farmer who wanted you to demolish a wall for him. The whole idea was to teach the player that certain tools could be used to destroy walls, and these quests were just placed randomly (or not) like any other piece of content. For my current game, I'm thinking of an explicit tutorial mode which starts you out with a companion NPC who gives you hints about what to do next. "Go over and pick up the gun," "Get closer to your target to increase shooting accuracy," and so forth. (Taking a note from a post Darren made once, I'd make the tutorial open in one end, so it's possible to enter the normal game from it, but also make it very difficult to survive, as a way of teaching about permadeath )

Still, there's a limit to how much info one can convey without breaking immersion, so to speak. Take Gearhead as an example: The first shopkeeper you speak to offers to provide information about system-specific things, like: "What does 'DV' mean?" It's done well enough, since the info is there as an option that more experienced players can ignore. Yet, it doesn't feel ideal for a genre where non-modality and open gameplay are held up as golden standards.

So, any thoughts on this? Is it better to have a one-off tutorial with a disembodied voice, or to somehow integrate lessons into the game? Or should we just include a readme and be done with it?

As always,
Minotauros

9

Development Process & non-technical / OSX compatibility across version

« on: June 04, 2014, 02:09:06 PM »

Purdy little going on here now. Better start some topics of my own, then

So, I'm trudging along on my cowboy RL, written in Python, and getting ready for an update sometime next week, or something (stay tuned). Getting out binaries for Linux and Windows isn't a problem, but then it would be nice to get the habit of releasing for OSX, of course. There are available applications to convert Python sources into OSX executables (or what you people call them). And I have an old Mac standing around, so this should be smooth as an oiled piglet, methinks? What brings me a bit of concern, though, is that this old Mac is old with a vengeance. I must've gotten it in the spring of 2007¹. So – if I "compile" a binary on this machine, is it still going to work on newer Macs? Or do I have to find an accomplice fanboi to do the dirty work of converting the scripts to a stand-alone application?

As always,
Minotauros

¹ I can double check the OS version, if that helps to clear things up.

10

Traditional Roguelikes (Turn Based) / Dungeon Monkey Eternal, by Joe Hewitt

« on: April 30, 2014, 07:38:59 PM »

Thought I'd link to this here. Joe Hewitt, creator of the legendary Gearhead RLs, has just released a new alpha project, a party-based RL with the auspicious title "Dungeon Monkey Eternal". I've just bare tried it out, and it looks promising at first sight.

http://www.gearheadrpg.com/?p=119

Features:
Classic dungeon RPG rule system, with 9 player species and 12 jobs. The mechanics were largely taken from Dungeon Monkey Unlimited, and several balance issues were addressed. All statistics are visible from the inventory/character sheet display.
Turn based tactics combat. Players and enemies can use spells, stealth, and a variety of skills.
Dynamic conversation system which customizes every character’s dialogue according to dialect and the story state. This also applies to the player characters.
Random world and story generation, including random generation of adventure game style puzzles.
Completely written in Python. No more homebrew scripting languages!

As always,
Minotauros

11

Incubator / RL Incubator Twenty-Fourteen Proposal

« on: November 24, 2013, 10:34:04 AM »

The RL Incubator and associated bundle didn't take off in 2013. It had an auspicious start, with some enthusiastic exchange showing that there is interest in the Incubator, but then the activity more or less stopped. Without dwelling too much on why this might have been so, I want to throw out a proposal for a revival of the Incubator in 2014 (if this post generates any response, we'll soon enough be discussing more explicitly what might have been done differently in the past, to come up with better solutions for the future).

I'm envisioning the Incubator as a hybrid web zine/game bundle of sorts. During 2014, the bundle would come out with twelve "issues", give or take. Each issue would contain a number of alpha/beta games, as well as a section with comments to the games released in the previous issue. To join, you'd have to submit a game as well as comments to the latest release of one or more other incubator games. I think there should be few restrictions on games allowed: They would have to be (intended as) Roguelikes, and perhaps we should also only allow free or noncommercial games.

The Incubator should have its own web page, with a front page exposing the latest issue, as well as an archive of older submissions. It should be possible to download each individual game directly through the website, or bundled together in an archive. The comments for each issue should probably be compiled into a document which can be downloaded separately. We could also use the database to do some simple statistics. I'm thinking about stuff like sorting games depending on how many times they've been released within the Incubator, how many comments they have gotten, an interface to access directly all comments to a certain game, etc.

Submitters might set individual goals for the year, aiming to reach a certain point before the December issue, which might come in the form of a megabundle, collecting the latest releases of all the games that took part in the project over the year. I'm instinctively thinking that this bundle should be free to download. I'm all for charity, but am afraid it might muddle the waters to add money into the mix at this point.

I would be willing to do some administrative work, such as receiving the submissions and compiling them into "release issues" each month, and/or maintaining the website (having some experience with php and mysql). I don't dispose of any server space, but maybe the Incubator could be hosted on the Temple?

Bear in mind that I'm just throwing this out as an idea for y'all to consider. If there's interest, we have December to discuss the details here in the forum and come up with a form that reflects what we want/need as a community. Instinctively, I'm thinking the threshold to enter should be low, as long as every submitter offers some comment on (some of) the games found in the latest issue(s). We could even allow for people to enter the Incubator with stuff like tilesets and other assets (perhaps with the stated goal of merging with a project within the December release). It would also be possible, for instance, to broaden the idea of the comments section. In addition to pure commentary, each issue might contain one or more articles or interviews, for instance. Just to say that the possibilities lie open at this point.

If we decide to go through with it, I'll join with Land of Strangers, as well as shouldering some of the administrative burden, as said. Now I'm just hoping to get some response to this. Any comments, ideas from any of you?

As always,
Minotauros

12

Other Announcements / Weird Roguebase entry

« on: October 19, 2013, 10:33:35 AM »

So, what's up with the latest entry in roguebase.net? A dead link to RL radio entitled "That skill system maybe isn't so great" … did someone hack the site, or something? Still, I'd actually love to hear that episode

As always,
Minotauros

13

Programming / Simple FOV on a hexagonal grid

« on: October 07, 2013, 11:09:10 PM »

I just implemented field of vision (FOV) in Land of Strangers, and figured I'd share my method, as it took me a bit of brain wracking to come up with a pretty simple solution. It is also reasonably quick – badly implemented in Python and crunching on my low-end netbook, my function scans a map of 469 hexes in about 0.1 seconds. To see the actual code I came up with, download the source code of Land of Strangers and check out the module named fov.py.

At first, I revisited my high school trigonometry. Keeping in mind that the ratio between a hexagon's height H and width W equals H/W = 2/√3, and that you can quite easily divide a hexagon in pretty chunks (see attempt at illustration below), it's not very difficult to calculate the distance and angle between two points on a hexagonal grid, using the inverse tangent. Here's some crappy ascii art to show the inner dimensions of a hexagon (or click here for a much better image)

Code: [Select]


 /\  h  H = 4h
|  | h  W = 2w
|  | h  H/W=2/√3
 \/  h
 ww
After pondering the problem for a bit, though, I'm glad to say I didn't need to apply that knowledge. Instead, I found a pretty easy way to implement shadowcasting on a hexagonal grid. Basically, you start at the center and spiral outwards, covering one ring of hexes for each iteration of the shadowcasting routine. The innermost ring (first iteration) consists of the 6 hexagons directly adjacent to the center, the second ring/iteration touches 12 hexagons, the next ring 18 hexes, then 24, 30, 36, etc. for as long as you want to go. Tracing the spiral is pretty trivial, so I'll leave that up to you. Here's to illustrate the kind of spiral I'm talking about:

Code: [Select]

. . . . . . . .
 . . J 8 9 . .
. . I 7 2 A . .
 . H 6 1 3 B . .
. . G 5 4 C . .
 . . F E D . . .
. . . . . . . .
It may be obvious to brighter minds than my own, but it took me days to consider that since a perfect circle always maps 360°, it's trivial to know that in the first iteration (hexes 2-7), consisting of 6 hexes, each hex spans 360°/6=60°; in the second iteration that is narrowed down to 360°/12=30°, in the third iteration 360°/18=20°, and so forth. The minimum and maximum angles of hex number H of iteration number N thus equals:

min_angle=(H-1)*(360 / (6*N))
max_angle=min_angle+(360 / (6*N))

For odd numbered iterations, we need to subtract (360 / (3*N)) from these numbers.

At this point, implementing shadowcasting on the grid is really easy. Here are the basic steps I took:

In preparation, make two empty lists: One to add hexes that are seen, and one to keep track of shadows that have been cast. The entries we put in this shadow list should be pairs of digits, where the first digit signifies the minimum angle of a cast shadow, and the second digit the maximum angle. Eg. if the very first hex (right NE from the viewer) casts a shadow, that shadow would be signified as a (0,60) entry in the list.

Now, loop through every hex of every iteration, doing the following:

1. Test the hex' min/max angles against existing shadows: If it falls within any shadow (the hex' min_angle is higher than the min_angle of the shadow AND the hex' max_angle is lower than the max_angle of the shadow), that hex is out of view.

2. If the hex is not shaded, add it to the list of visible hexes.

3. If the hex blocks view, add a new shadow with that hex' (min_angle,max_angle) in the list of shadows cast.

3b. If the new shadow overlaps an existing shadow, it's pertinent to merge the two into one, spanning from the lowest min_angle of the two shadows, to the highest max_angle.

Whenever you come to a hex where the min_angle is less than 0 or the max_angle is higher than 360, you need to make the program understand what's going on. For my part, I simply split such angles in two. For instance, to test the first hex of the second iteration, spanning (-15°,15°), I'd test to see if (345,360) is shaded AND (0,15) is shaded. If both are true, it follows that the hex is shaded. Likewise, to cast a shadow from that hex, I'd split it in two entries – (345,360) and (0,15) – to put in the list of shadows cast.

To optimize further, you can automatically skip over hexes that are necessarily shaded. If the algorithm just stated that the hex spanning (0,20) is out of view because of a shadow spanning (0,180), you can really just autoshade the next 5 hexes and test again for the hex spanning (180,200).

Depending on how you do your calculations, some shades may not merge properly, for instance if you're ending up with digits like 79.999. An ugly, effective way to deal with this is to enlarge every shadow by half a degree on both sides, to make sure everything overlaps nicely. A more elegant solution would be to use fractions, but at least in Python, that makes calculations ten times as slow. Sometimes the ugly kludges are better

As always,
Minotauros

14

Programming / Keeping gamepads (and other odd peripherals) in mind

« on: September 05, 2013, 10:01:31 AM »

I know some people play with a gamepad. I believe Legend is the only one who does RLs on a gamepad, but I think we should all be zealous about catering to Legend's needs So for the game I'm currently starting to write, I've been thinking I want an interface that plays well with this particular device.

But what should I keep in mind? I don't really know much about the anatomy of gamepads in general. How does a typical gamepad handle diagonals, for instance? How many buttons do I have to play with? Some buttons are typically "metabuttons", like Select and Start, right?

I want to keep the UI clean and simple, with just a few buttons needed to play the game, and the default option to access inventory etc. with the cursor keys. The keys will all be remappable, and I'll add options for keyboard shortcuts (eg. immediately access item X, without first navigating through the inventory), but they'll be optional to streamline the experience for keyboard users, whilst retaining a functional UI for those who'd rather wield a mouse or a gamepad.

Related question: Am I right in believing that mouses/touchpads used on Macs only have one button? If so, the game must be playable with just the left mouse button, or am I missing something?

As always,
Minotauros

Edit: Maybe I'm just being lazy asking this. If that's the case, sorry, feel free to ignore me. There is already this thread, I see, where I learn that the gamepad has 12 buttons in total, and that there is an application called xpadder to map the keys manually. That leaves me wiser, but still not quite enlightened, I think. How much of a hassle is this xpadder thing, for instance. I'd love a game where you can just plug in your gamepad, and go: "A to fire, B to reload, Select for extended actions, and Start for main menu, yeah, okay, let's make bonnets bloody!" I can also surely seek out some documentation on the web. But maybe this post can spawn some interesting discussion anyway.

15

Other Announcements / Tiamyth

« on: August 15, 2013, 06:42:52 PM »

I came across mention of this old game called "Tiamyth", developed by Mario Donick (of Lambda Rogue fame, and temple dweller of yore). Apparently a game that ties in card mechanics with standard RL tropes, it did spawn some discussion, but there doesn't seem to be any available version for download or similar. It sparked my curiosity, and I'd like to know more about it or try it out, if at all possible. Does anyone remember this? Played it? Have a copy lying around? Any takers?

As always,
Minotauros