Some Quick And Dirty Boards for a Tabletop Game Idea

Kind of a fun idea I had (actually a few months ago) to create a
bit of an augmented experience when playing Dungeons and Dragons (or,
well, I suppose any tabletop / Pen & Paper RPG that happens to use a 1"
grid, but I play D&D, so ... this is where I'm focused ;) ).

Came across 3d-printable projects for making various tile-sets (think
dungeons / caverns / taverns / etc. ) and after printing a few, realized
that with some pretty minor modifications, I could cram a PCB with some
RGB LEDs on it to do different things (mostly Area-of-Effect things;
like your classic fireball, or lightning bolts, etc.  It's always a pain
with those trying to figure out on the board just "where" the borders of
the effect are).

These are the boards that fit within the tiles themselves:
https://git.ad8gc.com/ad8gc/DnD_PLCC4/-/blob/main/Schematic.pdf

And these are the "carriers" that'll allow one to snap four tiles in a
row (limited since wider ones got stupid expensive stupid fast for "I
probably made a massive error here" :D)
https://git.ad8gc.com/ad8gc/DnD_Connector/-/blob/main/Schematic.pdf

Mainly, this is to facilitate testing & debugging -- these are designed
to accommodate a "test bench" of 4x4 tiles (8x8 spaces), and also let me
verify that they're short enough to accommodate widening out to 8 or 12
spaces (albeit that'll need an additional 4 or 8 VCC lines, larger
headers, and a wider PCB, not to mention some kind of jumper board or
something.  

Not shown / drawn up yet (in KiCAD, anyway) is the MCU / Driver
"Motherboard".  Effectively it's an ATMega328, 3 shift registers (1ea.
for the R,G,B channels) and eight FETs to drive a grid of 8x8 RGB LEDs,
plus power input. (I might be missing a few bits in the description,
it's done up right now as pencil and paper,  with a 1-channel MWE done
up on perfboard).

My two design goals were that:

1. These things be easy to use for non-programmers (especially if I
opted to make it into a "product" -- doubt I will, but hey, some people
have more money than time).  Ideally, the only programming it's going to
take is defining the room dimensions (essentially the lower-right
corner, given that 0,0 is the upper-left)

2. The tiles be 180-degree rotationally symmetric, to reduce the need
for "single-use" tiles (e.g. wall sections can be either North/South or
East/West, rather than JUST N or JUST E).  Maybe one day I'll figure out
90 degree symmetry to completely eliminate it.

To accomplish #1; I went with using standard LEDs with multiplexing,
this eliminated two problems I faced with smart/programmable LEDs:

  1. Data delivery --> while you need 75% fewer control signals for 
      "smart" LEDs, things get massively ugly when trying to divide them 
      into rows and columns.  You're either zig-zagging the signal on
      every other row; or having a return path on every row, so that
      they all start from the left (right).  Conversely, with
      multiplexing, I just have a grid, with {0,0} being the upper-left
      corner.
  2. Requires "Special" tiles to facilitate data flow.  For example, a
      chasm in the middle of the room would still need some kind of 
      carrier PCB to keep the signal flow across / around the chasm
      set-piece.  Whereas with the multiplexing, the row/column control 
      plane (on the carrier-board itself) is otherwise unbroken.

To accomplish #2, I went with some low-profile board-to-board connectors
(cue them NOT being rotationally symmetric when I get the 10 or so I
ordered :) ) ... I want to keep things relatively low-profile, so the
individual boards can survive semi-rough handling (e.g. getting stacked
in a case / bin / etc.) that would be problematic with pin-headers.  I
envision needing a few revisions here, since eventually I want to do
away with the "strips", and replace those with what would amount to
individual breakout boards, since the PCBs are otherwise quite big and
sparsely populated due to the physical spacing of the game-board.

Likewise, I expect a few revisions on LEDs, etc (I mean, these
common-anode look really nice, but there are *slightly* cheaper options
that don't do the common-anode on-die).


-- 
|_|O|_|
|_|_|O| Github: https://git.ad8gc.com/ad8gc
|O|O|O| PGP: 51B6 47EA 8D7D B5C8 974D  B0F3 ADE0 4E6E 03E9 745B

The arsehole Dan Purgert <dan@djph.net> persisting in being an Off-topic troll...

-- 
Dan Purgert <dan@djph.net> wrote:

> Path: not-for-mail
> From: Dan Purgert <dan@djph.net>
> Newsgroups: sci.electronics.design
> Subject: Some Quick And Dirty Boards for a Tabletop Game Idea
> Date: Wed, 27 Dec 2023 02:42:17 -0000 (UTC)
> Organization: A noiseless patient Spider
> Lines: 83
> Message-ID: <slrnuon3rk.clb.dan@djph.net>
> Injection-Date: Wed, 27 Dec 2023 02:42:17 -0000 (UTC)
> Injection-Info: dont-email.me; posting-host="b343546bc4119bb9ae70f852f384e7e0";
> 	logging-data="3871269"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18kLLEtDru1DCVYg6DvlF48/TY0S7MI9IA="
> User-Agent: slrn/1.0.3 (Linux)
> Cancel-Lock: sha1:9Lre6SaZvl9F7h3iSU5DYHY9DJQ=
> X-Received-Bytes: 5251

On 12/26/2023 7:42 PM, Dan Purgert wrote:
> These are the boards that fit within the tiles themselves:
> https://git.ad8gc.com/ad8gc/DnD_PLCC4/-/blob/main/Schematic.pdf

So, these are just lamps+ballast?

> And these are the "carriers" that'll allow one to snap four tiles in a
> row (limited since wider ones got stupid expensive stupid fast for "I
> probably made a massive error here" :D)
> https://git.ad8gc.com/ad8gc/DnD_Connector/-/blob/main/Schematic.pdf

Can you, instead, put a small MCU on the "LED boards" and just run power/gnd,
and data in/out to each board?  Let boards daisy chain their "out" signal
to the neighbor's "in".  That way, you can delegate the control of the
lamps to each little MCU as well as limiting the amount of "drive"
required on each (this would scale better than a single driver board).

Note that -- unlike "smart" LEDs -- you don't have to pass a bitmap around
but, instead, can send "commands" to each MCU telling each what sort of
effect you want *it* to provide for *it's* lamps.

(defining those effects would then be your primary design problem...
unless you chose an MCU that allowed you to DL little "scripts" into
scratchpad RAM therein)

> Mainly, this is to facilitate testing & debugging -- these are designed
> to accommodate a "test bench" of 4x4 tiles (8x8 spaces), and also let me
> verify that they're short enough to accommodate widening out to 8 or 12
> spaces (albeit that'll need an additional 4 or 8 VCC lines, larger
> headers, and a wider PCB, not to mention some kind of jumper board or
> something.
> 
> Not shown / drawn up yet (in KiCAD, anyway) is the MCU / Driver
> "Motherboard".  Effectively it's an ATMega328, 3 shift registers (1ea.
> for the R,G,B channels) and eight FETs to drive a grid of 8x8 RGB LEDs,
> plus power input. (I might be missing a few bits in the description,
> it's done up right now as pencil and paper,  with a 1-channel MWE done
> up on perfboard).
> 
> My two design goals were that:
> 
> 1. These things be easy to use for non-programmers (especially if I
> opted to make it into a "product" -- doubt I will, but hey, some people
> have more money than time).  Ideally, the only programming it's going to
> take is defining the room dimensions (essentially the lower-right
> corner, given that 0,0 is the upper-left)
> 
> 2. The tiles be 180-degree rotationally symmetric, to reduce the need
> for "single-use" tiles (e.g. wall sections can be either North/South or
> East/West, rather than JUST N or JUST E).  Maybe one day I'll figure out
> 90 degree symmetry to completely eliminate it.

I guess I don't understand how these are further "conditioned".
Isn't it just a matrix of indicators?  Do the (3Dprinted?) tiles
have additional "character" (e.g., contours, etc.)?

Photo?

> To accomplish #1; I went with using standard LEDs with multiplexing,
> this eliminated two problems I faced with smart/programmable LEDs:
> 
>    1. Data delivery --> while you need 75% fewer control signals for
>        "smart" LEDs, things get massively ugly when trying to divide them
>        into rows and columns.  You're either zig-zagging the signal on
>        every other row; or having a return path on every row, so that
>        they all start from the left (right).  Conversely, with
>        multiplexing, I just have a grid, with {0,0} being the upper-left
>        corner.

Keep in mind that if you multiplex the lamps (which seems like
you may be intending?), then brightness falls with duty cycle.
And, that you need to keep the "frame" rate high enough that
the user doesn't see flicker or visual artifacts as it beats
against the room lighting.

(you may discover that a non-sequential refresh sequence helps
hide visible patterns)

>    2. Requires "Special" tiles to facilitate data flow.  For example, a
>        chasm in the middle of the room would still need some kind of
>        carrier PCB to keep the signal flow across / around the chasm
>        set-piece.  Whereas with the multiplexing, the row/column control
>        plane (on the carrier-board itself) is otherwise unbroken.
> 
> To accomplish #2, I went with some low-profile board-to-board connectors
> (cue them NOT being rotationally symmetric when I get the 10 or so I
> ordered :) ) ... I want to keep things relatively low-profile, so the
> individual boards can survive semi-rough handling (e.g. getting stacked
> in a case / bin / etc.) that would be problematic with pin-headers.  I
> envision needing a few revisions here, since eventually I want to do
> away with the "strips", and replace those with what would amount to
> individual breakout boards, since the PCBs are otherwise quite big and
> sparsely populated due to the physical spacing of the game-board.

*If* the 3D "skin" is something that the user can clip on/off the
"lamps", then you could just put a "no feature" tile atop
the lamps so that they can't be seen AND program that MCU to keep
them dark.

> Likewise, I expect a few revisions on LEDs, etc (I mean, these
> common-anode look really nice, but there are *slightly* cheaper options
> that don't do the common-anode on-die).

On 2023-12-27, Don Y wrote:
> On 12/26/2023 7:42 PM, Dan Purgert wrote:
>> These are the boards that fit within the tiles themselves:
>> https://git.ad8gc.com/ad8gc/DnD_PLCC4/-/blob/main/Schematic.pdf
>
> So, these are just lamps+ballast?
>
>> And these are the "carriers" that'll allow one to snap four tiles in a
>> row (limited since wider ones got stupid expensive stupid fast for "I
>> probably made a massive error here" :D)
>> https://git.ad8gc.com/ad8gc/DnD_Connector/-/blob/main/Schematic.pdf
>
> Can you, instead, put a small MCU on the "LED boards" and just run power/gnd,
> and data in/out to each board?  Let boards daisy chain their "out" signal
> to the neighbor's "in".  That way, you can delegate the control of the
> lamps to each little MCU as well as limiting the amount of "drive"
> required on each (this would scale better than a single driver board).

"maybe" -- but ultimately the issue is going to be drawing an "area" on
the (in-game) floor where something happened.  

USUALLY this is done either by:

  (a) counting squares from the "center" of the effect
  (b) paper/plastic templates held over the "center" of the effect

>
> Note that -- unlike "smart" LEDs -- you don't have to pass a bitmap around
> but, instead, can send "commands" to each MCU telling each what sort of
> effect you want *it* to provide for *it's* lamps.

Which would require that the slave MCU to have a programmable address
(and then there's the problem of address conflicts), and on top of that,
there'd need to be a way to convey which slave was at which position of
the "game board", so that the effects would be done correctly.



>> My two design goals were that:
>> 
>> 1. These things be easy to use for non-programmers (especially if I
>> opted to make it into a "product" -- doubt I will, but hey, some people
>> have more money than time).  Ideally, the only programming it's going to
>> take is defining the room dimensions (essentially the lower-right
>> corner, given that 0,0 is the upper-left)
>> 
>> 2. The tiles be 180-degree rotationally symmetric, to reduce the need
>> for "single-use" tiles (e.g. wall sections can be either North/South or
>> East/West, rather than JUST N or JUST E).  Maybe one day I'll figure out
>> 90 degree symmetry to completely eliminate it.
>
> I guess I don't understand how these are further "conditioned".
> Isn't it just a matrix of indicators?  Do the (3Dprinted?) tiles
> have additional "character" (e.g., contours, etc.)?

Yep -- Think of the playing surface as a *VERY* low-resolution display screen:
there's only a resolution of 1 pixel / inch (and for testing, I'm
working with a "display" that's all of 8x8 pixels.).  The standard
playing surface is effectively a large sheet of graph paper, with a
1-square / inch grid).  You draw walls and doors and whatever else on
the board in (wet-erase) marker. The 3d printed tiles are ... well, the
same idea, just, now it's a bunch of plastic pieces that you can set out
in whatever order to build up the room to make things more immersive
for everyone.

>
> Photo?

Here's an example of the 3d-printed tileset.  The room here is comprised
of nine (9) individual 3d-printed tiles (All are 2x2 playing spaces,
even though the walls eat half the space, to keep the real-world
dimensions "correct") : https://www.fatdragongames.com/images/FDG0160AW7.jpg


>
>> To accomplish #1; I went with using standard LEDs with multiplexing,
>> this eliminated two problems I faced with smart/programmable LEDs:
>> 
>>    1. Data delivery --> while you need 75% fewer control signals for
>>        "smart" LEDs, things get massively ugly when trying to divide them
>>        into rows and columns.  You're either zig-zagging the signal on
>>        every other row; or having a return path on every row, so that
>>        they all start from the left (right).  Conversely, with
>>        multiplexing, I just have a grid, with {0,0} being the upper-left
>>        corner.
>
> Keep in mind that if you multiplex the lamps (which seems like
> you may be intending?), then brightness falls with duty cycle.
> And, that you need to keep the "frame" rate high enough that
> the user doesn't see flicker or visual artifacts as it beats
> against the room lighting.

Yep, the framerate (and brightness) should be fine; at least for this
initial testing size.  I mean, let's face it, this is already 64 LED
packages with "just" an 8x8 grid; "testing" with 16x16 (256 LEDs) or
24*24 (576 LEDs) would just be madness :)

>
> (you may discover that a non-sequential refresh sequence helps
> hide visible patterns)
>
>>    2. Requires "Special" tiles to facilitate data flow.  For example, a
>>        chasm in the middle of the room would still need some kind of
>>        carrier PCB to keep the signal flow across / around the chasm
>>        set-piece.  Whereas with the multiplexing, the row/column control
>>        plane (on the carrier-board itself) is otherwise unbroken.
>> 
>> To accomplish #2, I went with some low-profile board-to-board connectors
>> (cue them NOT being rotationally symmetric when I get the 10 or so I
>> ordered :) ) ... I want to keep things relatively low-profile, so the
>> individual boards can survive semi-rough handling (e.g. getting stacked
>> in a case / bin / etc.) that would be problematic with pin-headers.  I
>> envision needing a few revisions here, since eventually I want to do
>> away with the "strips", and replace those with what would amount to
>> individual breakout boards, since the PCBs are otherwise quite big and
>> sparsely populated due to the physical spacing of the game-board.
>
> *If* the 3D "skin" is something that the user can clip on/off the
> "lamps", then you could just put a "no feature" tile atop
> the lamps so that they can't be seen AND program that MCU to keep
> them dark.

Sure, I could do that (maybe).  But I *really* want to avoid making
"special cases" for myself at this point (or, frankly, at any point).
As it stands, if there were a feature that breaks the "standard tile"
for some reason (e.g. a chasm, or collapsed floor, or ... whatever),
it's not going to have any effect on any other LED in the given
row/column.


Maybe someday I'll figure it out (or scrap this approach as subpar, and
revise the whole thing ...)


-- 
|_|O|_|
|_|_|O| Github: https://git.ad8gc.com/ad8gc
|O|O|O| PGP: 51B6 47EA 8D7D B5C8 974D  B0F3 ADE0 4E6E 03E9 745B

On 12/26/2023 10:17 PM, Dan Purgert wrote:
>> Can you, instead, put a small MCU on the "LED boards" and just run power/gnd,
>> and data in/out to each board?  Let boards daisy chain their "out" signal
>> to the neighbor's "in".  That way, you can delegate the control of the
>> lamps to each little MCU as well as limiting the amount of "drive"
>> required on each (this would scale better than a single driver board).
> 
> "maybe" -- but ultimately the issue is going to be drawing an "area" on
> the (in-game) floor where something happened.
> 
> USUALLY this is done either by:
> 
>    (a) counting squares from the "center" of the effect
>    (b) paper/plastic templates held over the "center" of the effect

I'm not advocating for the MCUs to know anything about the game
or "what's (currently) happening".  "Something" drives the array,
knowing where every "feature" is located and how to run any
animations -- by directing the associated MCUs to "do this"
or "do that".

The "something" operates at a higher level of abstraction; it
doesn't deal with individual lamps but, rather, with effects
that it delegates to the MCUs in the "regions of interest".


So (keep in mind, I have no idea of DnD gameplay), if there
was an explosion at (4,2) at time t, it would direct the
MCU *at* (4,2) to run the explosion animation at time t.
The "something" (controller, for want of better word) would
know that the effect will take N time units *in* (4,2) and
then want to "dissipate" into the surrounding tiles at time
t=N.

So, the MCU at (3,2) -- just to the left of the origin of
the explosion -- would be told to run the "explosion off
to your right" animation at t=N.  The MCU at (5,2 would be
told to run "explosion off to your LEFT" at t=N.  The
MCU at (4,3) would be told "explosion above", etc.

The controller would just have to know (algorithmically)
how an effect propagates into adjacent tiles and which
effects it initiates IN those tiles as a result.

The value *you* would add is scripting each of these
effects *in* the specific MCUs AND their "side effects"
in adjacent MCUs (based on board geometry).

The user would just be concerned with defining which
tile is where.  And, "something" would have to decide
how the game was progressing (so it would know which effects
to initiate, and where)

[Again, I am only GUESSING as to how "play" happens.]

>> Note that -- unlike "smart" LEDs -- you don't have to pass a bitmap around
>> but, instead, can send "commands" to each MCU telling each what sort of
>> effect you want *it* to provide for *it's* lamps.
> 
> Which would require that the slave MCU to have a programmable address
> (and then there's the problem of address conflicts), and on top of that,
> there'd need to be a way to convey which slave was at which position of
> the "game board", so that the effects would be done correctly.

No.  Each MCU takes the first N bits of data coming in and
assumes it is intended for *it's* use.  The balance are passed
through to the next MCU "downstream".

As there is only one "downstream" neighbor, each MCU has nothing
to decide -- just pass the balance along.

Scaling "widthwise" just means making longer data streams.
Scaling "heightwise" would mean adding additional serial
streams from the controller.

>>> My two design goals were that:
>>>
>>> 1. These things be easy to use for non-programmers (especially if I
>>> opted to make it into a "product" -- doubt I will, but hey, some people
>>> have more money than time).  Ideally, the only programming it's going to
>>> take is defining the room dimensions (essentially the lower-right
>>> corner, given that 0,0 is the upper-left)
>>>
>>> 2. The tiles be 180-degree rotationally symmetric, to reduce the need
>>> for "single-use" tiles (e.g. wall sections can be either North/South or
>>> East/West, rather than JUST N or JUST E).  Maybe one day I'll figure out
>>> 90 degree symmetry to completely eliminate it.
>>
>> I guess I don't understand how these are further "conditioned".
>> Isn't it just a matrix of indicators?  Do the (3Dprinted?) tiles
>> have additional "character" (e.g., contours, etc.)?
> 
> Yep -- Think of the playing surface as a *VERY* low-resolution display screen:
> there's only a resolution of 1 pixel / inch (and for testing, I'm
> working with a "display" that's all of 8x8 pixels.).  The standard
> playing surface is effectively a large sheet of graph paper, with a
> 1-square / inch grid).  You draw walls and doors and whatever else on
> the board in (wet-erase) marker. The 3d printed tiles are ... well, the
> same idea, just, now it's a bunch of plastic pieces that you can set out
> in whatever order to build up the room to make things more immersive
> for everyone.

So, there are N different *types* of "tiles"?  I.e., one that is
a piece of lake, another that is the side of a mountain, etc.?
And, the plastic is permanently part of the tile?

I.e., so, you could decide which effects can occur in each
type of tile.  E.g., a 'splash' can't occur on dry land;
an explosion dissipates when it runs into a mountain, etc.

>> Photo?
> 
> Here's an example of the 3d-printed tileset.  The room here is comprised
> of nine (9) individual 3d-printed tiles (All are 2x2 playing spaces,
> even though the walls eat half the space, to keep the real-world
> dimensions "correct") : https://www.fatdragongames.com/images/FDG0160AW7.jpg

So, you'd have 36 tri-color LEDs in that same space?
I assume *under* the tile?  So, the floor would have to
be transparent/translucent?

What would you do with 36 lamps in such a room?  Would you
try to indicate the positions of some number of players
(each a different color?) within?  Or, the motion of a
player THROUGH the space?

[I'm trying to get an idea of what the effects would be like,
in terms of complexity]

>>> To accomplish #1; I went with using standard LEDs with multiplexing,
>>> this eliminated two problems I faced with smart/programmable LEDs:
>>>
>>>     1. Data delivery --> while you need 75% fewer control signals for
>>>         "smart" LEDs, things get massively ugly when trying to divide them
>>>         into rows and columns.  You're either zig-zagging the signal on
>>>         every other row; or having a return path on every row, so that
>>>         they all start from the left (right).  Conversely, with
>>>         multiplexing, I just have a grid, with {0,0} being the upper-left
>>>         corner.
>>
>> Keep in mind that if you multiplex the lamps (which seems like
>> you may be intending?), then brightness falls with duty cycle.
>> And, that you need to keep the "frame" rate high enough that
>> the user doesn't see flicker or visual artifacts as it beats
>> against the room lighting.
> 
> Yep, the framerate (and brightness) should be fine; at least for this
> initial testing size.  I mean, let's face it, this is already 64 LED
> packages with "just" an 8x8 grid; "testing" with 16x16 (256 LEDs) or
> 24*24 (576 LEDs) would just be madness :)

