avatar Log in

Forum - Realities vs "the spec"

From The Great Ball Contraption Wiki
Overview > Great Ball Contraption > Great Ball Contraption Discussion > Realities vs "the spec" Write a reply

Tom Atkinson and I had an interesting back & forth about realities of running a successful GBC vs "the spec" at Brickworld Indy. One of the things that started it was the tables that were provided were not all that great, and definitely weren't all the same height. This meant there were some modules that were working slightly uphill, or some that didn't quite lift the balls high enough for the next module because it was sitting on a slightly higher surface. Tom suggested that the tables should be better. In addition, the terrycloth that Tom provides to keep balls from bouncing & rolling so much (a definite plus) sometimes causes problems with some modules. Perfect tables would be nice, but ultimately that is out of our control unless we provide them. And the terrycloth provides too many benefits to get rid of. My solution was that all builders should try to make their modules EXCEED rather than just meet "the spec".

In the most basic terms, the spec says 1 ball/sec, input at 10 bricks high, output to 10 bricks high. Simple enough. But in reality, for a large GBC, I think most builders should try to make their modules so the input is lower, and the output is higher. I always try to make my modules so they output at least a brick or so higher, many of mine are capable of more than that. On the input side, I tend to be at or right below 10 bricks. Also on the input side, while technically there isn't anything that says the floor of the input can't be really shallow, it doesn't always work well if the upstream module deposits balls with any momentum-- they tend to bounce out. So I try to have at least an input a couple bricks deep. This leaves the throughput spec of 1 ball/sec. I have several modules that can easily exceed that. However, sometimes this means during a show they have periods where they run dry more often than if they were slower or they look like they are empty because at 1 ball/sec they are less than 1/2 full. I'm not sure that is optimal from a display standpoint.

I'd be interested to hear any other perspectives on this. Perhaps this would be a good topic for a roundtable at Brickworld Chicago. Meeting the spec vs having a successful module that works well in a GBC display.



Posted by on 24 March 2015 at 14:59.

I completely agree with all your points.

I used to think that if 1 bps (ball per second) rate is good, 2 bps is better. The reality is that if my 2 bps module receives a flood of balls (as happens after a jam is cleared), I'm going to flood the next module down and it's going to jam. Plus it means, as John pointed out, that I'm going to run dry at least half the time. So it turns out sending more than 1 bps is actually bad for the GBC.

It would not violate the spec to have an in basket of zero depth. Most of the Philo-type wave modules are like this. Neither would it violate the spec to have an output that completely covers an input basket. Put the two together and there's a problem. So like John I would put the onus on the input basket to have a minimum depth. 16 mm (two studs) would be the minimum to alleviate the above case.

