This is a wiki. DO NOT GRIEF.
Click the box before editing:
DO NOT CHECK THE BOX FOR FUN. If you do, the checked box isn’t real and neither is your sense of safety.
User Assignments
@Kingo’s doing formatting
@Boss_1s is doing generic edits (grammar corrections,spelling errors, minor formatting errors,place holding,getting rid of randomly spawned backticks , ect.) and mini-guiding
@Blackjack’s doing formatting
So I don’t know what I was thinking when I made this; not a good way to start a guide lol.
I think we all know that I am not a device person. I enjoy art and simple mechanics more than I do abstract work. But then I found this topic. One of those “Good Ol’ Discussions”:
I scrolled through the topic and its replies, then compiled a list of all the devices that can be broken down into other existing ones. Those that can be broken down are to be called ‘Constructables’. Those that the constructables are broken down into are the ‘Atoms’ of GKC Devices.
THE PLAN: Make a list of all the ‘Atoms’ and how the other devices (Constructables) can be made from them.
As far as I know, there are 52 released devices in Gimkit Creative, and the discussion in ClicClac’s older topic named 11 of them as “atoms”.
The Atoms
Item granter – Only device that can remove or grant items to a player. This plays a crucial role in most games. Memory: 35
Inventory Item Manager – Works with the ‘Item Granter’ to interact with the player’s inventory; again, it’s the only device that can do what it does. Memory: 215
Button – It’s a unique device that lets you interact and serves almost something close to a GUI if you count blocks, channels, and properties as the real workings behind the game. Memory: 50
Image
[image]
Text – The only convenient way to display words. Memory: 60
Image
[image]
Popup – This one I’m not sure about, because it could actually be a notification with different choices, but as that is impractical (a word I will use instead of impossible) to recreate, I will include the Popup as an atom for now. Memory: 50
Image
[image]
Notification – Sends alerts in-game and can carry block code. It might not be an atom as it is interchangeable with the popup, but it’s more useful as it can carry code. Memory: 15
Image
[image]
Trigger – We love triggers. Honestly my favorite device, it can do almost anything and is way better than a repeater. Memory: 40
Property – Stores data in numerical or word form, and also can be used to update the score in a game instead of knockouts or in-game time. Memory: TBD
Image
[image]
Damager – Deals damage to a player. It can be used instead of something like a laser. Memory: 10
Image
[image]
Questioner – Introduces questions to a game. This one is special because it’s the only one that has some sort of access to the bigger web–if GKC as we know it is a small section of the whole Gimkit website, the questioner is sort of a thin link to the bigger Gimkit website as it accesses sets you can create or borrow from other people. Memory: 250
Image
[image]
Barrier – Blocks off areas and doesn’t let you enter. This one’s a little questionable as you can approximate it with some triggers or just use props, so I may edit it out later. Memory: 20
Image
[image]
Camera Point – Allows players to “detach” the camera from pointing at the player to a different location. Because this can’t be constructed with other atoms, it is an atom itself. Memory: 100
Image
[image]
There is also one backward compatible atom (in which a constructable can also be an atom and be made by atoms):
Zone – Detects wether player(s) are entering or leaving a specific area. This is the only backward compatible atom so far; it is backwards compatible with a trigger. You can see the recipe for a zone in the Constructables section. Memory: 30
Image
[image]
Constructables
This section is a list of all the “constructable” devices–kind of like composite numbers in math, they can be made from the atoms. This concept may be useful as there is a chance a setup using the atoms will be less memory intensive than the actual device. Just check the memory comparisons at the end of each line - the atoms’ memories have been added together for convenience. I’ll add setup and how to do it if I have time. [1]
Wire repeater → trigger Memory: 5 vs. 40
Steps
Pretty simple to recreate a wire repeater with a trigger:
- Grab a trigger. The settings should look like this:
- Wire your input device to the trigger
When something --> Trigger
- Wire your output device to the trigger
When triggered --> Something
Note that you can use the delay pulse function from the wire repeater in the trigger as well, just use the trigger delay function.
LESS MEMORY EFFICIENT
Movement meter → timer[2] + item granter Memory: 400 vs. 100
Steps
To be written
Starting Inventory → Global property + item granter Memory: 10 vs. ≥35[3]
Steps
To be written
Laser → Trigger + damager Memory: 250 or 75 vs. ≥70
Alternative: Zone + damager (Memory: 250 or 75 vs. 60)
Alt. 2: Damager + Barrier (set to no collision)[4] (Memory: 250 or 75 vs. 50 or 90 with trigger)
Steps
The following steps use the trigger recipe:
- Grab a trigger. The settings should look like this:
You can change the Allowed Team setting if you want. - Copy the trigger as many times as you need to “stretch” out the damage zone.
- Grab a damager. The settings should be like this:
The following steps use the zone recipe:
- Grab a zone. Under
When Player Enters Zone
, transmita
(or something else). - Click the change size button in the zone settings, and stretch out the zone as much as you want.
- Grab a damager. The settings should be like this:
The following steps use the barrier recipe:
To be written
Finished Product:
[image]
[gif for damaging]
MORE MEMORY EFFICIENT
Counter → Text(w/ block code) + property Memory: 25 vs. ≥570
Steps
To be written
Checker → Trigger (if-do block code) Memory: 35 vs. 540
Steps
To be written
Item Spawner → Button + Item Granter Memory: 8 vs. 85
Steps
To be written
Knockout → Knockout Manager Memory: TBD vs. 10
Steps
To be written
Flag system → Barrier, button, item granter, zone, trigger (with if-do code) Memory: 450 vs. 945
Steps
To be written
Laser Manager → Damager + Trigger Memory: 32 vs. 70
Steps
To be written
Zone → At least 3 Triggers Memory: 30 vs. ≥60
Steps
For these steps I’ll use four triggers for a teeny-tiny zone, however you can change the amount of triggers to your liking when it comes to it. Also the recipe says three or more because you can do the following steps in platformer mode on the ground some terrain using three.
- Grab ONE trigger. Set player collision to on, and visible in-game to off.
- Copy the trigger, and place it to the top left or right of it, like this:
(uh, name reveal) - Repeat step two but with the bottom right/left and right/left of the original trigger.
(Optional: make the zone look like a zone with a barrier device with collision off, will cost you 20 additional memory)
FINISHED PRODUCT
With the terrain mentioned in the intro:
Maybe a bit bigger?
WAAAAAY LESS MEMORY EFFICIENT
Lifecycle(set to Game Start
or Player Joins Late
) → Trigger + Spawn Pad Memory: 50 vs. 50
Steps
The following steps are to recreate a lifecycle with Game Start
setting:
- Grab a trigger. Make sure the player collision setting is on.
Team Allowed and visibility settings are up to you. Make sure the trigger broadcasts something to put the “lifecycle” to use. - Grab a spawn pad. Make sure the spawn pad is directly above the trigger.
Optional: instead of channels, you can always use wires. However, that will cost +10 memory per wire. If you are using wires, make sure to wire the trigger to the output device.
Finished Product:
(Um what definitely not in playing mode )
End Game → Trigger (if-do block code) Memory: 10 vs. 540
Steps
To be written
Ball Capture Zone → trigger(w/ block code) + zone Memory: 200 vs. 540
Steps
To be written
Tag Zone → trigger(w/ block code) + zone + respawn Memory: 1500 vs. 850
Steps
To be written
Relay:
- set to
All Players
→ trigger(scope global) Memory: 20 vs. 40 - set to
All Players on My Team
→ trigger(scope team) Memory: 20 vs. 40 - other options would require player count systems (will be added later when systems section is created)
Steps
To be written
Thanks to @eiqcrmeliutgwhc for the following:
Vending Machine = Button + Item Granter(s) Memory: 125 vs. ≥85
Steps
To be written
Item Spawner = Button + Item Image + Item Granter Memory: 8 vs. 85 (without image)
Steps
To be written
Repeater = Trigger Memory: 500 vs. 40[5]
Steps
To be written
In addition, I’m thinking the questioner could be a popup, but it forces the players to only answer from one question set.
This guide is honestly a massive WIP, but it’s interesting and I see some potential for this subject. I will need help from you amazing sleep-deprived forumers as I am not the best with devices. Thanks for reading and now I’m gonna go play some Minecraft bye!
Credits
@ClicClac for the original research topic
@ars3nic for this research topic
Contributors:
@Boss_1s [note from ars3nic: HUGE shout-out to him for contributing so much to this guide! I appreciate it.]
@Dungeonmaster
@eiqcrmeliutgwhc
@getrithekd
@Blackjack
@Toothless
@Kingo
To-Do list
hack cough
Uh this is for me or whoever wants to edit this guide. My memory’s trash so yeah
- List devices by function
and memory usage - Tweak and refine formatting
- Check accuracy or practicality of constructables
- How-to section for constructables
- Add systems, i.e Player I/O or Turing Machines
- Figuring out which of the 41 constructables are
impossibleimpractical to be built with atoms (post #46)
Note: some constructables have
zone
as an atom, this is the actual zone device, even though the zone itself is backwards compatible with a trigger (see posts #64~#67) ↩︎counter + trigger ↩︎
A definitive value cannot be determined as there are multiple other devices that can be used to do the Global Property and activate the item granters. Hence I’ll do the minimum of 35 ↩︎
+ Trigger (possibly) ↩︎
This is why we don’t use repeaters…sigh ↩︎