How good are your coding skills?  Could you emulate it
on a CRT to get a feel for what it would look like?

>> (you may discover that a non-sequential refresh sequence helps
>> hide visible patterns)
>>
>>>     2. Requires "Special" tiles to facilitate data flow.  For example, a
>>>         chasm in the middle of the room would still need some kind of
>>>         carrier PCB to keep the signal flow across / around the chasm
>>>         set-piece.  Whereas with the multiplexing, the row/column control
>>>         plane (on the carrier-board itself) is otherwise unbroken.
>>>
>>> To accomplish #2, I went with some low-profile board-to-board connectors
>>> (cue them NOT being rotationally symmetric when I get the 10 or so I
>>> ordered :) ) ... I want to keep things relatively low-profile, so the
>>> individual boards can survive semi-rough handling (e.g. getting stacked
>>> in a case / bin / etc.) that would be problematic with pin-headers.  I
>>> envision needing a few revisions here, since eventually I want to do
>>> away with the "strips", and replace those with what would amount to
>>> individual breakout boards, since the PCBs are otherwise quite big and
>>> sparsely populated due to the physical spacing of the game-board.
>>
>> *If* the 3D "skin" is something that the user can clip on/off the
>> "lamps", then you could just put a "no feature" tile atop
>> the lamps so that they can't be seen AND program that MCU to keep
>> them dark.
> 
> Sure, I could do that (maybe).  But I *really* want to avoid making
> "special cases" for myself at this point (or, frankly, at any point).
> As it stands, if there were a feature that breaks the "standard tile"
> for some reason (e.g. a chasm, or collapsed floor, or ... whatever),
> it's not going to have any effect on any other LED in the given
> row/column.

