Editing 2916: Machine

{{comic
| number    = 2916
| date      = April 5, 2024
| title     = Machine
| image     = machine_2x.png
| imagesize = 740x740px
| noexpand  = true
| titletext = The Credible Machine
}}
* To experience the interactivity, visit the [https://xkcd.com/2916/ original comic].

==Explanation==
{{incomplete|Created by a WELL OILED ROBOT. Do NOT delete this tag too soon.}}
This interactive game is the 14th [[:Category:April fools' comics|April fools' comic]] released by [[Randall]]. The previous April fools' comic was [[2765: Escape Speed]] from 2023, which was released on Wednesday, April 19, 2023. "Machine" has been updated multiple times in the weeks following its release, adding the following features:
* the trophy and shot glass props
* the cat, which swats balls in front of it
* the inanimate cat and bunny decorations
* the system of links, which encodes the XY coordinates of the currently viewed cell, and the time (i.e. the entire machine's state after a certain moderation action)


As referenced in the title text, this game is a spiritual successor to the 1990s and early 2000s PC puzzle game series {{w|The Incredible Machine}}, a game Randall played as a kid. Both games have several objects in common:
* fan
* cat
* ramps
* balls of varying densities

The comic starts in a main screen where the user can create a {{w|Rube Goldberg machine}} in a "Cell" where the goal is to route a constant stream of colored balls from inputs on the ceiling or walls to outputs of matching colors on the walls or floor. After the comic is first opened a window pops up over the machine where Cueball in a lab coat tells you to route the balls from the inputs to the outputs. A button opens a “tool panel” where there are large and small boards available for use, as well as some gimmicky stuff like prisms<!-- that sort marbles by color SEEM TO 'RANDOMLY' REFRACT/DEFLECT, IF SORTING IS TRUE THEN EXPLAIN IN NEW/RELOCATED SECTION? --> (which deflect marbles) and fans (which blow marbles around), plus decorative elements which have no effect on the balls.

Typically, inputs and outputs only accept balls of a single color. However, some outputs accept multiple colors, indicated by a double arrow, and some inputs produce multiple colors. When the player is designing their 'machine', this will involve multiple full streams merged into one (supplied by a double-exit on the adjacent submission). Machines now working in the full grid may, however, find that their sources now contain stray balls of other types that were not handled properly, but there is no way to force a re-edit of the machine to alter its behavior to account for this.

If any balls are left in your cell for more than 30 seconds, they fade away. The first time a ball fades away another popup informs you that the balls are removed for security reasons. An indicator next to each exit increases for each ball of the correct color that passes through an exit, and reduces when no balls pass through, or if balls of the wrong color pass through it. While that exit is not properly supplied it displays a red cross, which changes to a green tick when a sufficient, and sufficiently clean, stream of balls is supplied. The first time you have built a machine which succeeds in routing enough balls of the correct color to ''all'' relevant outputs, a popup will prompt you to submit your cell to be added to the public machine. (Subsequently, the submit button will quietly change from 'inactive' (pale) to clickable (dark). This will change back again if any ball transfers dip back below the required threshold for any reason, such as further editing or an end to a 'fluke' glut of accumulated balls.)

Choosing to submit your cell will give you a textbox to give this cell a name. Proceeding through that, you will now see your cell within the 'grid' and a 'live' feed of balls from any relevant neighboring cells (which may be more sporadic then the feed you designed your cell with, and contain stray balls of different types). If any supplying-neighbors are still marked as "under construction", they ''may'' provide the balls as if perfectly routed from their own (eventual) source, but will eventually dry up. If your newly submitted creation is placed in the lowest row of cells, balls will be dispensed through the exit at the bottom, but there will be no launcher to propel them towards the pit, and they will vanish as they leave the exit.

Upon reopening the link to this comic without coordinate and time parameters, your recently created machine will most likely not be visible in the space you built it in. [https://www.reddit.com/user/xzaphenia/comments/ Reddit user xzaphenia] has claimed on r/xkcd that this is because there is a moderation team (of which they are a member) and that [https://www.reddit.com/r/xkcd/comments/1c1ixmb/comment/kzc3rmg/ the main page only shows public, approved machines]. This team of people, including those credited as co-creators of this comic, select machines according to their preferences (and little to no formal criteria besides [https://www.reddit.com/r/xkcd/comments/1c0sp60/comment/kz6hbgl/ coolness, innovativeness, effectiveness], and [https://www.reddit.com/r/xkcd/comments/1c0bsk2/comment/kyvfean/ privacy concerns]). Given the number of 'bottom-layer' cells that are likely primed ready to be completed (e.g. the grid-width of twelve, perhaps staggered across adjacent rows) and the many possible worldwide contributors at any one time, it may be that the chances of being picked for permanence is low; and certainly would have been lower early on in the comic's existence during the initial frantic rush to participate. [https://www.reddit.com/r/xkcd/comments/1c0sp60/comment/kz6hbgl/ It is also claimed that at some point, moderation will be cut off and the machine will be considered "complete"].

<gallery heights="200" widths="150">
File:2916_popup_intro.png|Introduction popup
File:2916_popup_time.png|Time limit popup
File:2916_popup_submit.png|Submission popup
</gallery>

The button in the bottom right corner allows you to toggle between editing your own machine and a page where you can drag around to view all of the machines that have been submitted and accepted, with a title for each in the upper left corner. In this view you can see that all of the outputs are also inputs for another cell, except for the top row where the inputs come from off screen and the lowest row which output through a launcher of some kind to a set of four colored-coded containers far below. Any empty cells are marked off by yellow tape with the words "UNDER CONSTRUCTION" as well as "DJIA ↑ 31415" once in each cell. "DJIA" stands for the Dow Jones Industrial Average, with "DJIA ↑ 31415" indicating that it rose to 31415 points, 31415 being the first five digits of pi, without the period. This would often be displayed on a yellow 'ticker', which might look superficially similar to the yellow barrier tape.

When viewing the whole machine, a button in the bottom left corner, added later, allows you to follow the path of the nearest ball as it passes from cell to cell. This will also make the ball you are following immortal - not subject to the 30s timeout rule. Another later addition was a button in the top left corner which copies a URL that will take you directly to the current cell that you are viewing. However, the link that is created will always show you the version of the machine at the time that you were viewing it, without any subsequent additions.

Whenever balls reach the bottom of the grid, they are directed towards four containers, one of each color. Most balls are accurately sent to their appropriate container, though there are some misfires. These containers are above a pit, and periodically dump their contents. Balls in the pit are subject to the same 30s culling rule as balls in the cells above. If no balls are directed towards the containers, the pit will be empty. If one or two streams of balls are making it, Cueball and Megan sit in a small boat named the USS Buoyancy, and when sufficient balls are being deposited, the boat begins to float and move. More streams of balls are likely to add more changes. Balls which miss or overspill the pit fall out of the bottom of the frame.

Under construction cells will feed balls of the appropriate color into neighboring cells so long as you are not looking at them. Once you scroll to look at them, the supply of balls stops and subsequent cells in the chain will not receive any; scroll away from them again and the supply will resume.

The grid is 12 cells wide, and grows in height. The largest size observed so far is 12x65, for a total of 780 cells. The machine's height is determined by the lowest cell; This can be either your submitted cell, or a cell created by another user.

Imperfections in the machines (whether accidental or by design) and the impossibility of entirely avoiding collisions when crossing streams inevitably lead to significant levels of losses and pollution with the wrong color balls. Indeed, using the follow ball function appears to demonstrate that it is quite rare for a ball to survive more than several machines without getting stuck somewhere. This should mean that effectively no balls would reach the lower layers. This implies that there is some 'creative accounting' going on to ensure that cells lower in the grid still have balls to process - simulating flow only for a few nearby cells, while assuming that those cells themselves have pure, steady inputs.

There is a hard limit of 100 items (both physically interactive and purely decorative) that can be placed in any given arena. If you have placed 75 items, a count will appear in the component bar of your piece-count ("''##''/100"), which will go away again if you delete items to bring it below this count. The count text turns red at "100/100", at which point no more items can be added, only existing ones moved (or removed, to lower the count again).

===Toolbox items===
{| class="wikitable" style="margin:auto"
|+ List of objects
|-
! Description !! Effect !! Image
|-
| Plank || Static obstacle || [[File:2916_plank.png|frameless|upright=0.25]]
|-
| Hammer || Static obstacle || [[File:2916_hammer.png|frameless|upright=0.25]]
|-
| Sword || Static obstacle || [[File:2916_sword.png|frameless|upright=0.25]]
|-
| Hinged scoop<sup>&dagger;</sup> || Rotates around its hinge, tries to stay horizontal with a springy effect || [[File:2916_scoop.png|frameless|upright=0.25]]<br>[[File:2916_scoop_mirrored.png|frameless|upright=0.25]]
|-
| Anvil || Static obstacle || [[File:2916_anvil.png|frameless|upright=0.125]]
|-
| Brick || Static obstacle || [[File:2916_brick.png|frameless|upright=0.125]]
|-
| Fan || Blows away balls in front of it. Different colors are affected by differing amounts (yellow balls are lightest, and can be levitated above an upward-facing fan).|| [[File:2916_fan.png|frameless|upright=0.125]]
|-
| Pillow || Balls will not bounce if they hit it || [[File:2916_pillow.png|frameless|upright=0.125]]
|-
| Bumper || Bounces balls away at significantly higher speed || [[File:2916_round_bumper.png|frameless|upright=0.125]] [[File:2916_bumper_left.png|frameless|upright=0.125]] [[File:2916_bumper_right.png|frameless|upright=0.125]]
|-
| Attractor/Black Hole<sup>*</sup> || Pulls balls toward center || [[File:2916_attractor.png|frameless|upright=0.125]]
|-
| Repulsor/White hole<sup>*</sup> || Repels balls away from center || [[File:2916_repulsor.png|frameless|upright=0.125]]
|-
| Prism || "Refracts" and internally-reflects balls as they otherwise pass through the object, the color of the ball ''may'' cause them to react (as much as possible) according to the respective color across the element.<!-- Benefit of the doubt, but it hasn't seemed to work that well for me, either. --> || [[File:2916_prism.png|frameless|upright=0.125]]
|-
| Wheel<sup>&Dagger;</sup> || Spins, deflects balls, can jam with enough resistance (e.g. glut of balls or against other elements). || [[File:2916_wheel.png|frameless|upright=0.125]]
|-
| "Good job" trophy || Static obstacle || [[File:2916_trophy.png|frameless|upright=0.125]]
|-
| Glass cup || Static obstacle. Container, with a nominal capacity of up to four balls (in whole or in part) within it. || [[File:2916_cup.png|frameless|upright=0.125]]
|-
| Cat || Swats away balls in front of itself (was added later) || [[File:2916_cat_new.png|frameless|upright=0.25]]
|-
! colspan="3" style="text-align:center" | Non-physical items
|-
| Right-facing Ponytail, with raised arms || Intangible decoration || [[File:2916_ponytail_arms.png|frameless|upright=0.125]]
|-
| Right-facing Ponytail, standing || Intangible decoration ||  [[File:2916_ponytail.png|frameless|upright=0.125]]
|-
| Left-facing Cueball, with raised arms || Intangible decoration ||  [[File:2916_cueball_arms.png|frameless|upright=0.125]]
|-
| Left-facing White Hat, standing || Intangible decoration ||  [[File:2916_whitehat.png|frameless|upright=0.125]]
|-
| Rightwards-facing Knit Cap, in an 'action' pose || Intangible decoration ||  [[File:2916_knitcap_resting.png|frameless|upright=0.25]]
|-
| Right-facing Knit Cap, standing || Intangible decoration ||  [[File:2916_knitcap.png|frameless|upright=0.125]]
|-
| Helmet-wearing figure, standing || Intangible decoration || [[File:2916_helmet.png|frameless|upright=0.125]]
|-
| Squirrel || Intangible decoration || [[File:2916_squirrel.png|frameless|upright=0.125]]
|-
| "Probably Deterministic" sign || Intangible decoration || [[File:2916_deterministic.png|frameless|upright=0.25]]
|-
| [[1682: Bun|Bun]] || Intangible decoration || [[File:2916_rabbit.png|frameless|upright=0.125]]
|-
| Cat || Intangible decoration || [[File:2916_cat.png|frameless|upright=0.125]]
|}

:<nowiki/>* &mdash; The Attractor and Repulsor are omnidirectional, but the area of effect can be resized to extend or restrict its influence. You do this by way of its bounding box with corner and mid-edged 'drag nodes' and a circular area that shows the current extent, which are only visible when the element is actively selected. This resize can be no larger than will make the box/circle touch the edges, no smaller than the fixed graphic and will always be identically proportioned in both axes.

:&dagger; &mdash; The hinged scoops are strictly horizontal, on building. They will rotate away from and (spring back to) horizontal according to interactions with balls or other non-decorative items that may be placed to disturb their balance, sometimes with further interesting interactions (that may or may not be intentional or useful). There are two selectable versions of this item. (The only ''other'' object class with a clear (and practical) asymmetry, for which a mirrored chirality can be chosen from the sidebar, are the two versions of triangular "Bonk"-bumpers.)

:&Dagger; &mdash; The wheel is an actively rotating element that starts off, by default, spinning anticlockwise. Pressing or tapping left/right arrow keys, when a placed wheel is selected, will adjust that wheel's rotation rate to be more/less anticlockwise. Adjusting it beyond zero rotation allows you to make it spin in the opposite direction.
:Rotation can be increased well beyond the point at which the {{w|wagon-wheel effect}} occurs<!-- does it depend upon browser rendering frequency, or is there a convenient refresh-cap-rate built into the rendering engine? -->, which may make it difficult to work out the spin direction of an overspeed wheel element (and thus which arrow keys will slow or speed up its rotation, if you have forgotten), though observing its impact upon any balls that strike it ''should'' make its current spin-direction obvious.
:The 'bounding editing box' will usually appear rotated, possibly according to the spinning graphic's current orientation upon selection, but remains at that (often non-orthagonal) angle even as the wheel spins (if it can) during this period of selection for editing. 

All other items can be manually re-angled by a 'loop node' arm extending from the bounding box. If you cannot see the 'angle node' for such a selected item, which is normally at the top of any freshly placed item but follows any re-angling that may have already applied, it could be that you have placed the item too close to the edge in which direction the node extends. To rotate it, move the object away from the edge to access the construction node (after which, you can drag the object back if required – but see below).

Rotation may be limited by the {{w|minimum bounding box}} that is the 'selection box', this is not necessarily the more flush {{w|convex hull}} of the collision-map built into the graphic. Should a corner of the bounding box need to move across the edge of the build-area, it will do nothing more than touch the edge until there is sufficient angle-drag to snap it to the angle from which that corner now comes back away from the edge; or, when it has a long straight edge currently flush with the edge boundary, it may snap to exactly 180°, in rotation, whereupon the opposite long straight edge is flush to the construction area edge. All objects that are drag-moved, similarly, cannot be moved any further than their current bounding box touching the construction-area edging. The bounding box for the rotating wheel is a notable exception to this, being not under any direct angle-control by the player. Instead, it seems to use the bounding inscribed circle that defines the wheel edge iteslf.

Apart from some interactions between the hinged scoops and any element (including other hinged scoops), there is no preventative 'collision detection' between objects during user-placement, which may overlap/cover each other (the most recently spawned item graphically overlays any earlier one). The wheel object will only spin if not constrained by other physical elements (including the spokes of an adjacent wheel, not in counter-rotation) but can still be dragged and placed anywhere within the boundary of the construction area.

The continuous stream(s) of balls respect all ''tangible'' objects, which includes any currently being dragged/rotated, though may prematurely vanish if forced between two items moved to touch/overlap each other. It is possible to to indirectly nudge balls by carefully moving a tangible object's surface into them (or holding them within it, e.g. the "cup"). This may be useful for rescuing temporarily stray balls (before they time-out anyway), unjamming an area with a construction-induced glut ''or'' for testing a ball-path that is not currently being fed 'naturally'. Doing so ''can'' then conceivably fulfil all the exit-gate requirements (temporarily), as it might also transiently spoil some required routing, but the manual intervention will not be possible once a 'machine' has been submit.

===Non-player items===

Ball containers at the bottom of the machine
{|
|[[File:2916_container_red.png|thumb|center|50px]]
|[[File:2916_container_yellow.png|thumb|center|50px]]
|[[File:2916_container_blue.png|thumb|center|50px]]
|[[File:2916_container_green.png|thumb|center|50px]]
|}

Cueball and Megan in the ''USS Buoyancy''
[[File:4d425c.png|thumb|left|150px]]
<br clear=all>

Pit below the ''USS Buoyancy'' (not to scale)
[[File:2916_pit_bottom.png|thumb|left|300px]]
<br clear=all>

=== Color routing ===
The different ball colors have different physical properties. Red balls are more bouncy than other balls, green balls are heavier, and yellow balls are lighter and slightly bouncy. The following values were extracted from the code:
{| class="wikitable sortable"
! Color
! Mass
! Density
! Restitution (bounciness)
! Linear damping (drag)
|-
! data-sort-key="00F" | Blue
| 0.08
| 1
| 0
| 0
|-
! data-sort-key="F00" | Red
| 0.08
| 1
| 0.8
| 0
|-
! data-sort-key="0F0" | Green
| 0.75
| 9.325
| 0
| 0
|-
! data-sort-key="FF0" | Yellow
| 0.024
| 0.3
| 0.6
| 2
|}

For certain combinations of inlet and outlet 'gates', it is necessary to 'cross the streams'. e.g. to direct righthand-entry balls to a lefthand-exit and vice-versa. It is possible to just construct the field to send two (or more!) sets of balls to fly across a common gap, to land on an appropriate reception area that leads to the chosen exit. But, though this is not {{w|Proton pack#Crossing the streams|completely inadvised}}, the timing of the balls cannot be guaranteed to be in sync (or, rather, anti-sync) with each other and collisions ''will'' occur, especially under the variations of delivery that might significantly alter the ballistic path across the gap. Even if the trial machine works, in isolation with a steady stream of all balls entering the field of play, once submitted it will inevitably be fed by a more chaotically-routed preceeding construction.

In order to maintain sufficient correct arrivals at exits<!-- and, I believe, sufficiently few ''wrong'' arrivals... does it enumerate the 'net correct delivery rate' to establish the validity of the output? ...needs more research -->, it may be necessary to add a method of filtering the hues.

This could just mean introducing a 'wrong hue trap' beyond any crossing point(s) that send the occasionally wrong ball back to the cross point (or let them time-out in a dead-end, relying upon few enough failures from the rest of the balls, along with all colliding balls that subsequently missed ''any'' chance of reaching an exit). Alternatively, two (or more) feeds of marbles could be fed through a deliberate 'sorter' that does a sufficiently reasonable job of separating the combined sets out towards their intended target-exits.

The various physical qualities of the balls suggest a number of methods for redirecting separate hues to separate onward journeys. This can be done by isolating a hue from every other hue, then passing on (if necessary) to a setup extracting a different one from the remainder, and perhaps also a third time. It may also be possible to merge 'arrangements' of sorting mechanics to efficiently distribute straight into three ''or even four'' onward tracks towards the desired outputs, but that is left as an exercise to the reader.

<!-- This may not be the most efficient depiction (with just four/less 'core methods', after following "See X/Y"s) but if the Prism or some other item actually adds zignificantly practical pre-"See" differences then the all-vs-all format (with the reversals/same-to-sames still there to be abbreviated/redirected) will come into its own.
If you so wish, redo. e.g. as ";header + :paragraph"s or table of "!Combo(s)!!Methodology"
NB:
  1x ! Row-start Style=                                                 | Row-start 'header'
  4x | *Unwikiparsable key just for editors' benefit* + optional Style= | Contents
...right now, I've mostly added "vertical fan" experiences (which I find useful for all but R/B differentiation), but more about bumpers (including fan-/wheel-collisions), the positive/negative 'force objects' and of course horizontal/angled fans could also be added.
-->
{| class="wikitable"
! style="background-color:black; color:white" | To separate !! style="background-color:lightblue" | Blue !! style="background-color:lightgreen" | Green !! style="background-color:yellow" | Yellow !! style="background-color:red" | Red
|-
! style="background-color:red" | Red
| *R/B* | '''Use 'bounce''''
The sole difference is how much balls will rebound from objects. Well managed and constrained ricochets should allow a sorting action.
| *R/G* | '''Use mass or 'bounce''''
Green balls cannot be levitated by a vertical fan. An incline across any such fan(s) will levitate only non-Greens.<br/>Green, like Blue, rebounds differently to Red. Green balls are also affected by black holes much less than all other balls.
| *R/Y* | ''See Y/B''
| *R/R* style="text-align: center; background-color:black; color:white" | n/a 
|-
! style="background-color:yellow" | Yellow
| *Y/B* | '''All methods'''
Yellow, alone, exhibits high drag against any unforced motion.<br/>It is also unique in all other ways; e.g. can be levitated highest, against all other hues (though most profoundly against Green).
| *Y/G* | ''See Y/B''
| *Y/Y* style="text-align: center; background-color:black; color:white" | n/a
| *Y/R* style="text-align: center; background-color:gray"  | ''See Y/B'' <!-- R/Y->Y/B -->
|-
! style="background-color:lightgreen" | Green
| *G/B* | '''Use mass'''
Green balls cannot be levitated by a vertical fan.<br/>There is also a not so marginal difference in density that might be exploited, such as by using black holes, which only minimally effects Green (perhaps showing an effective difference between mass of attraction and mass of inertia).
| *G/G* style="text-align: center; background-color:black; color:white" | n/a
| *G/Y* style="text-align: center; background-color:gray"  | ''See Y/B'' <!-- Y/G->Y/B -->
| *G/R* style="text-align: center; background-color:gray"  | See R/G
|-
! style="background-color:lightblue" | Blue
| *B/B* style="text-align: center; background-color:black; color:white" | n/a
| *B/G* style="text-align: center; background-color:gray"  | See G/B
| *B/Y* style="text-align: center; background-color:gray"  | See Y/B
| *B/R* style="text-align: center; background-color:gray"  | See R/B
|}

Even when not strictly necessary for one's own submission, once submitted into the full playing grid the player's own contribution may find itself working with less 'pure' delivered ball-streams (from an imperfectly separating feed-in contribution). It is possible that this more interactive disruption can make the new setup behave erratically or even entirely incorrectly.

It might be thought good practice (but not ''necessary'') to deliberately combine any or all inputs and do a full job of splitting them again, just in anticipation of possibly having to deal with such cross-contamination and being able to 'clean up' the onward stream(s) for the benefit of others. This would of course be particularly difficult if the isolated building-phase does not provide all four hues to 'test' against, so any speculatively added filtering would have to be added 'blind' (and only on the offchance that any anticipated incorrect balls will actually enter the arena) and without any legitimate exits to which such rejects could be shunted (therefore could accumulate, up until any 'time out' that might apply to any ball once operational as part of the combined grid).

Single-input/single-output designs might not particularly require ''any'' sorting mechanism, in theory, though the unexpected 'contamination' of the system with balls of different masses/etc could perhaps introduce malfunctioning passage from the added chaos it might succumb to.

==Transcript==
{{incomplete transcript|Do NOT delete this tag too soon.}}

:[The placeholder image shows four balls, colored red, green, yellow and blue, bouncing on top of three white blocks. Text in the center: "[visit xkcd.com to view]"]

:[Cueball with lab coat, intro popup]
:Cueball: Balls falling into your cell should be routed to the outputs at a steady rate.

:[Cueball with lab coat, warning popup]
:Cueball: For security reasons, balls that remain in your device for more than 30 seconds will be removed and destroyed.

:[Cueball with lab coat, submit popup]
:Cueball: Congratulations! Your contraption has passed all tests. Press [submit button] to submit it to be added to the machine!

==Trivia==
Once again an April Fool's Day Comic came out late, as Randall did not release this on April 1st, even though April 1st did fall on a Monday, a normal release day. It first came four days later with the Friday release on April 5th. That this is to be considered an April fools' comic, in spite of the later release, was confirmed on the xkcd Facebook page.

*Randall acknowledges the people who helped him create this comic in a [[Header_text#Machine|comic-specific header text]]. 
**With 11 different involved apart from Randall this is by far the comic with most people involved.
*Some hidden keyboard shortcuts have been found:
** Follow balls: Ctrl + Alt/Option + B (now also accessible by using the button provided)
** Show debug overlay: Ctrl + Shift + Win/Cmd + D
***  This may particularly clash with browser functionality, e.g. Firefox's "New Bookmarks" dialogue which will need closing, though still activating the overlay graphics.
** Delete selected item: Delete (Fn + Delete on Mac)
*When Randall posted a [https://www.facebook.com/TheXKCD/posts/pfbid0Cs97awQZi1ZiaEXouAex9tXrwAS3qJV3RmAiuCq5uvZQwqZVMgDmcqJ7JU9LYodYl link to this comic] on his [https://www.facebook.com/TheXKCD Facebook feed], he directly wrote that it was a late April Fools' Day!
**MACHINE
**Happy Belated April Fool's Day!
**This thus ends any discussion of whether this should be seen as an April Fool's comic or not. 
**It just came out 4 days late. This has also happened several times since [[Garden]].
[[File:2916 Machine Facebook April fools' confirmation.png]]

{{comic discussion}}

[[Category:April fools' comics]]
[[Category:Comics with color]]
[[Category:Dynamic comics]]
[[Category:Comics with animation]] 
[[Category:Interactive comics]]
[[Category:Comics featuring Cueball]]
[[Category:Comics featuring Megan]]
[[Category:Comics featuring Ponytail]]
[[Category:Comics featuring White Hat]]
[[Category:Comics featuring Knit Cap]]
[[Category:Characters with hats]]
[[Category:Squirrels]]
[[Category:Buns]]
[[Category:Cats]]