Archive: 15 posts

---

So, I decided to try my hand at a Conway's Game of Life (http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life) implementation in LBP. It's been done before (the implementation I found does a 6x6 grid and has a nice mechanical solution to clocking the updates to game state) but I wanted to see if I could do better. My implementation attempt uses the same basic "adder" - eight pistons in series connected to the magnetic sensors for the neighboring cells. When the "adder" adds to three, a magnetic sensor on the end of the adder detects a corresponding magnet - which in turn drives an emitter which continuously emits magnets in another location. Then there's the "clock" mechanism - this thing needs to update at the proper intervals, and the interval needs to be great enough that a momentary crossing of the "live" condition in between turns doesn't erroneously make the cell live. My first implementation used an emitter on each cell for this - the emitter emits (every half second) a piece of dark matter with a magnetic sensor attached to another emitter - if the sensor detects the magnet that's emitted by the adder stage, then it will emit a "live cell" object which will last for a half second. The "live cell" object has a yellow magnet, which is used by neighboring cells the recognize that the cell is alive - and also a green magnet placed such that the adder will, as long as the cell is "live", continue to emit the "live" state even if the adder result changes from three to two. The second version used a different timing mechanism to synchronize updates to the cell - I used a wobble bolt on the sensor that controls the "live cell" emitter. This version actually seemed to do worse than the emitter version, though. I built each cell as a self-contained thing, and my goal was to make a grid of these at least 8x8 (I had been hoping for 10x10, actually, but even 8x8 has been a real problem.) I've been trying to simplify the shapes and such to make the thermometer god happy, even merged groups of cells together so they wouldn't have distinct boundaries - but generally by the time I reach 56 cells the level overheats. And all this without supplying the logic which would, for instance, let the player specify an initial state for the machine... So I don't really know if I'll continue with this. There's a few more optimizations I may try, but I don't know if it's worth it if I can't get a bigger grid than the already-existing implementation...

2009-05-13 19:46:00 Author: tetsujin Posts: 187

---

I remember reading about this a few years ago. It would be very interesting to see what happens in LBP. Good luck, and send me a message when you get it up.

2009-05-13 21:21:00 Author: Killian Posts: 2575

---

Very quick response so sorry if this is little help, but have you: a) optimised the logic on the side and corner cells to limit their behaviour b) tried to come at it from a completely different angle. In most design problems like this, starting with someone else's design is normally a bad idea, as you have put yourself in their mindset and it makes it harder to do better than them.

2009-05-13 21:47:00 Author: rtm223 Posts: 6497

---

Very quick response so sorry if this is little help, but have you: a) optimised the logic on the side and corner cells to limit their behaviour b) tried to come at it from a completely different angle. Well, the grid's going to wrap around - so there's not much optimization to be had at the edges of the grid. (I feel like an 8x8 grid is kind of small for a Conway game that doesn't wrap around... At least if it wraps around I can have a glider go on its merry way. Early on I entertained notions of having a glider gun running - which would make a non-wrapping board preferable - but it seems like with my current approach I can't fit nearly enough cells to have a glider gun, so a wrap-around board seems preferable. Thus, no edge optimizations... One optimization I've missed so far, however: currently each cell is self-contained, built such that a bunch of cells can simply be placed next to each other in the correct arrangement to form the board. This means each cell has eight magnetic sensors to detect the state of its neighbors, plus one to detect its own state for output to the light board. I don't know if mag sensors are eating up a large portion of my thermometer (I figure it's the adder that's doing most of that, really) but I realized today that if I'm willing to do some wiring after placing the cells, I can have one (maybe two, for directional and on/off outputs) mag sensors on each cell to detect its own state, and then wire it up to all the adders that need to monitor that cell's state... Coming at it from a completely different angle - not yet. The current approach is, so far, my best design. I introduced the wobble-bolt version in the hope that the engine would like that better than the emitter-emitter method of synchronizing state updates - but I actually had better results with the earlier version. In most design problems like this, starting with someone else's design is normally a bad idea, as you have put yourself in their mindset and it makes it harder to do better than them. Well, I didn't really draw from the existing design. I started the design before I knew the older implementation existed, then I did the search 'cause I was curious to see what other people had been done. I was a little disappointed that the existing one was just a 6x6 grid, and thought I could do better with mine. (I'm pretty sure I could manage 7x7 or even 7x8 with my current version, in fact...) Also initially I thought the mechanical parts of that version were wasteful - but now I think they might actually be more efficient than my emitter-emitter rig for updating state. Plus the engine has a tendency to stop running emitters when things get hot - this could be problematic if my implementation winds up borderline... I haven't really studied the existing design beyond a cursory look, enough to understand how it clocks state updates. I'm not sure, but I think that the adder in each cell is what's taking up most of the thermo - the adder is eight pistons, eight glass boxes, and a hollow rectangle cut out of the dark matter "cell" to contain it. Presently the pistons are horizontal, which requires that the whole adder be enclosed in order to work reliably - probably I should try it vertically: that could work with fewer vertices, since I could rely on gravity to keep the chain of pistons lined up - but the advantages in terms of reduced vertex count would mostly disappear if I started stitching cells together horizontally... I'm going to try a few optimizations, I guess, and see what happens. I still think the adder is the main thing, though - so far I haven't come up with a better adder design than what I've got...