In my scenario, the "gap" would just be an MCU told "do nothing"
(stay dark?) but continue to pass the BALANCE of the data stream
across to your downstream neighbor.

> Maybe someday I'll figure it out (or scrap this approach as subpar, and
> revise the whole thing ...)

Is there a nominal "game board size"?  I.e., could you
standardize on 8x8 "subpanels" -- onto which the
plastic parts could be placed for textural effect?

[A larger "base unit" may afford you more design economies.
You can always tell the unused parts of a subpanel to "stay dark"]

onsdag den 27. december 2023 kl. 07.52.35 UTC+1 skrev Don Y:
> On 12/26/2023 10:17 PM, Dan Purgert wrote: 
> >> Can you, instead, put a small MCU on the "LED boards" and just run power/gnd, 
> >> and data in/out to each board? Let boards daisy chain their "out" signal 
> >> to the neighbor's "in". That way, you can delegate the control of the 
> >> lamps to each little MCU as well as limiting the amount of "drive" 
> >> required on each (this would scale better than a single driver board). 
> > 
> > "maybe" -- but ultimately the issue is going to be drawing an "area" on 
> > the (in-game) floor where something happened. 
> > 
> > USUALLY this is done either by: 
> > 
> > (a) counting squares from the "center" of the effect 
> > (b) paper/plastic templates held over the "center" of the effect
> I'm not advocating for the MCUs to know anything about the game 
> or "what's (currently) happening". "Something" drives the array, 
> knowing where every "feature" is located and how to run any 
> animations -- by directing the associated MCUs to "do this" 
> or "do that". 
> 
> The "something" operates at a higher level of abstraction; it 
> doesn't deal with individual lamps but, rather, with effects 
> that it delegates to the MCUs in the "regions of interest". 
> 
> 
> So (keep in mind, I have no idea of DnD gameplay), if there 
> was an explosion at (4,2) at time t, it would direct the 
> MCU *at* (4,2) to run the explosion animation at time t. 
> The "something" (controller, for want of better word) would 
> know that the effect will take N time units *in* (4,2) and 
> then want to "dissipate" into the surrounding tiles at time 
> t=N. 
> 
> So, the MCU at (3,2) -- just to the left of the origin of 
> the explosion -- would be told to run the "explosion off 
> to your right" animation at t=N. The MCU at (5,2 would be 
> told to run "explosion off to your LEFT" at t=N. The 
> MCU at (4,3) would be told "explosion above", etc. 
> 
> The controller would just have to know (algorithmically) 
> how an effect propagates into adjacent tiles and which 
> effects it initiates IN those tiles as a result. 
> 
> The value *you* would add is scripting each of these 
> effects *in* the specific MCUs AND their "side effects" 
> in adjacent MCUs (based on board geometry). 
> 
> The user would just be concerned with defining which 
> tile is where. And, "something" would have to decide 
> how the game was progressing (so it would know which effects 
> to initiate, and where) 
> 
> [Again, I am only GUESSING as to how "play" happens.]
> >> Note that -- unlike "smart" LEDs -- you don't have to pass a bitmap around 
> >> but, instead, can send "commands" to each MCU telling each what sort of 
> >> effect you want *it* to provide for *it's* lamps. 
> > 
> > Which would require that the slave MCU to have a programmable address 
> > (and then there's the problem of address conflicts), and on top of that, 
> > there'd need to be a way to convey which slave was at which position of 
> > the "game board", so that the effects would be done correctly.
> No. Each MCU takes the first N bits of data coming in and 
> assumes it is intended for *it's* use. The balance are passed 
> through to the next MCU "downstream". 
> 
> As there is only one "downstream" neighbor, each MCU has nothing 
> to decide -- just pass the balance along. 
> 
> Scaling "widthwise" just means making longer data streams. 
> Scaling "heightwise" would mean adding additional serial 
> streams from the controller.

then you are back to having to send the whole bitmap to change 
a single pixel, like smart LEDs ...

though you could use that scheme during initialization to give each node a 
unique address, after which each node will only react to its own address and 
pass along everything else

On 2023-12-27, Don Y wrote:
> On 12/26/2023 10:17 PM, Dan Purgert wrote:
>>> Can you, instead, put a small MCU on the "LED boards" and just run
>>> power/gnd, and data in/out to each board?  Let boards daisy chain
>>> their "out" signal to the neighbor's "in".  That way, you can
>>> delegate the control of the lamps to each little MCU as well as
>>> limiting the amount of "drive" required on each (this would scale
>>> better than a single driver board).
>> 
>> "maybe" -- but ultimately the issue is going to be drawing an "area" on
>> the (in-game) floor where something happened.
>> 
>> USUALLY this is done either by:
>> 
>>    (a) counting squares from the "center" of the effect
>>    (b) paper/plastic templates held over the "center" of the effect
>
> I'm not advocating for the MCUs to know anything about the game
> or "what's (currently) happening".  "Something" drives the array,
> knowing where every "feature" is located and how to run any
> animations -- by directing the associated MCUs to "do this"
> or "do that".
>
> The "something" operates at a higher level of abstraction; it
> doesn't deal with individual lamps but, rather, with effects
> that it delegates to the MCUs in the "regions of interest".
>
>
> So (keep in mind, I have no idea of DnD gameplay), if there
> was an explosion at (4,2) at time t, it would direct the
> MCU *at* (4,2) to run the explosion animation at time t.
> The "something" (controller, for want of better word) would
> know that the effect will take N time units *in* (4,2) and
> then want to "dissipate" into the surrounding tiles at time
> t=N.

Close enough :).  The issue is, now I'm tossing an MCU onto each tile,
to try making them "smarter", and adding complexity to the "master"
board to accommodate selecting which row/column is active.  

