I have what seems to me to be an "interesting" problem in my long-running Dungeon series. A dungeon is an array of tiles. Randomly placed in the array are rectangular rooms.

1/8
Rooms are connected from room N to room N-1 by halls from center to center, either first H then V or first V then H. This means that a given all way can cut through any other room, two halls can be side by side, making a wide hallway, and so on.

2/8
Like this:

Complex map in top right of dungeon picture.

3/8
My problem is this. I would like to have complex puzzles, I call them "set pieces", in the dungeon, for the player to solve. Maybe she has to find three switches, figure out what they do, and configure them a certain way to gain access to something valuable.

4/8
But the game program literally does not know what the dungeon layout is, and even if I were to place, say, a one-entrance set piece room first, the hallway logic could cut a second path right to it, by accident.

5/8
In a "real world" map like that, things would be arranged in convenient rooms for whatever the usage was. And doors would be built, paths walled up, based on knowledge of the big map.

In my game, there does not exist "knowledge of the big map".

6/9
I like that property, and want to maintain it. Yet I need to find suitable places to put puzzle items so that the puzzle will make sense.

I will think of something clever and elegant, if I can, or I'll brute force program my way through it.

7/8
I don't want to be given the clever and elegant solution, but I did want to talk about the problem. @ me if you wish.

8/8
Hm suppose we have defined layouts that demand, say, a single entrance. we block a rectangle and permit no hallway to go thru it. if some room tries to go HV to connect to another, and hits the block, it tries VH. if the dungeon winds up not fully connected, just roll another one
the Pathfinder monster maps all paths in the dungeon leading to the exit (dijkstra, basically). what else can we do with that info? certainly find places that are inaccessible.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Ron Jeffries

Ron Jeffries Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @RonJeffries

18 Mar
What matters?

Could we maybe stop fomenting hatred?
Could we maybe start calling it out as wring?

1/2
What doesn't matter?

Dungeon 124
I want to get a creature to lead us to the WayDown. And I feel the need to improve the campground. Also St. Gertude. And, as often happens, we don't go where I expect. Neat outcome, though
ronjeffries.com/articles/020-d…

2/2
Yes, I see a typo. Will fix. If you see two different ones, let me know.

3/2
Read 4 tweets
21 Feb 20
while i wait for a call from "the nurse", here are some thoughts about tests, including but not limited to TDD.

XP describes to kinds of tests, Programmer Tests, and Customer Tests. These names describe who the tests primarily serve.
Now in XP there are really only two main roles, programmer and customer. i don't want to argue about this right now, but customer is who the product is being written for, or their representative, and programmers are all the devs, testers, whatever software makers you have.
XP doesn't really contemplate separate testing. Like Scrum, at the end of the iteration, the "programmers" deliver a working tested integrated version of the product. N.B. tested.
Read 12 tweets
22 Jan 20
The thing about a framework, Scrum, TDD, whatever, is that it is a massive simplification of how the thing "should" be done.

A good framework has rumble strips and guard rails. When you hit those, they alert you to issues that the beginner would likely miss on their own.

1/9
As such, the framework IS NOT TRUE. If you follow it blindly, you will probably be OK, but you'll not be doing as well as you could, nor as well as the framework provider has in mind.

2/9
You're supposed to look up when the rumble strip rumbles, and think about how you got off the road. You're supposed to survive hitting the guard rail, to think about maybe slowing down for curves.

3/9
Read 9 tweets
18 Jan 20
OK, strong article to follow but for now, listen up.
There's this idea, the red/green/refactor thing, the never write a line of code not required by a failing test thing, the evolve the design based on the test and code plus your lovely imagination thing, the keep it clean thing.
I say "idea". You can see many ideas there already.

There is a name, TDD, Test-Driven Development or Test-Driven Design, that is applied to that bunch of ideas. We want to draw a bright line around the ideas that /are/ TDD, and to keep out the ones that are not TDD.
Yeah, no, we can't do that. Ideas are mushy and they flow one into another and they smear all over each other, and they change from something sensible to something stupid right before your eyes.

Still, we'd like to do that and for now I'll try to do that.
Read 19 tweets
31 Dec 19
I'm writing a thing about what it feels like to do TDD, in a kind of response to the articles and remarks by @jcoplien and @dhh and others. I agree, of course, that 100% line coverage, which you get for free with TDD, doesn't mean much in a theoretical sense.

1/6
Even 100% branch coverage doesn't mean much. While I don't subscribe to all the math in Cope's article, it's true that, theoretically, a program with high coverage can include plenty of errors.

What's interesting is that in practice, theory doesn't quite work.

2/6
If you TDD some little thing, making sure that every line of code you write is required by a meaningful test, and get it working, try this experiment.

Look at the code. Try to find places where a change to one or more lines will break the program but not break the tests.

3/6
Read 6 tweets
26 Dec 19
Well, I was going to write about "Doing it wrong" today, but it turns out that I already have. This article isn't quite what I'd say today but it's close:

ronjeffries.com/articles/019-0…

1/12
What would I say today that's different? Well, I'd clarify that there are at least three main ways that a TDD that doesn't work could differ from one that does:

- different design style.
- different problem: "TDD doesn't work here"
- different thing: "not TDD"

2/12
TDD favors a design style that leads to lots of very small, encapsulated items: classes, methods, functions.

If your preferred design style doesn't lean that way, you'll likely find TDD to be of less value.

3/12
Read 12 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(