2009-05-13 23:22:00 Author: tetsujin Posts: 187

---

I don't think you're going to get much out of less mag switches, and vertices are apparently less significant after yarg. Before attempting that optimisation you should run a quick check on ~50 adders horizontal and vertical. I think you are right about the adder, I have been trying to think of an alternative to an explicit adding machine, based on the concept detecting <2, 2, 3 or >3. I thought this was a dead end, but I have just com up with the concept of: a rotating sensor in the cell* so that each live neighbour contributes time to a directional piston, the length of which would indicate the added value when sampled at the end. The adder could then be made out of 1 piece of dark matter, 1 moving part with one piston, with 2 chains for reset logic. Your refresh time is going to be slow, but it could save a lot of thermo - those series chains are horrible for thermo munching. Does this sound plausible to you, it's late here, so I don't know what is or isn't sensible... *This is going to mess up with wrap anyway. OK, now it's morning and I've had some coffee, To explain: Use a wobble bolt to control the sensor. This wobble should have a rotation of 359 degrees and be set to flipper. Possibly 360 degrees if wobble bolts work properly with 360 and flipper. Timing on the wobble will likely be 0.8s. Sensing: At time 0: 1-shot input goes to the wobble bolt At time 0 - 0.8s the sensor gives a +1 for active neighbours, -1 for each inactive neighbour. At time 0.8, a 1shot signal is sent to a sampling device, which will sample the count. The sampler will then activate the emmitter for the cell, or not. Probably this will use a 1-shot also At time 0.9, the two chains will activate, to pull the adder back to the centre point of the adder's movement. At time 1.0, the sensing repeats Time this using an emmitter with lifetime 0.8, period 1.0 and effectively triggering the sample from the rising edge and sampling from falling edge. Reset logic can be delayed by 0.1s either implicitly or explicitly. For the wrap around, you can create dummy cells on the opposite side of of the grid. These can be hidden behind a thin layer. My tests with emmitters emmitting dark matter show they aren't as thermo heavy as people whoud have you believe, so this shouldn't have too much of an impact, and the thermo you save from not having so many pistons should make it ok.

2009-05-14 00:52:00 Author: rtm223 Posts: 6497

---