It's certainly an option; but on the other hand, "dumb LEDs" where a MCU
can just act as a CPU and push out "turn on 4,2" with a BJT and a shift
register.

>
>>> Note that -- unlike "smart" LEDs -- you don't have to pass a bitmap around
>>> but, instead, can send "commands" to each MCU telling each what sort of
>>> effect you want *it* to provide for *it's* lamps.
>> 
>> Which would require that the slave MCU to have a programmable address
>> (and then there's the problem of address conflicts), and on top of that,
>> there'd need to be a way to convey which slave was at which position of
>> the "game board", so that the effects would be done correctly.
>
> No.  Each MCU takes the first N bits of data coming in and
> assumes it is intended for *it's* use.  The balance are passed
> through to the next MCU "downstream".
>
> As there is only one "downstream" neighbor, each MCU has nothing
> to decide -- just pass the balance along.
>
> Scaling "widthwise" just means making longer data streams.
> Scaling "heightwise" would mean adding additional serial
> streams from the controller.

Ah, so "sorta" like the idea behind the WS2812 driver chips, but using a
selector switch (for example) to enable the data to "Row N" 

>
>>>> My two design goals were that:
>>>>
>>>> 1. These things be easy to use for non-programmers (especially if I
>>>> opted to make it into a "product" -- doubt I will, but hey, some people
>>>> have more money than time).  Ideally, the only programming it's going to
>>>> take is defining the room dimensions (essentially the lower-right
>>>> corner, given that 0,0 is the upper-left)
>>>>
>>>> 2. The tiles be 180-degree rotationally symmetric, to reduce the need
>>>> for "single-use" tiles (e.g. wall sections can be either North/South or
>>>> East/West, rather than JUST N or JUST E).  Maybe one day I'll figure out
>>>> 90 degree symmetry to completely eliminate it.
>>>
>>> I guess I don't understand how these are further "conditioned".
>>> Isn't it just a matrix of indicators?  Do the (3Dprinted?) tiles
>>> have additional "character" (e.g., contours, etc.)?
>> 
>> Yep -- Think of the playing surface as a *VERY* low-resolution
>> display screen: there's only a resolution of 1 pixel / inch (and for
>> testing, I'm working with a "display" that's all of 8x8 pixels.).
>> The standard playing surface is effectively a large sheet of graph
>> paper, with a 1-square / inch grid).  You draw walls and doors and
>> whatever else on the board in (wet-erase) marker. The 3d printed
>> tiles are ... well, the same idea, just, now it's a bunch of plastic
>> pieces that you can set out in whatever order to build up the room to
>> make things more immersive for everyone.
>
> So, there are N different *types* of "tiles"?  I.e., one that is
> a piece of lake, another that is the side of a mountain, etc.?
> And, the plastic is permanently part of the tile?

