# Raspberry Jam Big Birthday Weekend 2018 roundup

Post Syndicated from Ben Nuttall original https://www.raspberrypi.org/blog/big-birthday-weekend-2018-roundup/

A couple of weekends ago, we celebrated our sixth birthday by coordinating more than 100 simultaneous Raspberry Jam events around the world. The Big Birthday Weekend was a huge success: our fantastic community organised Jams in 40 countries, covering six continents!

We sent the Jams special birthday kits to help them celebrate in style, and a video message featuring a thank you from Philip and Eben:

#### Raspberry Jam Big Birthday Weekend 2018

To celebrate the Raspberry Pi’s sixth birthday, we coordinated Raspberry Jams all over the world to take place over the Raspberry Jam Big Birthday Weekend, 3-4 March 2018. A massive thank you to everyone who ran an event and attended.

## The Raspberry Jam photo booth

I put together code for a Pi-powered photo booth which overlaid the Big Birthday Weekend logo onto photos and (optionally) tweeted them. We included an arcade button in the Jam kits so they could build one — and it seemed to be quite popular. Some Jams put great effort into housing their photo booth:

Here are some of my favourite photo booth tweets:

PiParty photo booth @RGVSA & @ @Nerdvana_io #Rjam

The @SouthendRPIJams #PiParty photo booth

PiParty photo booth

#### Preston Raspberry Jam on Twitter

Preston Raspberry Jam Photobooth #RJam #PiParty

If you want to try out the photo booth software yourself, find the code on GitHub.

## The great Raspberry Jam bake-off

Traditionally, in the UK, people have a cake on their birthday. And we had a few! We saw (and tasted) a great selection of Pi-themed cakes and other baked goods throughout the weekend:

## Raspberry Jams everywhere

We always say that every Jam is different, but there’s a common and recognisable theme amongst them. It was great to see so many different venues around the world filling up with like-minded Pi enthusiasts, Raspberry Jam–branded banners, and Raspberry Pi balloons!

### Europe

Thank you so much to all the attendees of the Ikana Jam in Krakow past Saturday! We shared fun experiences, some of them… also painful 😉 A big thank you to @Raspberry_Pi for these global celebrations! And a big thank you to @hubraum for their hospitality! #PiParty #rjam

#### NI Raspberry Jam on Twitter

We also had a super successful set of wearables workshops using @adafruit Circuit Playground Express boards and conductive thread at today’s @Raspberry_Pi Jam! Very popular! #PiParty

My SenseHAT workshop, going well! @SouthendRPiJams #PiParty

#### Worksop College Raspberry Jam on Twitter

Learning how to scare the zombies in case of an apocalypse- it worked on our young learners #PiParty @worksopcollege @Raspberry_Pi https://t.co/pntEm57TJl

### Africa

Being one of the two places in Kenya where the #PiParty took place, it was an amazing time spending the day with this team and getting to learn and have fun. @TaitaTavetaUni and @Raspberry_Pi thank you for your support. @TTUTechlady @mictecttu ch

@TheMagP1

@GABONIAVERACITY #PiParty Lagos Raspberry Jam 2018 Special International Celebration – 6th Raspberry-Pi Big Birthday! Lagos Nigeria @Raspberry_Pi @ben_nuttall #RJam #RaspberryJam #raspberrypi #physicalcomputing #robotics #edtech #coding #programming #edTechAfrica #veracityhouse https://t.co/V7yLxaYGNx

### North America

The Riverside Raspberry Jam @Vocademy is underway! #piparty

The Philly & Pi #PiParty event with @Bresslergroup and @TechGirlzorg was awesome! The Scratch and Pi workshop was amazing! It was overall a great day of fun and tech!!! Thank you everyone who came out!

Thanks everyone who came out to the @Raspberry_Pi Big Birthday Jam! Special thanks to @PBFerrell @estefanniegg @pcsforme @pandafulmanda @colnels @bquentin3 couldn’t’ve put on this amazing community event without you guys!

#### Merge Robotics 2706 on Twitter

We are back at @SciTechMuseum for the second day of @OttawaPiJam! Our robot Mergius loves playing catch with the kids! #pijam #piparty #omgrobots

### South America

Así terminamos el #Raspberry Jam Big Birthday Weekend #Bogota 2018 #PiParty de #RaspberryJamBogota 2018 @Raspberry_Pi Nos vemos el 7 de marzo en #ArduinoDayBogota 2018 y #RaspberryJamBogota 2018

### Asia

#### Fablab UP Cebu on Twitter

Happy 6th birthday, @Raspberry_Pi! Greetings all the way from CEBU,PH! #PiParty #IoTCebu Thanks @CebuXGeeks X Ramos for these awesome pics. #Fablab #UPCebu

ラズパイ、6才のお誕生日会スタート in Tokyo PCNブースで、いろいろ展示とhttps://t.co/L6E7KgyNHFとIchigoJamつないだ、こどもIoTハッカソンmini体験やってます at 東京蒲田駅近 https://t.co/yHEuqXHvqe #piparty #pipartytokyo #rjam #opendataday

Happy birthday @Raspberry_Pi! #piparty #iotcebu @coolnumber9 https://t.co/2ESVjfRJ2d

### Oceania

#### Glenunga Raspberry Pi Club on Twitter

PiParty photo booth

Personally, I managed to get to three Jams over the weekend: two run by the same people who put on the first two Jams to ever take place, and also one brand-new one! The Preston Raspberry Jam team, who usually run their event on a Monday evening, wanted to do something extra special for the birthday, so they came up with the idea of putting on a Raspberry Jam Sandwich — on the Friday and Monday around the weekend! This meant I was able to visit them on Friday, then attend the Manchester Raspberry Jam on Saturday, and finally drop by the new Jam at Worksop College on my way home on Sunday.

I’m at my first Raspberry Jam #PiParty event of the big birthday weekend! @PrestonRJam has been running for nearly 6 years and is a great place to start the celebrations!

Back at @McrRaspJam at @DigInnMMU for #PiParty

Great to see mine & @Frans_facts Balloon Pi-Tay popper project in action at @worksopjam #rjam #PiParty https://t.co/GswFm0UuPg

Various members of the Foundation team attended Jams around the UK and US, and James from the Code Club International team visited AmsterJam.

Thanks to everyone who came to our Jam and everyone who helped out. @phoenixtogether thanks for amazing cake & hosting. Ademir you’re so cool. It was awesome to meet Craig Morley from @Raspberry_Pi too. #PiParty

Great #PiParty today at the @cotswoldjam with bloody delicious cake and lots of raspberry goodness. Great to see @ClareSutcliffe @martinohanlon playing on my new pi powered arcade build:-)

Happy 6th Birthday @Raspberry_Pi from everyone at the #PiParty at #cotswoldjam in Cheltenham!

It’s @Raspberry_Pi 6th birthday and we’re celebrating by taking part in @amsterjam__! Happy Birthday Raspberry Pi, we’re so happy to be a part of the family! #PiParty

For more Jammy birthday goodness, check out the PiParty hashtag on Twitter!

## The Jam makers!

A lot of preparation went into each Jam, and we really appreciate all the hard work the Jam makers put in to making these events happen, on the Big Birthday Weekend and all year round. Thanks also to all the teams that sent us a group photo:

Lots of the Jams that took place were brand-new events, so we hope to see them continue throughout 2018 and beyond, growing the Raspberry Pi community around the world and giving more people, particularly youths, the opportunity to learn digital making skills.

So many wonderful people in the @Raspberry_Pi community. Thanks to everyone at #PottonPiAndPints for a great afternoon and for everything you do to help young people learn digital making. #PiParty

Special thanks to ModMyPi for shipping the special Raspberry Jam kits all over the world!

Don’t forget to check out our Jam page to find an event near you! This is also where you can find free resources to help you get a new Jam started, and download free starter projects made especially for Jam activities. These projects are available in English, Français, Français Canadien, Nederlands, Deutsch, Italiano, and 日本語. If you’d like to help us translate more content into these and other languages, please get in touch!

PS Some of the UK Jams were postponed due to heavy snowfall, so you may find there’s a belated sixth-birthday Jam coming up where you live!

@TheMagP1 Ours was rescheduled until later in the Spring due to the snow but here is Babbage enjoying the snow!

The post Raspberry Jam Big Birthday Weekend 2018 roundup appeared first on Raspberry Pi.

# Random with care

Post Syndicated from Eevee original https://eev.ee/blog/2018/01/02/random-with-care/

Hi! Here are a few loose thoughts about picking random numbers.

This is all aimed at frivolous pursuits like video games. Hell, even video games where money is at stake should be deferring to someone who knows way more than I do. Otherwise you might find out that your deck shuffles in your poker game are woefully inadequate and some smartass is cheating you out of millions. (If your random number generator has fewer than 226 bits of state, it can’t even generate every possible shuffling of a deck of cards!)

## Use the right distribution

Most languages have a random number primitive that spits out a number uniformly in the range [0, 1), and you can go pretty far with just that. But beware a few traps!

### Random pitches

Say you want to pitch up a sound by a random amount, perhaps up to an octave. Your audio API probably has a way to do this that takes a pitch multiplier, where I say “probably” because that’s how the only audio API I’ve used works.

Easy peasy. If 1 is unchanged and 2 is pitched up by an octave, then all you need is rand() + 1. Right?

No! Pitch is exponential — within the same octave, the “gap” between C and C♯ is about half as big as the gap between B and the following C. If you pick a pitch multiplier uniformly, you’ll have a noticeable bias towards the higher pitches.

One octave corresponds to a doubling of pitch, so if you want to pick a random note, you want 2 ** rand().

### Random directions

For two dimensions, you can just pick a random angle with rand() * TAU.

If you want a vector rather than an angle, or if you want a random direction in three dimensions, it’s a little trickier. You might be tempted to just pick a random point where each component is rand() * 2 - 1 (ranging from −1 to 1), but that’s not quite right. A direction is a point on the surface (or, equivalently, within the volume) of a sphere, and picking each component independently produces a point within the volume of a cube; the result will be a bias towards the corners of the cube, where there’s much more extra volume beyond the sphere.

No? Well, just trust me. I don’t know how to make a diagram for this.

Anyway, you could use the Pythagorean theorem a few times and make a huge mess of things, or it turns out there’s a really easy way that even works for two or four or any number of dimensions. You pick each coordinate from a Gaussian (normal) distribution, then normalize the resulting vector. In other words, using Python’s random module:

 1 2 3 4 5 6 def random_direction(): x = random.gauss(0, 1) y = random.gauss(0, 1) z = random.gauss(0, 1) r = math.sqrt(x*x + y*y + z*z) return x/r, y/r, z/r 

Why does this work? I have no idea!

Note that it is possible to get zero (or close to it) for every component, in which case the result is nonsense. You can re-roll all the components if necessary; just check that the magnitude (or its square) is less than some epsilon, which is equivalent to throwing away a tiny sphere at the center and shouldn’t affect the distribution.

### Beware Gauss

Since I brought it up: the Gaussian distribution is a pretty nice one for choosing things in some range, where the middle is the common case and should appear more frequently.