Actually, reducing the number of mag switches does seem to have helped considerably... I ran some tests: 64 adders filled up the thermo half-way 64 panels of 8 directional mag switches each filled up the thermo half-way 64 panels of 1 omnidirectional mag switch each filled up the thermo less - maybe a quarter of the way. I reworked the Conway Cell I've been working with so each just has two mag sensors, three emitters, and the adder, then I've been building progressively larger blocks of multiple cells pre-wired in the correct configuration... I actually made an 8x7 grid of these modified cells, wired for wrap-around, but I hit an unfortunate snag: my bootstrap object that I used to set the initial state of the board (a piece of mag-activated dissolve with magnets on it) was setting the cell "active" but it wasn't also setting the cell to "continue to live if the number of live neighbors is 2" - so simple patterns like the 3x1 alternator would fizzle out in two generations. I created a new bootstrap object which doesn't set the cell live until it's been clocked - but still lights the cell's light for feedback... I tried manually resetting the bootstrap emitters on all 56 cells (that beat breaking down the grid and having to rewire the whole thing again) but when I was done, the "update" emitters stopped working, so the whole grid was useless... I'm trying again with this new design - I've tested a 4x4 grid of the new cells and it does work - probably tonight I'll expand the grid to 8x4 and then 8x7 and see if I can get the whole thing working. I'm going to settle for 8x7 for now, maybe try for 8x8 once I get that working. So I'm pretty sure reducing the number of mag switches did help - I got to 8x7, and it worked apart from that bug in the bootstrap. I think it'll work correctly once I build a new grid... I'd gotten to 8x7 with the eight-sensor design without overheating, but I was perilously close - and this was for cells without the ability to bootstrap and without a lightboard to show the status. I've been trying to think of different approaches, too: Paint switch-based adder: seems like a promising approach since it's basically the game's built-in version of an adder. Multiple paint switches can be put on an object to detect different numbers of paint hits, and then emitters can send paint at it according to how many neighbors are lit... It could even work with a wobble-bolt sensor like you described, to "scan" the neighbors (as long as it can somehow avoid detecting the cell's own state as if it were a "neighbor") - the trick would be to set the cell's state if the "3" (or "2", if it's present) paint sensor gets triggered but then revoke that state change if the count goes up to "4" - and revoke it before it causes a neighbor to emit paint. Some kind of two-stage emitter system, maybe, so that the paint sensor generates a "stage one" state and then a synchronized emitter emits a sensor-controlled-emitter than generates the "stage two" state if the "stage one" state is present. (This is how I handle the output of my current piston adder, actually...) Scanning Update: The idea is to put all the cell update logic on a pair of scan rows: the first update row contains the adders for all columns and detects game state (stage 2) for the cell and all its neighbors as input into the adder - if the adder condition is satisfied then it emits "stage 1" game state for the cell. The second update row (at least two board rows separated from the first update row) detects "stage 1" game state and emits "stage 2" game state. It also contains a magnet which causes previous "stage 2" state markers to dissolve. The update procedure via this method would be a lot slower (probably several seconds per update), since it needs to scan all rows and be at each one long enough to get a good output from the adders, but because it only needs one row worth of machinery instead of adder/emitter machinery for the entire grid, I think it could handle much larger grids. Vertical wrap-around would be a minor issue to solve, but since this approach might be sufficient to implement a glider gun, maybe one wouldn't want wrap-around anyway...

2009-05-14 19:05:00 Author: tetsujin Posts: 187

---

I took another crack at doing the 8x7 grid with my current cell design (piston-based adder, emitters for timing, etc.) and I was able to complete the level without overheating. Initially when I wired the thing up, though, I was having all kinds of reliability issues. Cells would either be born or stay alive when they shouldn't or die when they shouldn't... I made various changes to address this: 1: When the adder determines that the cell should be alive on the next turn, it emits a green magnet - the "stage 1" state... It emits this continuously as long as the adder condition is satisfied, since it doesn't know exactly when the next turn update will occur. I had set these to 0.2 seconds duration due to something I had been attempting earlier on - but I figured these might be making incorrect results stay active beyond the per-turn time allowance for the adder to settle down, so I changed it to 0.1. 2: The magnet switch that the adder uses to detect whether the cell should be alie on the next turn was set to 27 degrees - I decided to tighten this up to 20 degrees 3: Since the tolerance on the magnet switch was tightened up, I had to adjust the piston length, too - each cell needed one piston changed from 1.0/0.1 to 1.2/0.3 so that it would line up with the target better. Beyond that the one other difficulty I had was that, mysteriously, some cells wound up having one piston that got set to some funky value like 0.4/-0.7 - I don't know how that happened (all the cells were cloned from the master copy) Now it runs very reliably: I had it running two gliders simultaneously for probably about 60 iterations before I turned it off. (This is quite a relief - for a while there I thought the reliability issues I was seeing were an inherent flaw in the design...) Once I add some instruction and such I'm going to publish it. Maybe one of these days I'll try doing a version with a paint-based counter...

2009-05-15 07:08:00 Author: tetsujin Posts: 187

---

Absolutely fascinating. I can't wait to see this in action.

2009-05-15 08:06:00 Author: Jaeyden Posts: 564

---

Brilliant. Glad you got it working. I don't know if the paint-based counter is going to work though, surely you would need upper and lower bounds counting, with a lower bound variable? I'm sure you have a plan. I did think of method of doing away with adding (kind of), whereby you use piston and chain strengths to create an upper and lower bounds comparitor, and then the comparitor outputs are made into an AND gate giving an "alive at next iteration" signal, switching in 0.1s. You can even make the lower bound comparitor variable threshold. If you add a sampler to it, the whole logic for each cell has only 3 moving parts for complete sensing to clocked output. 3 moving parts, but 20 (maybe 21?) connectors, and lots of highly confusing wiring! Make sure you post something when you get it online, this should be quite a treat!

2009-05-15 08:49:00 Author: rtm223 Posts: 6497

---

It's online. I think the level name I used was "Conway's Life Simulation" (I thought this name might help scare away people who aren't interested in LBP-implementations of classic computer programs...) For some reason, though, one of my magic mouth bubbles is coming out all asterisks... Don't know what that's about. All it said was "This is a computer running Conway's game of life simulation." I guess the thing still has some issues - After I published the thing I ran the LWSS ("Lightweight space ship") and after several iterations it blew up... Kind of a drag, I thought I really had it working right... I think my 0.5 second update speed is just too fast for the pistons to settle reliably. But to change that I'd need to rebuild the whole machine... In retrospect, it was a mistake to try to make the cell as small as I did. It probably would have been a lot more reliable if it were larger... The idea for the paint-counter is that it would work something like this: when it's time to update the game state, the Conway Cell emits a counter object - this consists of a block of dark matter with two paint switches on it, plus eight sensors and eight emitters The sensors on the counter object are one-shots that detect the state of the neighbors and emit one paintball for each live neighbor. (alternately, each cell could take responsibility for sending paintballs to its neighbors - but that would mean that the paintballs would have to be emitted with zero velocity, since any non-zero initial velocity for an emitted object must be in the direction from the emitter to the emitted object...) The two paint switches are the low count and the high count: if the low count is reached it will one-shot emit a "cell state" - a block of dissolve (glued to dark matter) with a magnet on it and a magnet sensor controlling the dissolve. If the high count is reached it will one-shot emit a "cell state cancel" - a piece of dark matter with a magnet on it - this magnet will trigger the dissolve. Probably if a cell dies from overcrowding all 4+ paintballs would land at the same time on the sensor - the dissolve would be emitted at the same time as the canceller, and so the dissolve would pretty much instantly dissolve. The low count would normally be set to 3 - but if the cell is active when it's updated, an alternate version of the counter will be emitted in which the low count is 2. The two different emitters for different versions of the updater could be selected by a wobble bolt with two mag sensors on it - the cell would read its own state to control the direction of the wobble bolt. I think this kind of system would be a lot more reliable than the piston-type adders - but I'm not sure what the overall cost would be of all those emitters and sensors...

2009-05-15 09:35:00 Author: tetsujin Posts: 187

---

I forgot all about Conway's Game, I remember programming a version in class a few semesters ago now. I thought it was kind of neat than, and a big LBP implementation would be awesome.

2009-05-15 09:36:00 Author: Walter-Kovacs Posts: 542

---

I only just saw the update tetsujin. I'll check out the level tonight. I don't think the paintball machine is going to get you anywere. Emmitter thermo is essentially based upon the item that is emmitted and the maximum number at once and you are emmitting a lot of stuff and then doubling the paintswitch logic and adding a selector. Sounds heavy. I still think the adder from my previous post would be quite light on thermo, previous tests with lots of connectors on a single moving object have shown it's not as thermo heavy as you might think. It's just a wiring nightmare.

2009-05-18 17:33:00 Author: rtm223 Posts: 6497

---

I only just saw the update tetsujin. I'll check out the level tonight. I don't think the paintball machine is going to get you anywhere. Emmitter thermo is essentially based upon the item that is emitted and the maximum number at once and you are emitting a lot of stuff and then doubling the paintswitch logic and adding a selector. Sounds heavy. Well, nevertheless I think that'll be my next attempt. Letting the game itself do the counting at least promises to make things a lot more reliable. As for thermo - I agree the use of emitters (especially one per "neighbor", emitting moving objects requiring physical simulation, as opposed to dark matter) does sound costly - but I don't really know what it'll cost until I try it, at least as a non-functional mock-up. I think my adders are taking half the thermo, currently - so it's a good place to look for optimizations.

2009-05-18 18:15:00 Author: tetsujin Posts: 187

---

Good to see you're not giving up at any rate I would be giving this a go myself to see what I can come up to help but I really don't have the time atm

2009-05-18 18:37:00 Author: rtm223 Posts: 6497

---

Good to see you're not giving up at any rate Not giving up, but I am taking a break. I wired up this beastie probably three or four times due to various failed attempts or malfunctions... Even when copy/pasting pre-wired blocks to create bigger grids, it does take a while to wire up the 448 cross-cell connections. And one of these days I do want to make a level that people will enjoy playing 'cause it's fun, rather than just a giant tech demo.

2009-05-18 18:50:00 Author: tetsujin Posts: 187

Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.