Yeah, *MOST* of them are quite likely "floor style, variant X" (e.g. a
"dungeon" set may have 4 "open floor" variants -- "empty" [just four 
flagstones], "some rubble" in a space, or perhaps something like "trap
door" or "collapsed floor").  Then there's also the "border" pieces with
walls (and doors, etc).

>
> I.e., so, you could decide which effects can occur in each
> type of tile.  E.g., a 'splash' can't occur on dry land;
> an explosion dissipates when it runs into a mountain, etc.

"Sort of" but at the present time, I'm not planning anything quite so
complex as to know what the floor features are.
>
>>> Photo?
>> 
>> Here's an example of the 3d-printed tileset.  The room here is comprised
>> of nine (9) individual 3d-printed tiles (All are 2x2 playing spaces,
>> even though the walls eat half the space, to keep the real-world
>> dimensions "correct") : https://www.fatdragongames.com/images/FDG0160AW7.jpg
>
> So, you'd have 36 tri-color LEDs in that same space?
> I assume *under* the tile?  So, the floor would have to
> be transparent/translucent?

Yep, or a little hole in the space where a player piece would be
standing.  PROBABLY a hole, since painting the tiles wouldn't become
problematic (I mean, let's face it, 3D-Printers are entirely uniform
colors, and while that's perfectly fine for a testing phase ... )

>
> What would you do with 36 lamps in such a room?  Would you
> try to indicate the positions of some number of players
> (each a different color?) within?  Or, the motion of a
> player THROUGH the space?

No.  Taking that little room shown in the picture there, maybe the
players set off some kind of trap from the door in the "north" wall that
sprayed fire at them when they tried opening it.  

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.


> [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)

>
>>>> To accomplish #1; I went with using standard LEDs with multiplexing,
>>>> this eliminated two problems I faced with smart/programmable LEDs:
>>>>
>>>>     1. Data delivery --> while you need 75% fewer control signals for
>>>>         "smart" LEDs, things get massively ugly when trying to divide them
>>>>         into rows and columns.  You're either zig-zagging the signal on
>>>>         every other row; or having a return path on every row, so that
>>>>         they all start from the left (right).  Conversely, with
>>>>         multiplexing, I just have a grid, with {0,0} being the upper-left
>>>>         corner.
>>>
>>> Keep in mind that if you multiplex the lamps (which seems like
>>> you may be intending?), then brightness falls with duty cycle.
>>> And, that you need to keep the "frame" rate high enough that
>>> the user doesn't see flicker or visual artifacts as it beats
>>> against the room lighting.
>> 
>> Yep, the framerate (and brightness) should be fine; at least for this
>> initial testing size.  I mean, let's face it, this is already 64 LED
>> packages with "just" an 8x8 grid; "testing" with 16x16 (256 LEDs) or
>> 24*24 (576 LEDs) would just be madness :)
>
> How good are your coding skills?  Could you emulate it
> on a CRT to get a feel for what it would look like?

good enough, but I don't have a CRT to hand.  I've done it small-scale
with protoboard and 64 (white) LEDs, and it came out well enough.  Plan
for the week is to drop by the hardware store and pick up one of those
12x12 project panels (assuming I don't have any suitable plywood hanging
out around the house already) and put some LEDs on a big grid.  
>
>>> (you may discover that a non-sequential refresh sequence helps
>>> hide visible patterns)
>>>
>>>>     2. Requires "Special" tiles to facilitate data flow.  For example, a
>>>>         chasm in the middle of the room would still need some kind of
>>>>         carrier PCB to keep the signal flow across / around the chasm
>>>>         set-piece.  Whereas with the multiplexing, the row/column control
>>>>         plane (on the carrier-board itself) is otherwise unbroken.
>>>>
>>>> To accomplish #2, I went with some low-profile board-to-board connectors
>>>> (cue them NOT being rotationally symmetric when I get the 10 or so I
>>>> ordered :) ) ... I want to keep things relatively low-profile, so the
>>>> individual boards can survive semi-rough handling (e.g. getting stacked
>>>> in a case / bin / etc.) that would be problematic with pin-headers.  I
>>>> envision needing a few revisions here, since eventually I want to do
>>>> away with the "strips", and replace those with what would amount to
>>>> individual breakout boards, since the PCBs are otherwise quite big and
>>>> sparsely populated due to the physical spacing of the game-board.
>>>
>>> *If* the 3D "skin" is something that the user can clip on/off the
>>> "lamps", then you could just put a "no feature" tile atop
>>> the lamps so that they can't be seen AND program that MCU to keep
>>> them dark.
>> 
>> Sure, I could do that (maybe).  But I *really* want to avoid making
>> "special cases" for myself at this point (or, frankly, at any point).
>> As it stands, if there were a feature that breaks the "standard tile"
>> for some reason (e.g. a chasm, or collapsed floor, or ... whatever),
>> it's not going to have any effect on any other LED in the given
>> row/column.
>
> In my scenario, the "gap" would just be an MCU told "do nothing"
> (stay dark?) but continue to pass the BALANCE of the data stream
> across to your downstream neighbor.