That said, I never use it, because it has one annoying drawback: the Gaussian distribution has no minimum or maximum value, so you can’t really scale it down to the range you want. In theory, you might get any value out of it, with no limit on scale.

In practice, it’s astronomically rare to actually get such a value out. I did a hundred million trials just to see what would happen, and the largest value produced was 5.8.

But, still, I’d rather not knowingly put extremely rare corner cases in my code if I can at all avoid it. I could clamp the ends, but that would cause unnatural bunching at the endpoints. I could reroll if I got a value outside some desired range, but I prefer to avoid rerolling when I can, too; after all, it’s still (astronomically) possible to have to reroll for an indefinite amount of time. (Okay, it’s really not, since you’ll eventually hit the period of your PRNG. Still, though.) I don’t bend over backwards here — I did just say to reroll when picking a random direction, after all — but when there’s a nicer alternative I’ll gladly use it.

And lo, there is a nicer alternative! Enter the beta distribution. It always spits out a number in [0, 1], so you can easily swap it in for the standard normal function, but it takes two “shape” parameters α and β that alter its behavior fairly dramatically.

With α = β = 1, the beta distribution is uniform, i.e. no different from rand(). As α increases, the distribution skews towards the right, and as β increases, the distribution skews towards the left. If α = β, the whole thing is symmetric with a hump in the middle. The higher either one gets, the more extreme the hump (meaning that value is far more common than any other). With a little fiddling, you can get a number of interesting curves.

Screenshots don’t really do it justice, so here’s a little Wolfram widget that lets you play with α and β live:

Note that if α = 1, then 1 is a possible value; if β = 1, then 0 is a possible value. You probably want them both greater than 1, which clamps the endpoints to zero.

Also, it’s possible to have either α or β or both be less than 1, but this creates very different behavior: the corresponding endpoints become poles.

Anyway, something like α = β = 3 is probably close enough to normal for most purposes but already clamped for you. And you could easily replicate something like, say, NetHack’s incredibly bizarre rnz function.

### Random frequency

Say you want some event to have an 80% chance to happen every second. You (who am I kidding, I) might be tempted to do something like this:

 1 2 if random() < 0.8 * dt: do_thing() 

In an ideal world, dt is always the same and is equal to 1 / f, where f is the framerate. Replace that 80% with a variable, say P, and every tic you have a P / f chance to do the… whatever it is.

Each second, f tics pass, so you’ll make this check f times. The chance that any check succeeds is the inverse of the chance that every check fails, which is $$1 – \left(1 – \frac{P}{f}\right)^f$$.

For P of 80% and a framerate of 60, that’s a total probability of 55.3%. Wait, what?

Consider what happens if the framerate is 2. On the first tic, you roll 0.4 twice — but probabilities are combined by multiplying, and splitting work up by dt only works for additive quantities. You lose some accuracy along the way. If you’re dealing with something that multiplies, you need an exponent somewhere.

But in this case, maybe you don’t want that at all. Each separate roll you make might independently succeed, so it’s possible (but very unlikely) that the event will happen 60 times within a single second! Or 200 times, if that’s someone’s framerate.

If you explicitly want something to have a chance to happen on a specific interval, you have to check on that interval. If you don’t have a gizmo handy to run code on an interval, it’s easy to do yourself with a time buffer:

 1 2 3 4 5 6 timer += dt # here, 1 is the "every 1 seconds" while timer > 1: timer -= 1 if random() < 0.8: do_thing() 

Using while means rolls still happen even if you somehow skipped over an entire second.

(For the curious, and the nerds who already noticed: the expression $$1 – \left(1 – \frac{P}{f}\right)^f$$ converges to a specific value! As the framerate increases, it becomes a better and better approximation for $$1 – e^{-P}$$, which for the example above is 0.551. Hey, 60 fps is pretty accurate — it’s just accurately representing something nowhere near what I wanted. Er, you wanted.)

### Rolling your own

Of course, you can fuss with the classic [0, 1] uniform value however you want. If I want a bias towards zero, I’ll often just square it, or multiply two of them together. If I want a bias towards one, I’ll take a square root. If I want something like a Gaussian/normal distribution, but with clearly-defined endpoints, I might add together n rolls and divide by n. (The normal distribution is just what you get if you roll infinite dice and divide by infinity!)

It’d be nice to be able to understand exactly what this will do to the distribution. Unfortunately, that requires some calculus, which this post is too small to contain, and which I didn’t even know much about myself until I went down a deep rabbit hole while writing, and which in many cases is straight up impossible to express directly.

Here’s the non-calculus bit. A source of randomness is often graphed as a PDF — a probability density function. You’ve almost certainly seen a bell curve graphed, and that’s a PDF. They’re pretty nice, since they do exactly what they look like: they show the relative chance that any given value will pop out. On a bog standard bell curve, there’s a peak at zero, and of course zero is the most common result from a normal distribution.

(Okay, actually, since the results are continuous, it’s vanishingly unlikely that you’ll get exactly zero — but you’re much more likely to get a value near zero than near any other number.)

For the uniform distribution, which is what a classic rand() gives you, the PDF is just a straight horizontal line — every result is equally likely.

If there were a calculus bit, it would go here! Instead, we can cheat. Sometimes. Mathematica knows how to work with probability distributions in the abstract, and there’s a free web version you can use. For the example of squaring a uniform variable, try this out:

 1 PDF[TransformedDistribution[u^2, u \[Distributed] UniformDistribution[{0, 1}]], u] 

(The \[Distributed] is a funny tilde that doesn’t exist in Unicode, but which Mathematica uses as a first-class operator. Also, press shiftEnter to evaluate the line.)

This will tell you that the distribution is… $$\frac{1}{2\sqrt{u}}$$. Weird! You can plot it:

 1 Plot[%, {u, 0, 1}] 

(The % refers to the result of the last thing you did, so if you want to try several of these, you can just do Plot[PDF[…], u] directly.)

The resulting graph shows that numbers around zero are, in fact, vastly — infinitely — more likely than anything else.

What about multiplying two together? I can’t figure out how to get Mathematica to understand this, but a great amount of digging revealed that the answer is -ln x, and from there you can plot them both on Wolfram Alpha. They’re similar, though squaring has a much better chance of giving you high numbers than multiplying two separate rolls — which makes some sense, since if either of two rolls is a low number, the product will be even lower.

What if you know the graph you want, and you want to figure out how to play with a uniform roll to get it? Good news! That’s a whole thing called inverse transform sampling. All you have to do is take an integral. Good luck!

This is all extremely ridiculous. New tactic: Just Simulate The Damn Thing. You already have the code; run it a million times, make a histogram, and tada, there’s your PDF. That’s one of the great things about computers! Brute-force numerical answers are easy to come by, so there’s no excuse for producing something like rnz. (Though, be sure your histogram has sufficiently narrow buckets — I tried plotting one for rnz once and the weird stuff on the left side didn’t show up at all!)

By the way, I learned something from futzing with Mathematica here! Taking the square root (to bias towards 1) gives a PDF that’s a straight diagonal line, nothing like the hyperbola you get from squaring (to bias towards 0). How do you get a straight line the other way? Surprise: $$1 – \sqrt{1 – u}$$.

### Okay, okay, here’s the actual math

I don’t claim to have a very firm grasp on this, but I had a hell of a time finding it written out clearly, so I might as well write it down as best I can. This was a great excuse to finally set up MathJax, too.

Say $$u(x)$$ is the PDF of the original distribution and $$u$$ is a representative number you plucked from that distribution. For the uniform distribution, $$u(x) = 1$$. Or, more accurately,

$$u(x) = \begin{cases} 1 & \text{ if } 0 \le x \lt 1 \\ 0 & \text{ otherwise } \end{cases}$$

Remember that $$x$$ here is a possible outcome you want to know about, and the PDF tells you the relative probability that a roll will be near it. This PDF spits out 1 for every $$x$$, meaning every number between 0 and 1 is equally likely to appear.

We want to do something to that PDF, which creates a new distribution, whose PDF we want to know. I’ll use my original example of $$f(u) = u^2$$, which creates a new PDF $$v(x)$$.

The trick is that we need to work in terms of the cumulative distribution function for $$u$$. Where the PDF gives the relative chance that a roll will be (“near”) a specific value, the CDF gives the relative chance that a roll will be less than a specific value.

The conventions for this seem to be a bit fuzzy, and nobody bothers to explain which ones they’re using, which makes this all the more confusing to read about… but let’s write the CDF with a capital letter, so we have $$U(x)$$. In this case, $$U(x) = x$$, a straight 45° line (at least between 0 and 1). With the definition I gave, this should make sense. At some arbitrary point like 0.4, the value of the PDF is 1 (0.4 is just as likely as anything else), and the value of the CDF is 0.4 (you have a 40% chance of getting a number from 0 to 0.4).

Calculus ahoy: the PDF is the derivative of the CDF, which means it measures the slope of the CDF at any point. For $$U(x) = x$$, the slope is always 1, and indeed $$u(x) = 1$$. See, calculus is easy.

Okay, so, now we’re getting somewhere. What we want is the CDF of our new distribution, $$V(x)$$. The CDF is defined as the probability that a roll $$v$$ will be less than $$x$$, so we can literally write:

$$V(x) = P(v \le x)$$

(This is why we have to work with CDFs, rather than PDFs — a PDF gives the chance that a roll will be “nearby,” whatever that means. A CDF is much more concrete.)

What is $$v$$, exactly? We defined it ourselves; it’s the do something applied to a roll from the original distribution, or $$f(u)$$.

$$V(x) = P\!\left(f(u) \le x\right)$$

Now the first tricky part: we have to solve that inequality for $$u$$, which means we have to do something, backwards to $$x$$.

$$V(x) = P\!\left(u \le f^{-1}(x)\right)$$

Almost there! We now have a probability that $$u$$ is less than some value, and that’s the definition of a CDF!

$$V(x) = U\!\left(f^{-1}(x)\right)$$

Hooray! Now to turn these CDFs back into PDFs, all we need to do is differentiate both sides and use the chain rule. If you never took calculus, don’t worry too much about what that means!

$$v(x) = u\!\left(f^{-1}(x)\right)\left|\frac{d}{dx}f^{-1}(x)\right|$$

Wait! Where did that absolute value come from? It takes care of whether $$f(x)$$ increases or decreases. It’s the least interesting part here by far, so, whatever.

There’s one more magical part here when using the uniform distribution — $$u(\dots)$$ is always equal to 1, so that entire term disappears! (Note that this only works for a uniform distribution with a width of 1; PDFs are scaled so the entire area under them sums to 1, so if you had a rand() that could spit out a number between 0 and 2, the PDF would be $$u(x) = \frac{1}{2}$$.)

$$v(x) = \left|\frac{d}{dx}f^{-1}(x)\right|$$

So for the specific case of modifying the output of rand(), all we have to do is invert, then differentiate. The inverse of $$f(u) = u^2$$ is $$f^{-1}(x) = \sqrt{x}$$ (no need for a ± since we’re only dealing with positive numbers), and differentiating that gives $$v(x) = \frac{1}{2\sqrt{x}}$$. Done! This is also why square root comes out nicer; inverting it gives $$x^2$$, and differentiating that gives $$2x$$, a straight line.

