On 2023-12-27, Don Y wrote:
> On 12/27/2023 11:00 AM, Dan Purgert wrote:
>>>> So this is the grid, with the "W" representing the spaces with walls,
>>>> "D" being the doors, and the "0" being the tiles a character might be
>>>> on.
>>>>
>>>> W W D D W W
>>>> W 0 0 0 0 W
>>>> D 0 0 0 0 D
>>>> D 0 0 0 0 D
>>>> W 0 0 0 0 W
>>>> W 0 0 0 0 W
>>>> W W W W W W
>>>>
>>>>
>>>> Here, we've switched "on" the fire effect ('1's)
>>>>
>>>> W W D D W W
>>>> W 0 1 1 0 W
>>>> D 0 1 1 0 D
>>>> D 1 1 1 1 D
>>>> W 0 0 0 0 W
>>>> W 0 0 0 0 W
>>>> W W W W W W
>>>>
>>>> So, any character that happened to be standing in the "1" spaces would
>>>> get hurt.
>>>
>>> So, characters can occupy any (1,1) cell? I.e., in the example, above,
>>> every 0 (or 1) could have a character -- as well as "in" the doorways?
>>
>> Yep
>>
>>> How do players distinguish THEIR character from others (and effects)?
>>> Or, are their characters real bits of plastic sitting ON the tile?
>>
>> Yep, figurines or even just tokens stolen from other games (e.g.
>> "Trouble" or "Monopoly", etc). Anything that the players can remember as
>> "them" or "that Goblin I'm fighting" ...
>
> OK. I keep thinking in terms of video games. <frown>
>
> So, the (your) tiles are just meant to ENHANCE the visuals,
> not *be* the visuals.

Correct :) The "enhanced visuals" are just simple things to show an
area-of-effect thing happening, instead of paper or plastic templates
over top of the game board (or counting squares)

>
>>>>> [I'm trying to get an idea of what the effects would be like,
>>>>> in terms of complexity]
>>>>
>>>> For now, they're gonna be really simple (just solid red). Eventually,
>>>> probably replace the shift-registers with proper LED drivers, that can
>>>> help do brightness control, etc (so I can mix the RGB channels and get a
>>>> more "fire" looking color orange, or "electric blue", and so on)
>>>
>>> The downside of putting the effects in the MCUs is that you'd
>>> either need to reflash them each time you tried a new effect
>>> *or* design them with RAM in which the effect could be stored
>>> (DL at game initialization?)
>>>
>>> [I took the latter approach]
>>
>> The "Effects" are pretty static in general terms (e.g. that flame-jet
>> trap is ALWAYS that shape when on the grid. If it's 45 degrees to the
>> grid, then it'd just look like this:
>>
>> 0 0 0 0 0
>> 0 1 0 0 0
>> 0 1 1 0 0
>> 0 1 1 1 0
>> 0 0 0 0 0
>>
>> Other effects might approximate a circle:
>>
>>
>> 0 0 0 0 0 0 0 0
>> 0 0 0 1 1 0 0 0
>> 0 0 1 1 1 1 0 0
>> 0 1 1 1 1 1 1 0
>> 0 1 1 1 1 1 1 0
>> 0 0 1 1 1 1 0 0
>> 0 0 0 1 1 0 0 0
>> 0 0 0 0 0 0 0 0
>>
>> Or just a line.
>
> OK. I was assuming the "flame jet" would be an animated *sequence*...
> several consecutive "frames" arranged to generate an "effect".
> So, it might be:
>
> 0 0 0 0 0
> 0 0 0 0 0
> 0 0 0 0 0
> 0 0 0 0 0
> 0 0 0 0 0
>
> 0 0 0 0 0
> 0 0 0 1 0
> 0 0 0 0 0
> 0 0 0 0 0
> 0 0 0 0 0
>
> 0 0 0 0 0
> 0 0 1 1 0
> 0 0 0 1 0
> 0 0 0 0 0
> 0 0 0 0 0
>
> 0 0 0 0 0
> 0 0 1 0 0
> 0 0 1 1 0
> 0 0 0 0 0
> 0 0 0 0 0
>
> 0 0 0 0 0
> 0 1 1 0 0
> 0 0 1 1 0
> 0 0 0 1 0
> 0 0 0 0 0
>
> 0 0 0 0 0
> 0 1 0 0 0
> 0 1 1 0 0
> 0 0 1 1 0
> 0 0 0 0 0
>
> 0 0 0 0 0
> 0 1 0 0 0
> 0 1 1 0 0
> 0 1 1 1 0
> 0 0 0 0 0
>
> in half-second (?) snapshots.
>
> [This is why I was suggesting the MCU as it would allow the
> data rate to be lowered so the controller just had to say
> "do this" instead of actually *doing* it in place of the MCU]

Maybe for a version two :)