Yeah, but the thing you're not accounting for is that a "Ruined Floor"
piece isn't the "standard(tm)" nominal 2" square -- rather, it'll have a
missing corner (or more) so that there's a visual hole in the floor.  So
I'd need a special PCB for that piece (or any similar piece that "breaks
through" the plane of the floor.

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

>> Maybe someday I'll figure it out (or scrap this approach as subpar, and
>> revise the whole thing ...)
>
> Is there a nominal "game board size"?  I.e., could you
> standardize on 8x8 "subpanels" -- onto which the
> plastic parts could be placed for textural effect?

FOR NOW, it's 4x4 tiles (64 LEDs), because that fits really well into
two bytes, and I can keep it all in my head.  EVENTUALLY I want to
accommodate 8x8 tiles (256 LEDs) ...  

-- 
|_|O|_|
|_|_|O| Github: https://git.ad8gc.com/ad8gc
|O|O|O| PGP: 51B6 47EA 8D7D B5C8 974D  B0F3 ADE0 4E6E 03E9 745B

On Wednesday, December 27, 2023 at 1:59:26 PM UTC+11, a a wrote:
> Dan Purgert <d...@djph.net> wrote: 
> The arsehole Dan Purgert <d...@djph.net> persisting in being an Off-topic troll..

The half-wit "a a" doesn't know enough to realise that Dan Purget was being entirely on-topic.