Incidentally, that method for turning a uniform distribution into any distribution — inverse transform sampling — is pretty much the same thing in reverse: integrate, then invert. For example, when I saw that taking the square root gave $$v(x) = 2x$$, I naturally wondered how to get a straight line going the other way, $$v(x) = 2 – 2x$$. Integrating that gives $$2x – x^2$$, and then you can use the quadratic formula (or just ask Wolfram Alpha) to solve $$2x – x^2 = u$$ for $$x$$ and get $$f(u) = 1 – \sqrt{1 – u}$$.

Multiply two rolls is a bit more complicated; you have to write out the CDF as an integral and you end up doing a double integral and wow it’s a mess. The only thing I’ve retained is that you do a division somewhere, which then gets integrated, and that’s why it ends up as $$-\ln x$$.

And that’s quite enough of that! (Okay but having math in my blog is pretty cool and I will definitely be doing more of this, sorry, not sorry.)

## Random vs varied

Sometimes, random isn’t actually what you want. We tend to use the word “random” casually to mean something more like chaotic, i.e., with no discernible pattern. But that’s not really random. In fact, given how good humans can be at finding incidental patterns, they aren’t all that unlikely! Consider that when you roll two dice, they’ll come up either the same or only one apart almost half the time. Coincidence? Well, yes.

If you ask for randomness, you’re saying that any outcome — or series of outcomes — is acceptable, including five heads in a row or five tails in a row. Most of the time, that’s fine. Some of the time, it’s less fine, and what you really want is variety. Here are a couple examples and some fairly easy workarounds.

### NPC quips

The nature of games is such that NPCs will eventually run out of things to say, at which point further conversation will give the player a short brush-off quip — a slight nod from the designer to the player that, hey, you hit the end of the script.

Some NPCs have multiple possible quips and will give one at random. The trouble with this is that it’s very possible for an NPC to repeat the same quip several times in a row before abruptly switching to another one. With only a few options to choose from, getting the same option twice or thrice (especially across an entire game, which may have numerous NPCs) isn’t all that unlikely. The notion of an NPC quip isn’t very realistic to start with, but having someone repeat themselves and then abruptly switch to something else is especially jarring.

The easy fix is to show the quips in order! Paradoxically, this is more consistently varied than choosing at random — the original “order” is likely to be meaningless anyway, and it already has the property that the same quip can never appear twice in a row.

If you like, you can shuffle the list of quips every time you reach the end, but take care here — it’s possible that the last quip in the old order will be the same as the first quip in the new order, so you may still get a repeat. (Of course, you can just check for this case and swap the first quip somewhere else if it bothers you.)

That last behavior is, in fact, the canonical way that Tetris chooses pieces — the game simply shuffles a list of all 7 pieces, gives those to you in shuffled order, then shuffles them again to make a new list once it’s exhausted. There’s no avoidance of duplicates, though, so you can still get two S blocks in a row, or even two S and two Z all clumped together, but no more than that. Some Tetris variants take other approaches, such as actively avoiding repeats even several pieces apart or deliberately giving you the worst piece possible.

### Random drops

Random drops are often implemented as a flat chance each time. Maybe enemies have a 5% chance to drop health when they die. Legally speaking, over the long term, a player will see health drops for about 5% of enemy kills.

Over the short term, they may be desperate for health and not survive to see the long term. So you may want to put a thumb on the scale sometimes. Games in the Metroid series, for example, have a somewhat infamous bias towards whatever kind of drop they think you need — health if your health is low, missiles if your missiles are low.

I can’t give you an exact approach to use, since it depends on the game and the feeling you’re going for and the variables at your disposal. In extreme cases, you might want to guarantee a health drop from a tough enemy when the player is critically low on health. (Or if you’re feeling particularly evil, you could go the other way and deny the player health when they most need it…)

The problem becomes a little different, and worse, when the event that triggers the drop is relatively rare. The pathological case here would be something like a raid boss in World of Warcraft, which requires hours of effort from a coordinated group of people to defeat, and which has some tiny chance of dropping a good item that will go to only one of those people. This is why I stopped playing World of Warcraft at 60.

Dialing it back a little bit gives us Enter the Gungeon, a roguelike where each room is a set of encounters and each floor only has a dozen or so rooms. Initially, you have a 1% chance of getting a reward after completing a room — but every time you complete a room and don’t get a reward, the chance increases by 9%, up to a cap of 80%. Once you get a reward, the chance resets to 1%.

The natural question is: how frequently, exactly, can a player expect to get a reward? We could do math, or we could Just Simulate The Damn Thing.

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 from collections import Counter import random histogram = Counter() TRIALS = 1000000 chance = 1 rooms_cleared = 0 rewards_found = 0 while rewards_found < TRIALS: rooms_cleared += 1 if random.random() * 100 < chance: # Reward! rewards_found += 1 histogram[rooms_cleared] += 1 rooms_cleared = 0 chance = 1 else: chance = min(80, chance + 9) for gaps, count in sorted(histogram.items()): print(f"{gaps:3d} | {count / TRIALS * 100:6.2f}%", '#' * (count // (TRIALS // 100))) 
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15  1 | 0.98% 2 | 9.91% ######### 3 | 17.00% ################ 4 | 20.23% #################### 5 | 19.21% ################### 6 | 15.05% ############### 7 | 9.69% ######### 8 | 5.07% ##### 9 | 2.09% ## 10 | 0.63% 11 | 0.12% 12 | 0.03% 13 | 0.00% 14 | 0.00% 15 | 0.00% 

We’ve got kind of a hilly distribution, skewed to the left, which is up in this histogram. Most of the time, a player should see a reward every three to six rooms, which is maybe twice per floor. It’s vanishingly unlikely to go through a dozen rooms without ever seeing a reward, so a player should see at least one per floor.

Of course, this simulated a single continuous playthrough; when starting the game from scratch, your chance at a reward always starts fresh at 1%, the worst it can be. If you want to know about how many rewards a player will get on the first floor, hey, Just Simulate The Damn Thing.

 1 2 3 4 5 6 7  0 | 0.01% 1 | 13.01% ############# 2 | 56.28% ######################################################## 3 | 27.49% ########################### 4 | 3.10% ### 5 | 0.11% 6 | 0.00% 

Cool. Though, that’s assuming exactly 12 rooms; it might be worth changing that to pick at random in a way that matches the level generator.

(Enter the Gungeon does some other things to skew probability, which is very nice in a roguelike where blind luck can make or break you. For example, if you kill a boss without having gotten a new gun anywhere else on the floor, the boss is guaranteed to drop a gun.)

### Critical hits

I suppose this is the same problem as random drops, but backwards.

Say you have a battle sim where every attack has a 6% chance to land a devastating critical hit. Presumably the same rules apply to both the player and the AI opponents.

Consider, then, that the AI opponents have exactly the same 6% chance to ruin the player’s day. Consider also that this gives them an 0.4% chance to critical hit twice in a row. 0.4% doesn’t sound like much, but across an entire playthrough, it’s not unlikely that a player might see it happen and find it incredibly annoying.

Perhaps it would be worthwhile to explicitly forbid AI opponents from getting consecutive critical hits.

## In conclusion

An emerging theme here has been to Just Simulate The Damn Thing. So consider Just Simulating The Damn Thing. Even a simple change to a random value can do surprising things to the resulting distribution, so unless you feel like differentiating the inverse function of your code, maybe test out any non-trivial behavior and make sure it’s what you wanted. Probability is hard to reason about.

