Home    LBP Showcase / Reviews / Recommendations    Object Showcase
#1

Averaging a set of numbers

Archive: 9 posts

http://i47.tinypic.com/dfeus2.png


Background: A day or two ago I posted in the Help section asking for ideas on how to average a set of number. I'm creating an adaption of the Deal or No Deal gameshow, and part of the gameplay involves 'bank offers', where you get offered money in exchange for your briefcase. The offer value is based on an mean of all of the cases remaining in play.

My version of the game involves 24 briefcases, with values ranging from 1 to 250. There are 7 bank offers during the game, occuring at the following stages: 18 cases remaining, 13 cases remaining, 9 cases remaining, 6 cases remaining, 4 cases remaining, 3 cases remaining, 2 cases remaining. Hence I needed a system which could find the average of 18 values, 13 values, 9 values, 6 values, 4 values, 3 values or 2 values. Because there is a lot of other stuff occuring in the game I also had to try and keep thermometer usage to a minimum.


Here's what I came up with. I've seen the logic work some others on the forum have shown, so I'm sure there's a much more efficient way I haven't thought of to do this task. If anyone thinks of something more efficient though then let me know. I'm sure the extra thermometer space would come in handy.




http://imgur.com/JLnZG.png

Rather than creating an in-game system that can divide numbers ranging from 1 to 250 by denominators of 18, 13, 9, 6, 4, 3 and 2, I precalculated how much each case would be worth if it were part of an average under each circumstance. The values I used are shown in the table below.

http://imgur.com/w6Np4.png

For example, if I wanted to find the average of four cases, where the total case values were 10, 50, 90 and 150, all I would have to do is find the sum of 10/4 + 50/4 + 90/4 + 150/4. Using the above table, this is roughly 2 + 10 + 20 + 40 = 72 (actual average is 75).


In order to represent these values in-game, I created a huge series of dissolving block columns. Each block in each column is coded with the same information shown in the table above. Values were coded with sets of emitters: a HUNDREDS emitter, a TENS emitter and a ONES emitter. Each type of emitter emits a different coloured key, and the number of keys emitted depends on the value of the block.






http://imgur.com/g2Qt0.png



The use of dissolving blocks have several important implications:


1) Once a deal has been offered and rejected, the lowest row of blocks is dissolved and the next row falls into place. This new row contains information for the following bank offer, and hence a single detector system can be used for each of the 8 bank offers.

2) When a case is 'opened' and removed from gameplay, the dissolving block base that supports the column is removed and the entire column falls away. This means that the detector will no longer read values from this case, and these cases will not contribute to the next calculated bank offer. In the previous example of finding an average of cases worth 10, 50, 90 and 150, there would only be four columns of dissolving blocks remaining at this stage of the game, and hence finding an average of these cases just involves finding the sum of blocks available to the detector.






http://imgur.com/RzCLR.png






http://imgur.com/H8Bbe.png
Edit: That should say Key H, not Key G.



http://imgur.com/u7zP4.png


The second component of the system is a moving detector attached to a piston. The detector is positioned just beneath the columns of dissolving blocks, and moves from right to left. As it passes under each block, three things occur:



1) Two switches on the detector act as piston control. An AND logic system located elsewhere determines if the detector is in front of a column of blocks, and if the block immediately above the detector contains useful information (some blocks are left intentionally blank). If both conditions are met, the detector pauses for 1.0s.

2) A key on the detector panel activates the magnetic switch on the dissolving block above. This in turn activates the dissolving block's set of emitters. Each emitter can emit up to 9 keys at a rate of 0.1 keys per second (hence the need for a 1 second pause).

3) Magnetic switches on the detector panel read the number of keys emitted by each type of emitter, and feed that information into the next part of the system.




http://imgur.com/ZvaU5.png





http://imgur.com/EwwBI.png



http://imgur.com/wwAei.png

The final part of my system involves an incremental wheel motor. Credit for this idea goes to Tamland (read his thread here (https://lbpcentral.lbp-hub.com/index.php?t=19915-Incremental-Bolt)).

Basically, if we know the speed of a motor and we know the duration it has been switched on, we know how far it will have turned. If you turn on a bolt motor for a very short duration (0.1 s) then you can make the bolt meter spin a fraction of the wheel. Altering the speed of the bolt meter will alter how much it spins.

The incremental bolts receive information from my moving piston detector. The emitters on the dissolving blocks emit keys with lifetimes of 0.1s. These keys activate switches on the detector, which then turn the wheel. The speed of the bolt meter is set so that the wheel turns 36 degrees (or one tenth of a circle) every time a key is detected. It is possible to then measure how far the wheel has turned using a combination of magnetic switches and keys.

Given that my emitters already emit separate values for ONES, TENS and HUNDREDS, I set up three of these wheel systems next to each other. Each wheel takes in input from a magnetic switch on the detector. Hence, one wheel spins when ONES are emitted, the second wheel spins when TENS are emitted, and the final wheel spins when HUNDREDS are emitted.





http://imgur.com/5R2FV.png


Whenever a wheel has performed a full rotation and has returned to the origin (i.e. 'reached 10&apos, a unit has to be added to counter of the next order of magnitude. My initial approach involved adding extra emitters at the end of the detectors path, depending on how many units I needed to carry over.

An alternative approach, which worked much simpler to implement, was to add a second layer to the wheel. The second layer (which contains switches positioned at the origin) is directly in line with the first layer, and is also controlled by a motor bolt. The main difference is that the second layer rotates in the opposite direction. Given that the second layer contains the switches used to detect position, this is effectively the same as rotating the first layer by an extra position.

For example, every time my ONES counter performs one full rotation, Switch D on the second layer is activate. Switch D sets off the flipper piston housed beneath the counter, which in turn has a duration of 0.1 s. A switch at the flipper piston then causes the second layer wheel on the TENS counter to move 36 degrees in the opposite direction to the first layer wheel.




http://imgur.com/KRG9v.png






http://imgur.com/07g6y.png






Final thermometer temperature for averaging system: 40%.

Dissolving blocks and emitters: 36%
Detector and counters: 4%		2010-07-03 05:03:00

Author:
Tntnnbltn
Posts: 10

This is... incredibly impressive.2010-07-03 07:18:00

Author:
Tyler
Posts: 663

Incredible.
I would never be able to do anything like this. Ever.
So, a deal or no deal level?
I'll keep an eye out for it on here.		2010-07-03 08:18:00

Author:
Jedi_1993
Posts: 1518

My bwain hurts =S

That's awesome!		2010-07-03 09:33:00

Author:
Weretigr
Posts: 2105

Wow, that's amazing. Great job and I wish you luck on your Sack or No Sack level.2010-07-03 16:52:00

Author:
Dragonvarsity
Posts: 5208

That's an awesome system you got there! :O
I'm really impressed!		2010-07-03 20:15:00

Author:
phil_003
Posts: 609

Woah O.O
That is crazy...		2010-07-05 21:03:00

Author:
piggabling
Posts: 2979

Wow, you even went out of your way to explain to us how this works!
Amazing, truly amazing.		2010-07-08 06:48:00

Author:
Mastadom
Posts: 195

Quite brilliant logic you've got there. Can't wait to see this all in action with your Deal or no Deal level!

And to think that LBP2 will make all of this physical logic obsolete...Yet this seems really advanced already. 		2010-07-08 23:35:00

Author:
Rhombohedron
Posts: 25


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

Datenschutz
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.