It isn't ostentatiously high-tech electronics, but it is the kind of electronics that some of us make money out of. and similar sorts of questions have been showing up here for years now, and nobody else has bothered to complain about them.

-- 
Bill Sloman, Sydney

On 12/27/2023 6:31 AM, Lasse Langwadt Christensen wrote:
> onsdag den 27. december 2023 kl. 07.52.35 UTC+1 skrev Don Y:
>> On 12/26/2023 10:17 PM, Dan Purgert wrote:
>>>> Can you, instead, put a small MCU on the "LED boards" and just run power/gnd,
>>>> and data in/out to each board? Let boards daisy chain their "out" signal
>>>> to the neighbor's "in". That way, you can delegate the control of the
>>>> lamps to each little MCU as well as limiting the amount of "drive"
>>>> required on each (this would scale better than a single driver board).
>>>
>>> "maybe" -- but ultimately the issue is going to be drawing an "area" on
>>> the (in-game) floor where something happened.
>>>
>>> USUALLY this is done either by:
>>>
>>> (a) counting squares from the "center" of the effect
>>> (b) paper/plastic templates held over the "center" of the effect
>> I'm not advocating for the MCUs to know anything about the game
>> or "what's (currently) happening". "Something" drives the array,
>> knowing where every "feature" is located and how to run any
>> animations -- by directing the associated MCUs to "do this"
>> or "do that".
>>
>> The "something" operates at a higher level of abstraction; it
>> doesn't deal with individual lamps but, rather, with effects
>> that it delegates to the MCUs in the "regions of interest".
>>
>>
>> So (keep in mind, I have no idea of DnD gameplay), if there
>> was an explosion at (4,2) at time t, it would direct the
>> MCU *at* (4,2) to run the explosion animation at time t.
>> The "something" (controller, for want of better word) would
>> know that the effect will take N time units *in* (4,2) and
>> then want to "dissipate" into the surrounding tiles at time
>> t=N.
>>
>> So, the MCU at (3,2) -- just to the left of the origin of
>> the explosion -- would be told to run the "explosion off
>> to your right" animation at t=N. The MCU at (5,2 would be
>> told to run "explosion off to your LEFT" at t=N. The
>> MCU at (4,3) would be told "explosion above", etc.
>>
>> The controller would just have to know (algorithmically)
>> how an effect propagates into adjacent tiles and which
>> effects it initiates IN those tiles as a result.
>>
>> The value *you* would add is scripting each of these
>> effects *in* the specific MCUs AND their "side effects"
>> in adjacent MCUs (based on board geometry).
>>
>> The user would just be concerned with defining which
>> tile is where. And, "something" would have to decide
>> how the game was progressing (so it would know which effects
>> to initiate, and where)
>>
>> [Again, I am only GUESSING as to how "play" happens.]
>>>> Note that -- unlike "smart" LEDs -- you don't have to pass a bitmap around
>>>> but, instead, can send "commands" to each MCU telling each what sort of
>>>> effect you want *it* to provide for *it's* lamps.
>>>
>>> Which would require that the slave MCU to have a programmable address
>>> (and then there's the problem of address conflicts), and on top of that,
>>> there'd need to be a way to convey which slave was at which position of
>>> the "game board", so that the effects would be done correctly.
>> No. Each MCU takes the first N bits of data coming in and
>> assumes it is intended for *it's* use. The balance are passed
>> through to the next MCU "downstream".
>>
>> As there is only one "downstream" neighbor, each MCU has nothing
>> to decide -- just pass the balance along.
>>
>> Scaling "widthwise" just means making longer data streams.
>> Scaling "heightwise" would mean adding additional serial
>> streams from the controller.
> 
> then you are back to having to send the whole bitmap to change
> a single pixel, like smart LEDs ...

No.  "You" wouldn't change a "single pixel"; the *effect*,
running *in* one of the MCUs (having already been told
"run this effect") would know which pixel to change, and when.
I.e., the animation can run FASTER than the data rate because
you encode the animation (effect) in the datum that was delivered
to THAT MCU.

> though you could use that scheme during initialization to give each node a
> unique address, after which each node will only react to its own address and
> pass along everything else

Then your protocol needs to carry an address for each datum.
I.e., the stuff "passed along" would also include at least one OTHER
address to inform "whoever" for whom it is intended.

onsdag den 27. december 2023 kl. 17.33.29 UTC+1 skrev Don Y:
> On 12/27/2023 6:31 AM, Lasse Langwadt Christensen wrote: 
> > onsdag den 27. december 2023 kl. 07.52.35 UTC+1 skrev Don Y: 
> >> On 12/26/2023 10:17 PM, Dan Purgert wrote: 
> >>>> Can you, instead, put a small MCU on the "LED boards" and just run power/gnd, 
> >>>> and data in/out to each board? Let boards daisy chain their "out" signal 
> >>>> to the neighbor's "in". That way, you can delegate the control of the 
> >>>> lamps to each little MCU as well as limiting the amount of "drive" 
> >>>> required on each (this would scale better than a single driver board). 
> >>> 
> >>> "maybe" -- but ultimately the issue is going to be drawing an "area" on 
> >>> the (in-game) floor where something happened. 
> >>> 
> >>> USUALLY this is done either by: 
> >>> 
> >>> (a) counting squares from the "center" of the effect 
> >>> (b) paper/plastic templates held over the "center" of the effect 
> >> I'm not advocating for the MCUs to know anything about the game 
> >> or "what's (currently) happening". "Something" drives the array, 
> >> knowing where every "feature" is located and how to run any 
> >> animations -- by directing the associated MCUs to "do this" 
> >> or "do that". 
> >> 
> >> The "something" operates at a higher level of abstraction; it 
> >> doesn't deal with individual lamps but, rather, with effects 
> >> that it delegates to the MCUs in the "regions of interest". 
> >> 
> >> 
> >> So (keep in mind, I have no idea of DnD gameplay), if there 
> >> was an explosion at (4,2) at time t, it would direct the 
> >> MCU *at* (4,2) to run the explosion animation at time t. 
> >> The "something" (controller, for want of better word) would 
> >> know that the effect will take N time units *in* (4,2) and 
> >> then want to "dissipate" into the surrounding tiles at time 
> >> t=N. 
> >> 
> >> So, the MCU at (3,2) -- just to the left of the origin of 
> >> the explosion -- would be told to run the "explosion off 
> >> to your right" animation at t=N. The MCU at (5,2 would be 
> >> told to run "explosion off to your LEFT" at t=N. The 
> >> MCU at (4,3) would be told "explosion above", etc. 
> >> 
> >> The controller would just have to know (algorithmically) 
> >> how an effect propagates into adjacent tiles and which 
> >> effects it initiates IN those tiles as a result. 
> >> 
> >> The value *you* would add is scripting each of these 
> >> effects *in* the specific MCUs AND their "side effects" 
> >> in adjacent MCUs (based on board geometry). 
> >> 
> >> The user would just be concerned with defining which 
> >> tile is where. And, "something" would have to decide 
> >> how the game was progressing (so it would know which effects 
> >> to initiate, and where) 
> >> 
> >> [Again, I am only GUESSING as to how "play" happens.] 
> >>>> Note that -- unlike "smart" LEDs -- you don't have to pass a bitmap around 
> >>>> but, instead, can send "commands" to each MCU telling each what sort of 
> >>>> effect you want *it* to provide for *it's* lamps. 
> >>> 
> >>> Which would require that the slave MCU to have a programmable address 
> >>> (and then there's the problem of address conflicts), and on top of that, 
> >>> there'd need to be a way to convey which slave was at which position of 
> >>> the "game board", so that the effects would be done correctly. 
> >> No. Each MCU takes the first N bits of data coming in and 
> >> assumes it is intended for *it's* use. The balance are passed 
> >> through to the next MCU "downstream". 
> >> 
> >> As there is only one "downstream" neighbor, each MCU has nothing 
> >> to decide -- just pass the balance along. 
> >> 
> >> Scaling "widthwise" just means making longer data streams. 
> >> Scaling "heightwise" would mean adding additional serial 
> >> streams from the controller. 
> > 
> > then you are back to having to send the whole bitmap to change 
> > a single pixel, like smart LEDs ...
> No. "You" wouldn't change a "single pixel"; the *effect*, 
> running *in* one of the MCUs (having already been told 
> "run this effect") would know which pixel to change, and when. 
> I.e., the animation can run FASTER than the data rate because 
> you encode the animation (effect) in the datum that was delivered 
> to THAT MCU.

but you still have to send stream as long as the number of mcus, you can't just send single a command addressed 
to a specific one