The following diagram shows how this logic could be isolated in an “order dispatcher,” whose only purpose is to route order messages to the appropriate queue based on whether the order exceeds $5000. Nothing on the web application or the processing nodes changes other than the target queue to which the order is sent. The rates at which orders are processed can be achieved by modifying the poll rates and scalability settings that I have already discussed. ### Extending the design pattern with Amazon SNS Amazon SNS supports reliable publish-subscribe (pub-sub) scenarios and push notifications to known endpoints across a wide variety of protocols. It eliminates the need to periodically check or poll for new information and updates. SNS supports: • Reliable storage of messages for immediate or delayed processing • Publish / subscribe – direct, broadcast, targeted “push” messaging • Multiple subscriber protocols • Amazon SQS, HTTP, HTTPS, email, SMS, mobile push, AWS Lambda With these capabilities, you can provide parallel asynchronous processing of orders in the system and extend it to support any number of different business use cases without affecting the production environment. This is commonly referred to as a “fanout” scenario. Rather than your web application pushing orders to a queue for processing, send a notification via SNS. The SNS messages are sent to a topic and then replicated and pushed to multiple SQS queues and Lambda functions for processing. As the diagram above shows, you have the development team consuming “live” data as they work on the next version of the processing application, or potentially using the messages to troubleshoot issues in production. Marketing is consuming all order information, via a Lambda function that has subscribed to the SNS topic, inserting the records into an Amazon Redshift warehouse for analysis. All of this, of course, is happening without affecting your order processing application. ### Summary While I haven’t dived deep into the specifics of each service, I have discussed how these services can be applied at an architectural level to build loosely coupled systems that facilitate multiple business use cases. I’ve also shown you how to use infrastructure and application-level scaling techniques, so you can get the most out of your EC2 instances. One of the many benefits of using these managed services is how quickly and easily you can implement powerful messaging capabilities in your systems, and lower the capital and operational costs of managing your own messaging middleware. Using Amazon SQS and Amazon SNS together can provide you with a powerful mechanism for decoupling application components. This should be part of design considerations as you architect for the cloud. For more information, see the Amazon SQS Developer Guide and Amazon SNS Developer Guide. You’ll find tutorials on all the concepts covered in this post, and more. To can get started using the AWS console or SDK of your choice visit: Happy messaging! # BackMap, the haptic navigation system Post Syndicated from Janina Ander original https://www.raspberrypi.org/blog/backmap-haptic/ At this year’s TechCrunch Disrupt NY hackathon, one team presented BackMap, a haptic feedback system which helps visually impaired people to navigate cities and venues. It is assisted by a Raspberry Pi and integrated into a backpack. ### Good vibrations with BackMap The team, including Shashank Sharma, wrote an iOS phone app in Swift, Apple’s open-source programming language. To convert between addresses and geolocations, they used the Esri APIs offered by PubNub. So far, so standard. However, they then configured their BackMap setup so that the user can input their destination via the app, and then follow the route without having to look at a screen or listen to directions. Instead, vibrating motors have been integrated into the straps of a backpack and hooked up to a Raspberry Pi. Whenever the user needs to turn left or right, the Pi makes the respective motor vibrate. #### Disrupt NY 2017 Hackathon | Part 1 Disrupt NY 2017 Hackathon presentations filmed live on May 15th, 2017. Preceding the Disrupt Conference is Hackathon weekend on May 13-14, where developers and engineers descend from all over the world to take part in a 24-hour hacking endurance test. BackMap can also be adapted for indoor navigation by receiving signals from beacons. This could be used to direct users to toilet facilities or exhibition booths at conferences. The team hopes to upgrade the BackMap device to use a wristband format in the future. ### Accessible Pi Here at Pi Towers, we are always glad to see Pi builds for people with disabilities: we’ve seen Sanskriti and Aman’s Braille teacher Mudra, the audio e-reader Valdema by Finnish non-profit Kolibre, and Myrijam and Paul’s award-winning, eye-movement-controlled wheelchair, to name but a few. Our mission is to bring the power of coding and digital making to everyone, and we are lucky to be part of a diverse community of makers and educators who have often worked proactively to make events and resources accessible to as many people as possible. There is, for example, the autism- and Tourette’s syndrome-friendly South London Raspberry Jam, organised by Femi Owolade-Coombes and his mum Grace. The Raspberry VI website is a portal to all things Pi for visually impaired and blind people. Deaf digital makers may find Jim Roberts’ video tutorials, which are signed in ASL, useful. And anyone can contribute subtitles in any language to our YouTube channel. If you create or use accessible tutorials, or run a Jam, Code Club, or CoderDojo that is designed to be friendly to people who are neuroatypical or have a disability, let us know how to find your resource or event in the comments! The post BackMap, the haptic navigation system appeared first on Raspberry Pi. # sheep-wolf – Exploit MD5 Collisions For Malware Detection Post Syndicated from Darknet original http://feedproxy.google.com/~r/darknethackers/~3/ZBPMdkZzgOc/ sheep-wolf is a tool to help you Exploit MD5 Collisions in software, specially malware samples which are commonly detected using MD5 hash signatures. and then a malicious one (Wolf) that have the same MD5 hash. Please use this code to test if the security products in your reach use MD5 internally to fingerprint binaries and […] The post… Read the full post at darknet.org.uk # Build your own Crystal Maze at Home Post Syndicated from Laura Sach original https://www.raspberrypi.org/blog/build-crystal-maze/ I recently discovered a TV channel which shows endless re-runs of the game show The Crystal Maze, and it got me thinking: what resources are available to help the younger generation experience the wonder of this iconic show? Well… ## Enter the Crystal Maze If you’re too young to remember The Crystal Maze, or if you come from a country lacking this nugget of TV gold, let me explain. A band of fairly useless contestants ran around a huge warehouse decked out to represent four zones: Industrial, Aztec, Futuristic, and Medieval. They were accompanied by a wisecracking host in a fancy coat, Richard O’Brien. Richard O’Brien also wrote The Rocky Horror Picture Show so, y’know, he was interesting to watch if nothing else. The contestants would enter rooms to play themed challenges – the categories were mental, physical, mystery, and skill – with the aim of winning crystals. If they messed up, they were locked in the room forever (well, until the end of the episode). For every crystal they collected, they’d be given a bit more time in a giant crystal dome at the end of the programme. And what did they do in the dome? They tried to collect pieces of gold paper while being buffeted by a wind machine, of course! Collect enough gold paper and you win a mediocre prize. Fail to collect enough gold paper and you win a mediocre prize. Like I said: TV gold. Sounds fun, doesn’t it? Here are some free resources that will help you recreate the experience of The Crystal Maze in your living room…without the fear of being locked in. ## Marble maze Photo credit: Board Game Geek Make the classic Crystal Maze game, but this time with a digital marble! Use your Sense HAT to detect pitch, roll, and yaw as you guide the marble to its destination. Bonus fact: marble mazes featured in the Crystal Maze board game from the 1990s. ## Buzz Wire Photo credit: Board Game Geek Guide the hook along the wire and win the crystal! Slip up and buzz three times, though, and it’s an automatic lock-in. The beauty of this make is that you can play any fail sound you like: burp wire, anyone? Follow the tutorial by community member David Pride, which he created for the Cotswold Jam. ## Laser tripwire Photo credit: Marc Gerrish Why not recreate the most difficult game of all? Can you traverse a room without setting off the laser alarms, and grab the crystal? Try your skill with our laser tripwire resource! ## Forget the crystal! Get out! I would love to go to a school fête where kids build their own Crystal Maze-style challenges. I’m sure there are countless other events which you could jazz up with a fun digital making challenge, though the bald dude in a fur coat remains optional. So if you have made your own Crystal Maze challenge, or you try out one of ours, we’d love to hear about it! Here at the Raspberry Pi Foundation, we take great pride in the wonderful free resources we produce for you to use in classes, at home, and in coding clubs. We publish them under a Creative Commons licence, and they’re an excellent way to develop your digital making skills. And massive thanks to David Pride and the Cotswold Jam for creating and sharing your great resources for free. The post Build your own Crystal Maze at Home appeared first on Raspberry Pi. # European Astro Pi Challenge winners Post Syndicated from David Honess original https://www.raspberrypi.org/blog/european-astro-pi-winners/ In October last year, with the European Space Agency and CNES, we launched the first ever European Astro Pi challenge. We asked students from all across Europe to write code for the flight of French ESA astronaut Thomas Pesquet to the International Space Station (ISS) as part of the Proxima mission. Today, we are very excited to announce the winners! First of all, though, we have a very special message from Thomas Pesquet himself, which comes all the way from space… #### Thomas Pesquet congratulates Astro Pi participants from space French ESA astronaut Thomas Pesquet floats in to thank all participants in the European Astro Pi challenge. In October last year, together with the European Space Agency, we launched the first ever European Astro Pi challenge for the flight of French ESA astronaut Thomas Pesquet to the International Space Station (ISS) as part of mission Proxima. Thomas also recorded a video in French: you can click here to see it and to enjoy some more of his excellent microgravity acrobatics. ## A bit of background This year’s competition expands on our previous work with British ESA astronaut Tim Peake, in which, together with the UK Space Agency and ESA, we invited UK students to design software experiments to run on board the ISS. Astro Pi Vis (AKA Ed) on board the ISS. Image from ESA. In 2015, we built two space-hardened Raspberry Pi units, or Astro Pis, to act as the platform on which to run the students’ code. Affectionately nicknamed Ed and Izzy, the units were launched into space on an Atlas V rocket, arriving at the ISS a few days before Tim Peake. He had a great time running all of the programs, and the data collected was transmitted back to Earth so that the winners could analyse their results and share them with the public. The European challenge provides the opportunity to design code to be run in space to school students from every ESA member country. To support the participants, we worked with ESA and CPC to design, manufacture, and distribute several hundred free Astro Pi activity kits to the teams who registered. Further support for teachers was provided in the form of three live webinars, a demonstration video, and numerous free educational resources. The Astro Pi activity kit used by participants in the European challenge. ## The challenge Thomas Pesquet assigned two missions to the teams: • A primary mission, for which teams needed to write code to detect when the crew are working in the Columbus module near the Astro Pi units. • A secondary mission, for which teams needed to come up with their own scientific investigation and write the code to execute it. The deadline for code submissions was 28 February 2017, with the judging taking place the following week. We can now reveal which schools will have the privilege of having their code uploaded to the ISS and run in space. ## The proud winners! Everyone produced great work and the judges found it really tough to narrow the entries down. In addition to the winning submissions, there were a number of teams who had put a great deal of work into their projects, and whose entries have been awarded ‘Highly Commended’ status. These teams will also have their code run on the ISS. We would like to say a big thank you to everyone who participated. Massive congratulations are due to the winners! We will upload your code digitally using the space-to-ground link over the next few weeks. Your code will be executed, and any files created will be downloaded from space and returned to you via email for analysis. In no particular order, the winners are: ### France • Winners • @stroteam, Institut de Genech, Hauts-de-France • Wierzbinski, École à la maison, Occitanie • Les Marsilyens, École J. M. Marsily, PACA • MauriacSpaceCoders, Lycée François Mauriac, Nouvelle-Aquitaine • Ici-bas, École de Saint-André d’Embrun, PACA • Les Astrollinaires, Lycée général et technologique Guillaume Apollinaire, PACA • Highly Commended • ALTAÏR, Lycée Albert Claveille, Nouvelle Aquitaine • GalaXess Reloaded, Lycée Saint-Cricq, Nouvelle Aquitaine • Les CM de Neffiès, École Louis Authie, Occitanie • Équipe Sciences, Collège Léonce Bourliaguet, Nouvelle Aquitaine • Maurois ICN, Lycée André Maurois, Normandie • Space Project SP4, Lycée Saint-Paul IV, Île de la Réunion • 4eme2 Gymnase Jean Sturm, Gymnase Jean Sturm, Grand Est • Astro Pascal dans les étoiles, École Pascal, Île-de-France • les-4mis, EREA Alexandre Vialatte, Auvergne-Rhône-Alpes • Space Cavenne Oddity, École Cavenne, Auvergne-Rhône-Alpes • Luanda for Space, Lycée Français de Luanda, Angola (Note: this is a French international school and the team members have French nationality/citizenship) • François Detrille, Lycée Langevin-Wallon, Île-de-France ### Greece • Winners • Delta, TALOS ed-UTH-robotix, Magnesia • Weightless Mass, Intercultural Junior High School of Evosmos, Macedonia • 49th Astro Pi Teamwork, 49th Elementary School of Patras, Achaia • Astro Travellers, 12th Primary School of Petroupolis, Attiki • GKGF-1, Gymnasium of Kanithos, Sterea Ellada • Highly Commended • AstroShot, Lixouri High School, Kefalonia • Salamina Rockets Pi, 1st Senior High School of Salamina, Attiki • The four Astro-fans, 6th Gymnasio of Veria, Macedonia • Samians, 2nd Gymnasio Samou, North Eastern Aegean ### United Kingdom • Winners • Madeley Ad Astra, Madeley Academy, Shropshire • Team Dexterity, Dyffryn Taf School, Carmarthenshire • The Kepler Kids, St Nicolas C of E Junior School, Berkshire • Catterline Pi Bugs, Catterline Primary, Aberdeenshire • smileyPi, Westminster School, London • Highly Commended • South London Raspberry Jam, South London Raspberry Jam, London ### Italy • Winners • Garibaldini, Istituto Comprensivo Rapisardi-Garibaldi, Sicilia • Buzz, IIS Verona-Trento, Sicilia • Water warmers, Liceo Scientifico Galileo Galilei, Abruzzo • Juvara/Einaudi Siracusa, IIS L. Einaudi, Sicilia • AstroTeam, IIS Arimondi-Eula, Piemonte ### Poland • Winners • Birnam, Zespół Szkoły i Gimnazjum im. W. Orkana w Niedźwiedziu, Malopolska • TechnoZONE, Zespół Szkół nr 2 im. Eugeniusza Kwiatkowskiego, Podkarpacie • DeltaV, Gimnazjum nr 49, Województwo śląskie • The Safety Crew, MZS Gimnazjum nr 1, Województwo śląskie • Warriors, Zespół Szkół Miejskich nr 3 w Jaśle, Podkarpackie • Highly Commended • The Young Cuiavian Astronomers, Gimnazjum im. Stefana Kardynała Wyszyńskiego w Piotrkowie Kujawskim, Kujawsko-pomorskie • AstroLeszczynPi, I Liceum Ogolnokształcace w Jasle im. Krola Stanislawa Leszczynskiego, Podkarpackie ### Portugal • Winners • Sampaionautas, Escola Secundária de Sampaio, Setúbal • Labutes Pi, Escola Secundária D. João II, Setúbal • AgroSpace Makers, EB 2/3 D. Afonso Henriques, Cávado • Zero Gravity, EB 2/3 D. Afonso Henriques, Cávado • Lua, Agrupamento de Escolas José Belchior Viegas, Algarve ### Romania • Winners • AstroVianu, Tudor Vianu National High School of Computer Science, Bucharest • MiBus Researchers, Mihai Busuioc High School, Iași • Cosmos Dreams, Nicolae Balcescu High School, Cluj • Carmen Sylva Astro Pi, Liceul Teoretic Carmen Sylva Eforie, Constanța • Stargazers, Tudor Vianu National High School of Computer Science, Bucharest ### Spain • Winners • Papaya, IES Sopela, Vizcaya • Salesianos-Ubeda, Salesianos Santo Domingo Savio, Andalusia • Valdespartans, IES Valdespartera, Aragón • Ins Terrassa, Institut Terrassa, Cataluña ### Ireland • Winner • Moonty1, Mayfield Community School, Cork ### Germany • Winner • BSC Behringersdorf Space Center, Labenwolf-Gymnasium, Bayern ### Norway • Winner • Skedsmo Kodeklubb, Kjeller Skole, Akershus ### Hungary • Winner • UltimaSpace, Mihaly Tancsics Grammar School of Kaposvár, Somogy ### Belgium • Winner • Lambda Voyager, Stedelijke Humaniora Dilsen, Limburg ## FAQ Why aren’t all 22 ESA member states listed? • Because some countries did not have teams participating in the challenge. Why do some countries have fewer than five teams? • Either because those countries had fewer than five teams qualifying for space flight, or because they had fewer than five teams participating in the challenge. How will I get my results back from space? • After your code has run on the ISS, we will download any files you created and they will be emailed to your teacher. The post European Astro Pi Challenge winners appeared first on Raspberry Pi. # Some moon math Post Syndicated from Robert Graham original http://blog.erratasec.com/2017/02/some-moon-math.html So “Brianna Wu” (famous for gamergate) is trending, and because I love punishment, I clicked on it to see why. Apparently she tweeted that Elon Musk’s plan to go to the moon is bad, because once there he can drop rocks on the Earth with the power of 100s of nuclear bombs. People are mocking her for the stupidity of this. But the math checks out. First of all, she probably got the idea from Heinlein’s book The Moon is a Harsh Mistress where the rebel moon colonists do just that. I doubt she did her own math, and relied upon Heinlein to do it for her. But let’s do the math ourselves. Let’s say that we want to stand at the height of the moon and drop a rock. How big a rock do we need to equal the energy of an atomic bomb? To make things simple, let’s assume the size of bombs we want is that of the one dropped on Hiroshima. As we know from high school physics, the energy of a dropped object (ignoring air) is: energy = 0.5 * mass * velocity * velocity Solving for mass (the size of the rock), the equation is: mass = 2 * energy/(velocity * velocity) We choose “energy” as that of an atomic bomb, but what is “velocity” in this equation, the speed of something dropped from the height of the moon? The answer is something close to the escape velocity, which is defined as the speed of something dropped infinitely far away from the Earth. The moon isn’t infinitely far away (only 250,000 miles away), but it’s close. How close? Well, let’s use the formula for escape velocity from Wikipedia [*]: where G is the “gravitational constant”, M is the “mass of Earth”, and r is the radius. Plugging in “radius of earth” and we get an escape velocity from the surface of the Earth of 11.18 km/s, which matches what Google tells us. Plugging in the radius of the moon’s orbit, we get 1.44 km/s [*]. Thus, we get the following as the speed of an object dropped from the height of the moon to the surface of the earth, barring air resistance [*]: 9.74 km/s Plugging these numbers in gets the following result: So the answer for the mass of the rock, dropped from the moon, to equal a Hiroshima blast, is 1.3 billion grams, or 1.3 million kilograms, or 1.3 thousand metric tons. Well, that’s a fine number and all, but what does that equal? Is that the size of Rhode Island? or just a big truck? The answer is: nearly the same mass as the Space Shuttle during launch (2.03 million kilograms [*]). Or, a rock about 24 feet on a side. That’s big rock, but not so big that it’s impractical, especially since things weigh 1/6th as on Earth. In Heinlein’s books, instead of shooting rocks via rockets, it shot them into space using a railgun, magnetic rings. Since the moon doesn’t have an atmosphere, you don’t need to shoot things straight up. Instead, you can accelerate them horizontally across the moon’s surface, to an escape velocity of 5,000 mph (escape velocity from moon’s surface). As the moon’s surface curves away, they’ll head out into space (or toward Earth) Thus, Elon Musk would need to: • go the moon • setup a colony, underground • mine iron ore • build a magnetic launch gun • build fields full of solar panels for energy • mine some rock • cover it in iron (for magnet gun to hold onto) • bomb earth At that point, he could drop hundreds of “nukes” on top of us. I, for one, would welcome our Lunar overlords. Free Luna! Update: I’ve made a number of short cuts, but I don’t think they’ll affect the math much. We don’t need escape velocity for the moon as a whole, just enough to reach the point where Earth’s gravity takes over. On the other hand, we need to kill the speed of the Moons’s orbit (2,000 miles per hour) in order to get down to Earth, or we just end up orbiting the Earth. I just assume the two roughly cancel each other out and ignore it. I also ignore the atmosphere. Meteors from outer space hitting the earth of this size tend to disintegrate or blow up before reaching the surface. The Chelyabinsk meteor, the one in all those dashcam videos from 2013, was roughly 5 times the size of our moon rocks, and blew up in the atmosphere, high above the surface, with about 5 times the energy of a Hiroshima bomb. Presumably, we want our moon rocks to reach the surface, so they’ll need some protection. Probably make them longer and thinner, and put an ablative heat shield up from, and wrap them in something strong like iron. I don’t know how much this will slow down the rock. Presumably, if coming straight down, it won’t slow down by much, but if coming in at a steep angle (as meteors do), then it could slow down quite a lot. Update: First version of this post used “height of moon”, which Wolfram Alfa interpreted as “diameter of moon”. This error was found by . The current version of this post changes this to the correct value “radius of moon’s orbit”. Update: I made a stupid error about Earth’s gravitational strength at the height of the Moon’s orbit. I’ve changed the equations to fix this. # Inclusive learning at South London Raspberry Jam Post Syndicated from Alex Bate original https://www.raspberrypi.org/blog/inclusive-learning-south-london-raspberry-jam/ Raspberry Pi Certified Educator Grace Owolade-Coombes runs the fantastically inclusive South London Raspberry Jam with her son Femi. In this guest post, she gives us the low-down on how the Jam got started. Enjoy! Grace and Femi Owolade-Coombes Our Jam has been running for over a year now; we’ve had three really big events and one smaller family hack day. Let me begin by telling you about how the idea of running a Jam arose in the first place. Around three years ago, I read about how coding was going to be part of the curriculum in primary and secondary schools and, as a teacher in the FE sector, I was intrigued. As I also had a young and inquisitive son, who was at primary school at the time, I felt that we should investigate further. Grace visited the National STEM Learning Centre in York for a course which introduced her to coding. I later attended a short course at the National STEM Learning Centre in York, during which one of the organisers told me about the Raspberry Pi Foundation; he suggested I come to a coding event back at the Centre a few weeks later with my family. We did, and Femi loved the Minecraft hack. Note from Alex: not the actual Minecraft hack but I’ll be having words with our resource gurus because this would be brilliant! The first Raspberry Jam we attended was in Southend with Andy Melder and the crew: it showed us just how welcoming the Jam community can be. Then I was lucky enough to attend Picademy, which truly was a transformative experience. Ben Nuttall showed me how to tweet photographs with the Pi, which was the beginning of me using Twitter. I particularly loved Clive Beale’s physical computing workshop which I took back and delivered to Femi. Picademy gave Grace the confidence to deliver Raspberry Pi training herself. After Picademy, I tweeted that I was now a Raspberry Pi Certified Educator and immediately got a request from Dragon Hall, Convent Garden to run a workshop – I didn’t realise they meant in three days’ time! Femi and I bit the bullet and ran our first physical computing workshop together. We haven’t looked back since. Femi went on to join the Festival of Code, which he loved. Around this time, Femi was attending a Tourettes Action support group, where young people with Tourette’s syndrome, like him, met up. Femi wanted to share his love of coding with them, but he felt that they might be put off as it can be difficult to spend extended amounts of time in public places when you have tics. He asked if we could set up a Jam that was inclusive: it would be both autism- and Tourette’s syndrome-friendly. There was such a wealth of support, advice, and volunteers who would help us set up that it really wasn’t a hard decision to make. Grace and Femi set up an Indiegogo campaign to help fund their Jam. We were fortunate to have met Marc Grossman during the Festival of Code: with his amazing skills and experience with Code Club, we set up together. For our first Jam, we had young coding pioneers from the community, such as Yasmin Bey and Isreal Genius, to join us. We were also blessed with David Whale‘s company and Kano even did a workshop with us. There are too many amazing people to mention. Grace and Femi held the first South London Raspberry Jam, an autism- and Tourette’s syndrome-friendly event for five- to 15-year-olds, at Deptford Library in October 2016, with 75 participants. We held a six-session Code Club in Catford Library followed by a second Jam in a local community centre, focusing on robotics with the CamJam EduKit 3, as well as the usual Minecraft hacks. Our third Jam was in conjunction with Kano, at their HQ, and included a SEN TeachMeet with Computing at School (CAS). Joseph Birks, the inventor of the Crumble, delivered a great robot workshop, and Paul Haynes delivered a Unity workshop too. Grace and Femi’s latest event was a family hack day in conjunction with the London Connected Learning Centre. Femi often runs workshops at our Jams. We try to encourage young coders to follow in Femi’s footsteps and deliver sessions too: it works best when young people learn from each other, and we hope the confidence they develop will enable them to help their friends and classmates to enjoy coding too. Inclusivity, diversity, and accessibility are at the heart of our Jams, and we are proud to have Tourettes Action and Ambitious about Autism as partners. #### Tourettes Action on Twitter All welcome to this event in London SAT, 12 DEC 2015 AT 13:00 2nd South London Raspberry Jam 2015 Bellingham… https://t.co/TPYC9Ontot Now we are taking stock of our amazing journey to learn about coding, and preparing to introduce it to more people. Presently we are looking to collaborate with the South London Makerspace and the Digital Maker Collective, who have invited Femi to deliver robot workshops at Tate Modern. We are also looking to progress to more project-based activities which fit with the Raspberry Pi Foundation’s Pioneers challenges. South London Raspberry Jam has participated in both Pi Wars and Astro Pi. Femi writes about all the events we attend or run: see hackerfemo.com or check out our website and sign up to our mailing list to keep informed. We are just about to gather a team for the Pioneers project, so watch out for updates. The post Inclusive learning at South London Raspberry Jam appeared first on Raspberry Pi. # Using Pi to experience another’s reality Post Syndicated from Alex Bate original https://www.raspberrypi.org/blog/using-pi-experience-anothers-reality/ Have you ever fancied being part of a real-life version of Being John Malkovich, without the danger of becoming trapped in a portal into the mind of an actor? This project helps you experience just that. European telecoms operator Tele2 recently relaunched their phone and internet service with a particularly hefty data plan offering 100GB that customers can use across nine different devices, and they asked creative agency Your Majesty to market the new offering. The agency had a novel take on the brief: In Sweden, a lot of discussion around connectivity tends to be negative, especially when it comes to controlling our exposure to media that can alter our outlook on our surroundings and the world. What if we made a campaign to show limitless connectivity in a way that changes our perspective? Striving to alter that negative viewpoint, they didn’t focus on anything as simple as nine devices all working at once, but rather went in a very different direction. #### Tele2: Settle For More – Case Film Tele2 is a Swedish telecom company that provides phone and Internet services. They are re-launching in a big way to become the best data provider in the country and asked us to create a campaign to showcase a killer offer. The final outcome was an immersive online experience, allowing viewers the chance to ‘step inside the minds’ of nine Swedish celebrities, including actor Joel Kinnaman and our favourite Queen of – ahem! – shoddy robots, Simone Giertz. A custom backpack housed a 3D-printed rig to support a Raspberry Pi 3 for collection of sensor data, and a colour-grading box for footage recorded by a GoPro-equipped helmet. “Wait: did she just say ‘collection of sensor data’?” Yes. Yes, I did. Along with the video and audio streams from the on-board GoPro and microphone, the system collected data on heart rate, emotional state, and even sweat. Delicious. The brain sensor data collected from the EEG then controls the colour of the footage as it’s relayed back to the audience: green for calm, yellow for happy, red for angry, and blue for sad. We can confirm that Simone’s screen turned a deep shade of purple on more than one occasion, and her heart rate actually shot up when she thought she had burned out some servos. Videos from the various participants can be viewed at the Tele2 YouTube channel, including Joel, Simone, entrepreneur Cristina Stenbeck, and altitude instructor Anna Lundh. Working with marketing agency Edelman Deportivo and digital studio Wolfmother Co., Your Majesty documented the impact of the campaign on Bēhance, so check it out. The post Using Pi to experience another’s reality appeared first on Raspberry Pi. # PIXEL for PC and Mac Post Syndicated from Eben Upton original https://www.raspberrypi.org/blog/pixel-pc-mac/ Our vision in establishing the Raspberry Pi Foundation was that everyone should be able to afford their own programmable general-purpose computer. The intention has always been that the Raspberry Pi should be a full-featured desktop computer at a$35 price point. In support of this, and in parallel with our hardware development efforts, we’ve made substantial investments in our software stack. These culminated in the launch of PIXEL in September 2016.