Deeper in baskets of course reduce the amount of balls rejected. One of the most common reasons I've seen for having to re-sequence modules in a GBC is that one module is throwing balls harder than the next module can handle them. As often as not it is because balls are bouncing forward out of the module rather than out the sides, and the depth of the input basket isn't the issue so much as the height of its far wall above the in basket floor (which may slope downward or vary over time). I wonder if we should cap the momentum of incoming balls? If so, we need to state it in a way that is easily testable. Perhaps create a test in basket and have the module output 30 balls into it and see how many it rejects. Something like one that is 10 bricks tall on the left, front, and back walls (with "left" being the same left in Hassenplug's standard, the side next to the outputting module), and, say, 9 bricks tall on the right wall, and two bricks deep. The texture and "give" of the bottom would be important. A "hollow" bottom, such as suspended plate, will dissipate most of the bounce, but one built over bricks will behave very elastically.

As to what an acceptable failure rate might be, I believe that is situation-dependent. You can be reliable enough to impress your friends. You can be reliable enough to make a YouTube video. You can be reliable enough to be part of a GBC. And you can be reliable enough to keep Tom from losing his mind. There may be a holy grail level, too, where you are reliable enough to not need a baby sitter at all. So it might make sense to create reliability categories. Level 0 would be an untested module (I started with a zero reference point in deference to the mathematical Rafe). Level 1 would demonstrate receiving and outputting 30 balls in 30 seconds with 0 leaks and no intervention. At Level 2 we start using statistics to prove a certain level of reliability. I don't know what numbers to ascribe. Maybe align it what one person monitoring 5 meters of GBC can do at a 90% duty cycle (the other 10% being allocated to resting). Level 3 would be one person monitoring 5 meters of GBC at a 40% duty cycle (the other 60% being allocated to interacting with the public and resting). Level 4 would be akin expecting zero failures over an entire exhibition weekend. To name the reliability levels:

Level 0: untested
Level 1: demonstrated
Level 2: acceptable
Level 3: proven
Level 4: infallable
Posted by ALittleSlow (administrator) on 24 March 2015 at 21:22.
Edited by ALittleSlow (administrator) on 24 March 2015 at 21:22.

A zero depth in basket doesn't sound right. The specification requires an opening of 8x8 studs, but without depth there would be no opening. It also wouldn't be a basket. It's reasonable to assume that a module may cover the entire in basket, and thus the in basket must have sufficient depth to make 30 balls fit underneath. That's my interpretation.

A well behaved module should output the balls in an orderly fashion, but unless it's a big problem I don't think it should be added to the rules. Any added rule will raise the barrier to entry. Even coping with 30 balls seems to be hard enough, but promising to do a good effort of incorporating it anyway could get more people to start building. Instead it would be great to have a description of best practises and place it in close proximity to the rules.

Another underspecified detail in the spec is the height of the basket. It says ten bricks, but doesn't say if that includes the baseplate. As the page is talking about building on baseplates it seems reasonable that the height should be baseplate+10 bricks+stud height. Given the table height issue, I guess it's still bad to be that close to the limit.

Posted by Torso on 24 March 2015 at 23:30.

I meant that extra effort to include beginner's modules should be made, even if they aren't completely conforming to the spec. Placing forgiving modules before and/or after is one of the few ways we have of making it easier to get started.

Posted by Torso on 25 March 2015 at 15:42.

Posted by Torso on 2015-03-25 at 15:42:46.

»I meant that extra effort to include beginner's modules should be made, even if they aren't completely conforming to the spec. «
That makes sense. And it raises a topic worthy of its own thread.

Posted by ALittleSlow (administrator) on 25 March 2015 at 22:34.

Rereading John's post reminds me of a saying, the earliest reference of which I can find is by William Stallings in Network World on May 23, 1993: "Conformance is no guarantee of interoperability". The two problems Stallings points to are 1) standards nearly always leave some room for subjective judgement and 2) standards do not cover every aspect of interoperability. He doesn't provide a solution, only a caution: be skeptical and seek proof of interoperability.

You can see the first principle (or is it the second?) in operation by posing the question, "what is the maximum height of a standard in basket?" It seems obvious that the answer is 10 bricks. Surprise! The answer is 10 and 1/4 bricks. It seems from the canonical example that you are allowed a baseplate, 10 bricks and the studs on those bricks. A baseplate is 2 (not 4 as originally posted) LDU or 1/12 of a brick thick, and studs are a fraction over 1/6 of a brick high. So 10 and 1/4, or so.

I can only think of one way to make conformance to the standard more likely to result in interoperability: make the standard more specific. The problem is that the specific the rules, the less room you give the designer. So there is no perfect solution. The "right" answer depends on how important interoperability is to you compared to creative freedom.

Posted by ALittleSlow (administrator) on 2 June 2015 at 04:28.
Edited by ALittleSlow (administrator) on 6 June 2015 at 03:15.

I'm not convinced that changing the specification is a good thing. It's a good thing that it's short and simple. Primarily we should provide information on how to interpret and implement it.

When programming, writing code to a given specification is common. To check that it conforms to the spec, we often use test cases. Some people take it so far that they consider the test cases to be the specification (Test Driven Development). Maybe that is something we can use?

Design a couple of evil in baskets and output chutes that narrowly conforms to the spec or even exceeds it slightly. By using common bricks it should be easy for people to build and test their modules with them. If they are designed in a good way, it should take care of the most common interoperability issues.

Posted by Torso on 2 June 2015 at 12:00.

I disagree that the baseplate should be counted in the height-of-input-bin calculations. Clearly it should be "height above whatever you use as a base" (otherwise where do you stop? Do you include the height of the table? Height above sea level of the room?). If every module uses a baseplate, (which would have been the norm when the spec was written) then it's height above that baseplate. If not every module has a baseplate, then you're using some lower base, and an input bin that's 10 bricks + baseplate high is non-conformant.

About the studs though, I've got nothing.


Posted by Captainowie (administrator) on 2 June 2015 at 12:45.

Torso, I almost completely agree. I only disagree by degree: I wouldn't go as far as evil. Maybe stringent or extreme case. An output with a 2 meter drop into an in basket would conform to the spec, and would be evil, but few would expect an in basket to handle it.

You bring up a good point: identifying the common interoperability issues. Then we can design test cases for those issues.

Owen, I'll accept that argument. The case for the baseplate is based solely on a baseplate being present in an example Steve Hassenplug posted alongside the rules. But if one interprets that baseplate as simply being the "substrate", then this argument vanishes. I didn't like that interpretation, anyway. -Brian

Posted by ALittleSlow (administrator) on 6 June 2015 at 03:31.

Evil might have been too strong. I think we mean the same thing.

Regarding baseplates, this quote (from "Building Notes") is relevant: "Most, but not all modules will be assembled on some sort of baseplate, and it's assumed these plates can be connected together."

The specification is ambiguous and outdated. I think it would be better if this wiki would focus on current practices and present the specification in a way that makes it more likely that new modules will be compatible. Let's specify the maximum height of the in basket without baseplate and a strong recommendation to output balls one brick higher (or a baseplate higher at least). The link to the canonical rules should still be kept.

Posted by Torso on 9 June 2015 at 11:19.

I don't mind tables being not even in height. It actually helps showing the flexibility in GBC modules. I always try to create my modules with a 10x10x10 inbox as a fixed starting point for everyone. A basis to start from when creating any module. Baseplates not counted. Plates and tiles are counted. If I need flexibility I will create that at the exit of the module. Either a higher exit point or a flexible one. flexible in both hight and or direction. Baseplates kan be very handy especially when your module does vibrate and you can fix it to the next or previous module. Though if it has a flexible ending, a baseplate will be useless at that point. I also do try to setup the modules differently at each event. It shows that it shouldn't matter which module is placed in front or after your module. If you want to make an exit at two meters height, you can be sure you will create a mess on the table because of bouncing balls. No inbox will be able to handle that. Do you want to cleanup that mess? Answer will probably be "no". So don't do that but make a double looping behind it to give the audience a very nice marbletrack to look at.

Just my opinion... :-)

Posted by on 9 June 2015 at 21:48.
Page: 02