>> [...[
>> No, it's printed that way. Normally a "full tile" is 2x2 playable
>> spaces, i.e.
>>
>> S S
>> S S
>
> You speak as if this is a *standard* (?) and not just an attribute of
> your particular implementation?
>
>> But a ruin / chasm / etc tile may only be
>>
>> S S OR S S
>> - - - S
>>
>> (with the "-" indicating the missing space). The "broken" edge then
>> (i.e. touching the "-") will be printed up to look like the stone floor
>> cracked, or if it's an abandoned wooden structure, you'll have a bit of
>> floor joist sticking out, etc.
>
> So, you'd not want the PCB beneath to be exposed in those cases?
> Could the PCB be potted in a black substance so only the actual
> LED is exposed to daylight (and easily ignored if that "corner"
> is meant to not exist?)

Less that I don't want it there, and more that (as currently designed),
it doesn't physically fit those "damaged" tiles. They're made to snap
together, so they have approximately a 0.100" thick "base" that the PCB
slips up into. So I'd either

(a) need a differently shaped PCB to accommodate the odd shapes (and
also move where the connections are on them) OR
(b) cut away the edges of those tiles, to let the "Standard" PCB stick
out as you're suggesting.

>
>> Ultimately, that "edge" part of the feature doesn't accommodate the
>> shape of my LED board; and even if I did make a custom board for those
>> features, the current design puts the connector dead-center on the LED
>> carrier. Moving those connection points around is potentially possible,
>> but I'd rather get the general idea into a "working" state before
>> changing too many other things.
>
> You'd, presumably, also have to deal with the case where *two* corners
> (or three!) were missing -- and *which* corners (e.g., opposite or adjacent)
>
> I.e., there's a big incentive for you to find a way to NOT need
> to address that on your PCB.

Simplest solution -> those tiles don't get a PCB :)

>
>>>> With the current multiplexed approach, those "odd" tiles don't cause any
>>>> trouble (other than an extra ring of non-effect that's suboptimal, but I
>>>> can live with that, since it's less engineering
>>>
>>> Why can't one of the "effects" commanded to an MCU encode the
>>> same appearance/behavior?
>>
>> Right now, a single board is basically $2 assembled (4x LEDs packages,
>> 1x connector, 12x resistors); plus something like $6 for the
>> "motherboard" (ATMega328 + 3x shift registers + 8x BJTs +
>> caps/resistors/etc. as required).
>>
>> Even adding "just" an ATTiny 202 is upping each slave board's price by
>> 25% or so (and that's ignoring any data-integrity stuff like switching
>> to e.g. RS485, etc). I'm not saying I won't be going there; but seems a
>> bit premature to jump into that for an idea that may have other flaws
>> elsewhere.
>
> You'd only have to worry about comms *to* the board (from a PC?).
> There are also really cheap MCUs, given that these wouldn't need
> to do much.

Tiny202 is (as far as I know) the simplest / cheapest option that has
necessary hardware (UART).

>
> Here, you have to decide if you are looking for a small quantity
> build *or* planning on it, someday, being built "in quantity".
> You likely don't want to have to revisit all of your design
> decisions (and implementation choices) if you change your mind,
> later. (rehashes tend to take a lot longer because they open
> the door for feeping creaturism; then, you have to decide when
> it's an appropriate time to "shoot the engineer" lest the rehash
> never get built!)

Yeah, but the immediate concern is "does it even work in the absolute
simplest method I can devise" (which is 8x8 multiplexing). If you can't
even see the indicators well through (holes in) the tiles, well, it's a
bit dead in the water

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860