PIXEL represents our best guess as to what the majority of users are looking for in a desktop environment: a clean, modern user interface; a curated suite of productivity software and programming tools, both free and proprietary; and the Chromium web browser with useful plugins, including Adobe Flash, preinstalled. And all of this is built on top of Debian, providing instant access to thousands of free applications.

Put simply, it’s the GNU/Linux we would want to use.

The PIXEL desktop on Raspberry Pi

Back in the summer, we asked ourselves one simple question: if we like PIXEL so much, why ask people to buy Raspberry Pi hardware in order to run it? There is a massive installed base of PC and Mac hardware out there, which can run x86 Debian just fine. Could we do something for the owners of those machines?

So, after three months of hard work from Simon and Serge, we have a Christmas treat for you: an experimental version of Debian+PIXEL for x86 platforms. Simply download the image, burn it onto a DVD or flash it onto a USB stick, and boot straight into the familiar PIXEL desktop environment on your PC or Mac. Or go out and buy this month’s issue of The MagPi magazine, in stores tomorrow, which has this rather stylish bootable DVD on the cover.

Our first ever covermount

You’ll find all the applications you’re used to, with the exception of Minecraft and Wolfram Mathematica (we don’t have a licence to put those on any machine that’s not a Raspberry Pi). Because we’re using the venerable i386 architecture variant it should run even on vintage machines like my ThinkPad X40, provided they have at least 512MB of RAM.

Why do we think this is worth doing? Two reasons:

• A school can now run PIXEL on its existing installed base of PCs, just as a student can run PIXEL on her Raspberry Pi at home. She can move back and forth between her computing class or after-school club and home, using exactly the same productivity software and programming tools, in exactly the same desktop environment. There is no learning curve, and no need to tweak her schoolwork to run on two subtly different operating systems.
• And bringing PIXEL to the PC and Mac keeps us honest. We don’t just want to create the best desktop environment for the Raspberry Pi: we want to create the best desktop environment, period. We know we’re not there yet, but by running PIXEL alongside Windows, Mac OS, and the established desktop GNU/Linux distros, we can more easily see where our weak points are, and work to fix them.

Remember that this is a prototype rather then a final release version. Due to the wide variety of PC and Mac hardware out there, there are likely to be minor issues on some hardware configurations. If we decide that this is something we want to commit to in the long run, we will do our best to address these as they come up. You can help us here – please let us know how you get on in the comments below!

Instructions

Download the image, and either burn it to a DVD or write it to a USB stick. For the latter, we recommend Etcher.

Etcher from resin.io

Insert the DVD or USB stick into your PC or Mac, and turn it on. On a PC, you will generally need to enable booting from optical drive or USB stick in the BIOS, and you will have to ensure that the optical drive or USB stick is ahead of all other drives in the boot order. On a Mac, you’ll need to hold down C during boot*.

If you’ve done that correctly, you will be greeted by a boot screen.

Boot screen

Here you can hit escape to access the boot menu, or do nothing to boot through to the desktop.

Spot the difference: the PIXEL desktop on a PC

* We are aware of an issue on some modern Macs (including, annoyingly, mine – but not Liz’s), where the machine fails to identify the image as bootable. We’ll release an updated image once we’ve got to the bottom of the issue.

Persistence

If you are running from DVD, any files you create, or modifications you make to the system, will of course be lost when you power off the machine. If you are running from a USB stick, the system will by default use any spare space on the device to create a persistence partition, which allows files to persist between sessions. The boot menu provides options to run with or without persistence, or to erase any persistence partition that has been created, allowing you to roll back to a clean install at any time.

Disclaimer

One of the great benefits of the Raspberry Pi is that it is a low-consequence environment for messing about: if you trash your SD card you can just flash another one. This is not always true of your PC or Mac. Consider backing up your system before trying this image.

Raspberry Pi can accept no liability for any loss of data or damage to computer systems from using the image.

The post PIXEL for PC and Mac appeared first on Raspberry Pi.

# How to Pi: Halloween Edition 2016

Post Syndicated from Alex Bate original https://www.raspberrypi.org/blog/how-to-pi-halloween-edition-2016/

Happy Halloween, one and all. Whether you’ve planned a night of trick-or-treating, watching scary movies, or hiding from costumed children with the lights off, our How to Pi guide should get you ready for the evening’s festivities. Enjoy!

## Costumes

This is definitely a Pi Towers favourite. The Disco Ball costume by Wolfie uses a drone battery and Raspberry Pi to create, well, a child-sized human disco ball. The video links on the project page seem to be down; however, all the ingredients needed for the project are listed at Thingiverse, and a walkthrough of the wiring can be seen here. Below, you’ll see the full effect of the costume, and I’m sure we can all agree that we need one here in the office.

#### Halloween 2016 Disco Ball

Some aerial shots of Serena’s halloween costume we made. It contains 288 full color LEDs, a dual battery system for power, and a Raspberry Pi B2 running the sequence that was created in xLights.

If you feel ‘too cool’ to fit inside a giant disco ball, how about fitting inside a computer… sort of? The Jacket houses a Raspberry Pi with a monitor in the sleeve because, well, why not?

#### ‘The Jacket’ 2.0 My Cyberp…

lsquo;The Jacket’ 2.0 My Cyberpunk inspired jacket was completed just in time for a Halloween party last night. This year’s upgrades added to the EL tape and 5″ LCD, with spikes, a pi zero and an action cam (look for the missing chest spike).

## Dealing with Trick-or-treaters

Trick or Trivia, the trivia-based Halloween candy dispenser from YouTube maker TheMakersWorkbench, dispenses candy based on correct answers to spooky themed questions. For example, Casper is a friendly what? Select ‘Ghost’ on the touchscreen and receive three pieces of candy. Select an incorrect answer and receive only one.

It’s one of the best ways to give out candy to trick-or-treaters, without having to answer the door or put in any effort whatsoever.

#### Trick Or Trivia Trivia-Based Halloween Candy Dispenser Servo Demo

This video is a companion video to a project series I am posting on Element14.com. The video demonstrates the candy dispensing system for the Trick or Trivia candy dispenser project. You can find the post that this video accompanies at the following link: http://bit.ly/TrickorTrivia If you like this video, please consider becoming out patron on Patreon.

Or just stop them knocking in the first place with this…

#### Raspberry Pi Motion Sensor Halloween Trick

A Raspberry Pi running Ubuntu Mate connected to an old laptop screen. I have a motion sensor hidden in the letterbox. When you approach the door it detects you. Next the pi sends a signal to a Wi Fi enabled WeMo switch to turn on the screen.

## Scary pranks

When it comes to using a Raspberry Pi to prank people, the team at Circuit-Help have definitely come up with the goods. By using a setup similar to the magic mirror project, they fitted an ultrasonic sensor to display a zombie video within the mirror whenever an unsuspecting soul approaches. Next year’s The Walking Dead-themed Halloween party is sorted!

#### Haunted Halloween Mirror

This Raspberry Pi Halloween Mirror is perfect for both parties and pranks! http://www.circuit-help.com.ph/haunted-halloween-mirror/

If the zombie mirror isn’t enough, how about some animated portraits for your wall? Here’s Pi Borg’s Moving Eye Halloween portrait. Full instructions here.

#### Spooky Raspberry Pi controlled Halloween picture

Check out our quick Halloween Project, make your own Raspberry Pi powered spooky portrait! http://www.instructables.com/id/Halloween-painting-with-moving-eyes/

## Pumpkins

We’ve seen a flurry of Raspberry Pi pumpkins this year. From light shows to motion-activated noise makers, it’s the year of the pimped-up pumpkin. Here’s Oliver with his entry into the automated pumpkin patch, offering up a motion-activated pumpkin jam-packed with LEDs.

#### Raspberry Pi Motion Sensor Light Up Pumpkin

Using a Raspberry Pi with a PIR motion sensor and a bunch of NeoPixels to make a scary Halloween Pumpkin

Or get super-fancy and use a couple of Pimoroni Unicorn HATs to create animated pumpkin eyes. Instructions here.

#### Raspberry Pi Pumpkin LED Matrix Eyes

Inspired by the many Halloween electronics projects we saw last year, we tried our own this year. Source code is on github https://github.com/mirkin/pi-word-clock

## Ignore the world and get coding

If you’re one of the many who would rather ignore Halloween, close the curtains, and pretend not to be home, here are some fun, spooky projects to work on this evening. Yes, they’re still Halloween-themed… but c’mon, they’ll be fun regardless!

Halloween Music Light Project – Follow the tutorial at Linux.com to create this awesome and effective musical light show. You can replace the tune for a less Halloweeny experience.

#### Halloween Music-Light project created using Raspberry Pi and Lightshow project.

Uploaded by Swapnil Bhartiya on 2016-10-12.

Spooky Spot the Difference – Let the Raspberry Pi Foundation team guide you through this fun prank, and use the skills you learn to replace the images for other events and holidays.

Whatever you get up to with a Raspberry Pi this Halloween, make sure to tag us across social media on Facebook, Twitter, Instagram, G+, and Vine. You can also check out our Spooky Pi board on Pinterest.

The post How to Pi: Halloween Edition 2016 appeared first on Raspberry Pi.

# Conservancy’s First GPL Enforcement Feedback Session

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2016/10/27/gpl-feedback.html

[ This blog
was crossposted
on Software Freedom Conservancy’s website
. ]

As I mentioned in an earlier blog post, I had the privilege
of attending Embedded Linux Conference Europe (ELC EU) and the OpenWrt Summit
in Berlin, Germany earlier this month. I gave a talk (for which the video is
available below) at the OpenWrt Summit. I also had the opportunity to host
the first of many conference sessions seeking feedback and input from the
GPL Compliance Project for
Linux Developers
.

ELC EU has no “BoF Board” where you can post informal
sessions. So, we scheduled the session by word of mouth over a lunch hour.
We nevertheless got an good turnout (given that our session’s main
competition was eating food 🙂 of about 15 people.

Most notably and excitingly, Harald Welte, well-known Netfilter developer
was able to attend. Harald talked about his work with
gpl-violations.org enforcing his own copyrights in Linux, and
explained why this was important work for users of the violating devices.
He also pointed out that some of the companies that were sued during his
most active period of gpl-violations.org are now regular upstream
contributors.

Two people who work in the for-profit license compliance industry attended
as well. Some of the discussion focused on usual debates that charities
involved in compliance commonly have with the for-profit compliance
industry. Specifically, one of them asked how much compliance is
enough, by percentage?
I responded to his question on two axes.
First, I addressed the axis of how many enforcement matters does the GPL
Compliance Program for Linux Developers do, by percentage of products
violating the GPL
? There are, at any given time, hundreds of
documented GPL violating products, and our coalition works on only a tiny
percentage of those per year. It’s a sad fact that only that tiny
percentage of the products that violate Linux are actually pursued to
compliance.

On the other axis, I discussed the percentage on a per-product basis.
From that point of view, the question is really: Is there a ‘close
enough to compliance’ that we can as a community accept and forget
From my point of view, we frequently compromise
anyway, since the GPL doesn’t require someone to prepare code properly for
upstream contribution. Thus, we all often accept compliance once someone
completes the bare minimum of obligations literally written in the GPL, but
give us a source release that cannot easily be converted to an upstream
contribution. So, from that point of view, we’re often accepting a
less-than-optimal outcome. The GPL by itself does not inspire upstreaming;
the other collaboration techniques that are enabled in our community
because of the GPL work to finish that job, and adherence to
the Principles assures
that process can work. Having many people who work with companies in
different ways assures that as a larger community, we try all the different
strategies to encourage participation, and inspire today’s violators to
become tomorrow upstream contributors — as Harald mention has already
often happened.

That same axis does include on rare but important compliance problem: when
a violator is particularly savvy, and refuses to release very specific
parts of their Linux code
(as VMware did),
even though the license requires it. In those cases, we certainly cannot
and should not accept anything less than required compliance — lest
companies begin holding back all the most interesting parts of the code
that GPL requires them to produce. If that happened, the GPL would cease
to function correctly for Linux.

After that part of the discussion, we turned to considerations of
corporate contributors, and how they responded to enforcement. Wolfram
Sang, one of the developers in Conservancy’s coalition, spoke up on this
point. He expressed that the focus on for-profit company contributions,
and the achievements of those companies, seemed unduly prioritized by some
in the community. As an independent contractor and individual developer,
Wolfram believes that contributions from people like him are essential to a
diverse developer base, that their opinions should be taken into account,
and their achievements respected.

I found Wolfram’s points particularly salient. My view is that Free
Software development, including for Linux, succeeds because both powerful
and wealthy entities and individuals contribute and collaborate
together on equal footing. While companies have typically only enforce the
GPL on their own copyrights for business reasons (e.g., there is at least
one example of a major Linux-contributing company using GPL enforcement
merely as a counter-punch in a patent lawsuit), individual developers who
join Conservancy’s coalition follow community principles and enforce to
defend the rights of their users.

At the end of the session, I asked two developers who hadn’t spoken during
the session, and who aren’t members of Conservancy’s coalition, their
opinion on how enforcement was historically carried out by
gpl-violations.org, and how it is currently carried out by Conservancy’s
GPL Compliance Program for Linux Developers. Both responded with a simple
response (paraphrased): it seems like a good thing to do; keep doing
it!

I finished up the session by inviting everyone to
the join
the principles-discuss
list, where public discussion about GPL
enforcement under the Principles has already begun. I also invited
everyone to attend my talk, that took place an hour later at the OpenWrt
Summit, which was co-located with ELC EU.

In that talk, I spoke about a specific example of community success in GPL
enforcement. As explained on the
OpenWrt history page,
OpenWrt was initially made possible thanks to GPL enforcement done by
BusyBox and Linux contributors in a coalition together. (Those who want to
hear more about the connection between GPL enforcement and OpenWrt can view
my talk.)

Since there weren’t opportunities to promote impromptu sessions on-site,
this event was a low-key (but still quite nice) start to Conservancy’s
planned year-long effort seeking feedback about GPL compliance and
enforcement. Our next
session is
an official BoF session at Linux Plumbers Conference
, scheduled for
next Thursday 3 November at 18:00. It will be led by my colleagues Karen
Sandler and Brett Smith.

# How Different Stakeholders Frame Security

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2016/10/how_different_s.html

Josephine Wolff examines different Internet governance stakeholders and how they frame security debates.

Her conclusion:

The tensions that arise around issues of security among different groups of internet governance stakeholders speak to the many tangled notions of what online security is and whom it is meant to protect that are espoused by the participants in multistakeholder governance forums. What makes these debates significant and unique in the context of internet governance is not that the different stakeholders often disagree (indeed, that is a common occurrence), but rather that they disagree while all using the same vocabulary of security to support their respective stances. Government stakeholders advocate for limitations on WHOIS privacy/proxy services in order to aid law enforcement and protect their citizens from crime and fraud. Civil society stakeholders advocate against those limitations in order to aid activists and minorities and protect those online users from harassment. Both sides would claim that their position promotes a more secure internet and a more secure society — ­and in a sense, both would be right, except that each promotes a differently secure internet and society, protecting different classes of people and behaviour from different threats.

While vague notions of security may be sufficiently universally accepted as to appear in official documents and treaties, the specific details of individual decisions­ — such as the implementation of dotless domains, changes to the WHOIS database privacy policy, and proposals to grant government greater authority over how their internet traffic is routed­ — require stakeholders to disentangle the many different ideas embedded in that language. For the idea of security to truly foster cooperation and collaboration as a boundary object in internet governance circles, the participating stakeholders will have to more concretely agree on what their vision of a secure internet is and how it will balance the different ideas of security espoused by different groups. Alternatively, internet governance stakeholders may find it more useful to limit their discussions on security, as a whole, and try to force their discussions to focus on more specific threats and issues within that space as a means of preventing themselves from succumbing to a façade of agreement without grappling with the sources of disagreement that linger just below the surface.

The intersection of multistakeholder internet governance and definitional issues of security is striking because of the way that the multistakeholder model both reinforces and takes advantage of the ambiguity surrounding the idea of security explored in the security studies literature. That ambiguity is a crucial component of maintaining a functional multistakeholder model of governance because it lends itself well to high-level agreements and discussions, contributing to the sense of consensus building across stakeholders. At the same time, gathering those different stakeholders together to decide specific issues related to the internet and its infrastructure brings to a fore the vast variety of definitions of security they employ and forces them to engage in security-versus-security fights, with each trying to promote their own particular notion of security. Security has long been a contested concept, but rarely do these contestations play out as directly and dramatically as in the multistakeholder arena of internet governance, where all parties are able to face off on what really constitutes security in a digital world.

We certainly saw this in the “going dark” debate: e.g. the FBI vs. Apple and their iPhone security.

# Doom scale

Post Syndicated from Eevee original https://eev.ee/blog/2016/10/10/doom-scale/

I’ve been dipping my toes into Doom mapping again recently. Obviously I’ve done it successfully once before, but I’m having trouble doing it a second time.

I have three major problems: drawing everything too small, drawing everything too rectangular, and completely blanking on what to do next. Those last two are a bit tricky, but struggling with scale? That sounds like a problem I can easily solve with charts and diagrams and math.

## Some fundamental metrics

Doom’s mapping rules and built-in textures offer a few fixed reference points.

The z planes — floor and ceiling — are a 64×64 grid anchored at the origin. All “flat” textures are aligned to this grid. (ZDoom lets you rotate, scale, and offset flats, but in vanilla Doom, you sometimes have to design architecture around texture alignment.)

All actors (objects) are square and axis-aligned. Doomguy is 32×56. However, it’s very difficult for an actor to move down a corridor of the same width, and the axis-alignment means a 32-unit square couldn’t fit down a 32-unit diagonal hallway. (It’s rare to see a hallway narrower than 64 or a room height shorter than 64.)

The viewport is 41 pixels above the ground. Doomguy’s maximum step height is 24, which is actually fairly large, almost half his height. Doomguy can balance on a ledge of any width.

The vast majority of Doom’s wall textures are 64×128. A few larger textures are 128×128, and a handful of very large outdoor textures are 256×128. A few “strut” textures and door borders are 8 or 16 wide. Some interesting exceptions:

• DOOR3, the door you appear to have entered from in many Doom maps, is 64×72. So is DOOR1. EXITDOOR has some extra stuff on it, but the actual door part is also 64×72.
• BIGDOOR1, the silver door with the UAC logo on it, is 128×96.
• MIDBARS3 is a railing texture that’s 64×72.
• The Icon of Sin is built out of a 3×3 grid of textures. The full image is 768×384.
• EXITSIGN is 64×16, though only half of it is the actual part that says “EXIT”; the rest is the sides of the sign.
• The STEP textures are all 16 high.

Since Doom’s textures tend to be 128 tall, we can conclude that a standard room tends to be no more than 128 tall. Any more and the texture would start to tile, which works poorly with a lot of textures.

## The problem

Vertical distance is fine. Doom doesn’t have a lot of vertical movement, so vertical distances tend not to get too outlandish in the first place.

The trouble is that I don’t know how big spaces are. I draw rooms and they turn out, much later, to be far too cramped. I draw buildings and outdoor areas and they turn out to not really have enough space to fit everything I want.

An obvious approach is to find a conversion between Doom units and real-world units, then judge distances based on real-world units. That sounds great, but I don’t have a good sense of real-world units, either. How big is the room I’m in now? Somewhere between ten and a hundred feet, I guess? Thirty? How much is thirty feet, is that a lot?

How long is my car, say? I guess two of me could lie down end-to-end beside it, so that’s twelve feet? That sounds like I’m underestimating. Fifteen? Are these reasonable guesses? I don’t know.

Hm, well. The answer turns out to be exactly halfway between at thirteen and a half feet, so I don’t know what we’ve learned here exactly.

Okay, so let’s consider in terms of architecture. How long is the quiet residential street in front of my house? I have no idea. The next biggest thing is a house, and I don’t know how wide a house is, or how many houses there are on this street. I could estimate the street in terms of house lengths, and estimate a house in terms of car lengths, and estimate a car length in terms of my height, but that’s enough wild guesses that the final answer could be a whole order of magnitude off.

I never have any reason to appreciate or internalize length measurements, especially moderately large ones. I have no reference point.

Also, Doom’s grid and texture sizes mean that everything is done in multiples of powers of two. I know the powers of two, but I don’t actually know every single multiple of 64 up to 32768, so I occasionally run into the problem that the numbers lose all meaning. How many 64s are in 768, again…?

## Also, Doom doesn’t make any sense

The other problem with relating to real-world sizes is that it assumes there’s a way to convert between Doom and the real world. Alas, the universe of Doom has much more in common with the exaggerated and cartoony scale of platformers than with the hyper-realism in modern shooters.

Consider Doomguy. Here’s his default forward-facing sprite, PLAYA1. The pink area is his 32×56 collision box, the red dot is where he fires from, and the yellow dot is the location of the viewport.

The collision box is the same height as the sprite itself, but it gets shifted upwards slightly because of the sprite offsets. (Every sprite has an offset indicating where its bottom center is, since that’s where the game tracks an object’s position. If Doomguy’s sprite were just drawn from the bottom, he’d look like he were standing on his tiptoes.)

It is generally accepted — by which I mean “Doom Wiki says so” — that 32 units of height correspond to one meter (39”), which makes Doomguy about 5 feet 8 inches tall. It also makes him one meter wide, which seems rather extreme. The usual handwave is to say that vertical and horizontal scales are different (because pixels weren’t square in the original game), so 32 units of width correspond to ¾ of a meter (just shy of 30”).

That doesn’t really make sense to me. If the architecture were truly distorted to compensate for the pixel size, then surely wall textures would be, too. They aren’t. Switches are perfect 32×32 squares. Several floor textures also exist separately as wall textures, and they weren’t distorted in any way. This is a cute explanation that neatly ties together several bits of Doom trivia, but I don’t think it was a deliberate design decision.

Plus, according to this sprite, Doomguy’s collision box is significantly wider than his actual appearance. I don’t know why this is — perhaps the extra space is where he keeps his hundred rockets and half a dozen spare weapons. If we’re interested in aesthetics, surely we should be going by Doomguy’s sprite rather than his in-game dimensions.

More importantly… this weird ratio still doesn’t jive with most architecture. Consider the fast skinny doors introduced in Doom II, which are 64×128. At 32u = 1m, those are two meters wide and four meters tall, or 78” × 157”. The Internet tells me that an interior residential doorway is around 32” × 80” (2:5), and a human being is around 18” × 69” (~1:4).

Here are those measurements alongside the supposed sizes of Doomguy and a skinny door. Something seems slightly off.

The light blue boxes are the collision boxes; the dark blue boxes are Doomguy’s apparent visible size. I’m using his waist rather than his shoulders, because most people’s (or at least, my) shoulders are not too much wider than their hips — however Doomguy is a beefcake carved out of pure muscle and doors would not be designed for him.

It seems as though all the architecture in Doom is about twice the size it should be, for whatever reason. Look what happens if I shrink the door, but not Doomguy:

If I use some ZDoom shenanigans to shrink a door within the game, it looks rather more like a real door. (You’d have a hard time fitting through it without modifying the player’s radius, though.)

It’s not just architecture! Keycard sprites are 14×16, which would be about a foot and a half square. The shotgun is 63 pixels long, a whopping 77”. A shotgun shell is 7 pixels long, almost 9”. The candelabra is 61 pixels tall — taller than Doomguy! — which is just over six feet. This is ridiculous. Halving all of these lengths makes them closer to something reasonable.

It appears, for whatever reason, that the world of Doom is roughly twice the size of the world we’re used to. (Or perhaps Doomguy has been shrunk by half.) That matches my attempts at replicating real-world places to scale — they turned out unusually cramped.

64 units equal 1 meter, then. Problem solved.

Ah, well, about that. The 64×128 doors make sense, but… real doorways don’t span the full height of a room, yet many Doom rooms are 128 tall. Or less. The starting area in E1M1, the hallway in MAP01, and the DOOR1 entrance” door are all 72 units tall, which converts to less than four feet.

Let’s try something else. Tom Hall says in the Doom Bible that the 128-unit walls in Wolfenstein 3D were eight feet thick, i.e. 16 units equal 1 foot. The 64-unit grid is thus four feet, which seems reasonable. The maximum step height would be 18 inches, and shallow steps would be 6 inches, which also seem reasonable — the stairs in my house are 7” tall, and the most I can comfortably step up is 3 at a time.

But this still makes those 72-unit rooms be only four and a half feet tall.

This isn’t a problem that can be solved with different height and width scaling, because we’ve come down to a conflict between door/room height and step height. If those 72-unit rooms are a more reasonable eight feet tall (the standard) then 9 units are 1 foot, and Doomguy’s step height is over two and a half feet. Also, those 64×128 doors are over nine feet tall.

The fact is, Doomguy has goofy proportions, and the environment was designed around them. The textures have a gritty semi-realistic aesthetic, but comparing the levels to real-world architecture makes about as much sense as designing Mario levels around real places. Actual humans cannot jump several times their own height, so the design language doesn’t translate at all.

## Better reference points

If I can’t use the real world to get a sense of scale, I might as well use Doom itself.

I’ve gone through some large areas that are particularly memorable to me, areas that I have a good sense of, and measured their dimensions.

However, I’ve tried using a new kind of unit: Doom grid cells. All of the numbers in parentheses are counts of 64-unit cells (for horizontal units only). It turns out to be much easier to grapple with 22 vs 24 than 1408 vs 1536.

• E1M1: Hangar

The iconic starting room is 640×768 (10×12) and 72 tall. The recessed area in the middle is 448×320 (7×5) and 216 tall.

• E3M8: Dis

The entire shuriken fits in a 3712×3584 (58×56) box. The sky is 256 units above the inner part of the ground.

• MAP01: Entryway

The opening room is 640×448 (10×7) and 256 tall. The subsequent hallway is 128 (2) wide and 72 tall.

The large room before the exit is 960 (15) deep and 192 tall. Wow! I always think 1024 (16) sounds really huge, but this one humble room is almost that big.

• MAP02: Underhalls

The entire area with the little brick “house” is 576×896 (9×14), measured from the water. The surrounding walkway is 88 tall; the grass is 216 below the sky.

The whole map fits in a 1920×1920 (30×30) box.

• MAP03: The Gantlet

The main large outdoor area is carved from a 1664×832 (26×13) rectangle. The water is 264 below the sky.

The entire starting area just about fits in a 704×704 (11×11) box. The hallway is 128 tall; the center room is 160 tall.

The inner part, including the walkway, is 1536×1472 (24×23). The outdoor parts are 120 tall; the roof is 80 above the walkway.

• MAP08: Tricks and Traps

The starting room is 448×448 (7×7) and 192 tall.

The cacodemon room is 448 (7) wide, 1792 (28) from the door to the far wall, and 288 tall.

The cyberdemon room is roughly 896×448 (14×7) and varies between 96 and 128 tall.

The room you teleport to with the pain elementals is 704×704 (11×11) and 144 tall.

• MAP12: The Factory

The entire map is 3776×4288 (59×67). Outdoors is 208 tall. The outer wall is 96 tall, and the main raised outdoor part is 80 high, 128 below the sky.

The main “factory” interior is 2560×1536 (40×24).

• MAP14: The Inmost Dens, the most detailed map in Doom II

Water to sky is 200, and the floor is 16 above the water. The brick wall surrounding everything is 32 high. The pillars between areas are 88 tall.

The entire map fits in a 3520×3904 (55×61) box.

• MAP15: Industrial Zone

Ground to sky is 600.

The central structure — the one you jump off to reach the other side of the map — is 1600×1600 (25×25).

The entire map, excluding the purely aesthetic waterfront, fits in a particularly pleasing 4416×6144 (69×96) box.

• MAP18: Courtyard

The grassy courtyard itself is, very roughly, 2112×1920 (33×30). Grass to sky is 192.

The surrounding area with the columns is 576 (9) at its deepest.

The separate cacodemon area with the blue key is 768×1216 (12×19) and 272 tall.

• MAP23: Barrels o’ Fun

The starting hallway is 2240 (35) long, 384 (6) wide, and 256 tall.

The blood pit is 960×1024 (15×16) and a whopping 384 tall. The hallways leading to it are 64×528 (1×8¼) and 80 tall.

• MAP27: Monster Condo

The starting area plus library form a rough 2624×1728 (41×27) rectangle. The other main area plus pain elemental room form a rough 2432×1600 (38×25) rectangle. Both are 128 tall.

The twin marble rooms are about 576×1024 (9×16), not counting the 128 (2)-deep closets on the sides and backs. Total height is 256, and the walkway is 80 above the floor.

• MAP29: The Living End

The huge central blood pit is 3072×2816 (48×44) and a whopping 696 tall, which is almost five and a half 128s. The platform you first see it from is 200 above the floor.

The central exit slab is 1216×1216 (19×19).

• MAP30: Icon of Sin

The main area is 2688×1728 (42×27) and 768 tall. Each platform is 128 above the next. Pressing the switch up top raises the lift by 512, or four 128s.

• MAP32: Grosse

The main room is a 2176×2944 (34×46) rectangle, plus a 1024 (16)-deep lead-in bit.

It might help to know that the player’s maximum run speed is about 583 units per second… or just over 9 grid cells per second. With straferunning, it’s about 11⅔ grid cells.

I also ran all of these maps through a slightly modified wad2svg and combined them into a single image, depicting all of them at the same scale. (If you like, I also have a large SVG version.)

One pixel is 16 Doom units; four pixels are 64 units or one grid cell; the grid lines mark 1024 units or 16 grid cells. The player can run across one grid cell in 1.8 seconds, or 1.4 seconds when straferunning.

I don’t know if I’ve absorbed anything intuitively from this yet, but it’ll give me something to refer back to the next time I try to map. Seeing that the entirety of Underhalls just about fits inside the Icon of Sin room, for example, is downright fascinating and says a lot about the importance of breaking space up.

Ah, you got me, this whole post was an excuse to list those dimensions and make a collage of Doom maps.

## Postscript

What if I fixed the player size?

Assuming Tom Hall is correct that 1 real-world foot is equal to 16 Doom units, a six-foot-tall Marine should be 96 units tall. With the magic of ZDoom, I can make that happen. I can also fix the heights of the humanoid enemies.

The results are pretty hilarious. Highly recommend running around for a bit with one of these. Hint: you may want to bind a key to “crouch”.