Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
Report this post
In Math? XD
Whats the biggest Euler Totient which you can calcuate? :)
Do you know what they changed to make it easier?
Originally you had to move the robot towards the closest location to harvest. In the new version (kelp robot) you need to move it towards the oldest location instead. It's actually slighter harder in some other ways, but overall it's easier because you don't need to cram as many components onto the board!
Whats up? Show me your Euler Totient. You have challenged me, so show me what you can do. Easier question? Calculate the Earthrotation Vector and call me exactly how long a Year on Earth is. 365,2524 is wrong same like 366. Show me the Equation. :)
Tip: The Maya's & Egypts has allready known the right equation.
One Week = 7,7966252560984031737018592552236 Days
Half-Day = 11,575521079380826404635928445453 Hours
Easier question: Take your petty "I'm so smart" to PM?
The Easiest question: Are you a ♥♥♥♥ Sapien Sapien or a ♥♥♥♥ Errectus? Its so uninteresting to know how long a Year really is. How fast Earth moves everyday. How much Energy is needed. How long it needs to get the right amount of Energy. So why you dont know how long a year or a second really is? Did you never ask yourself why calculating Time is such a Problem? I guess no, because the most individual Lifeforms on this Planet didnt understand what the job is if your are born as ♥♥♥♥ Sapien Sapien. Also without those answers is human not able to build computers. ;)
Good, then go build computers instead of trying to boost your ego here.
I just answered to this:
Dont need to boost my ego. I try to boost just the knowledge of apes so they have the chance to become a Human.
I came across the same thing but way sooner than you and that is with the laser tag thing. I'e managed to dope out that my alive signal will be the mainline of the logic...it's used as part of the evaluation when the trigger was pulled (right side) and the respawn and hit evaluation on the left side so the core "slp" chip will be in the middle of the board, with "slx" conditioned processors doing the rest of the work.
I suggested making the board larger or the components smaller. Perhaps that could be used as a difficulty setting? Easy setting would be a very large board while making the game harder means making the real estate smaller?
I'm glad I'm not the only one seeing the space issue as a "Huh?" thing. For a moment I thought it was just me.
Note that these are only hints, so you can get some help on the way:
Controller:
Use a MC4000 and a DX300 to read the button and convert them to a 0-4 value. Then its as easy as forwarding everything verbatim with a MC6000 (MC6000 required due to the sheer amount of pins required)
Laser tag:
Use 2 MC4000 + 2 DX300. One of them just toggle the alive signal on and off. Then use the other to read the alive signal and decide if fire is allowed or not. The alive signal is thus connected to both the alive output and second MC4000.
Vape pen:
Use one MC4000, and one MC6000 as core. The rest is a piece of cake. The MC4000 is just to convert XBUS into one pin of the diode, as you only have 2 analog outputs on the MC6000.
Mining robot:
Notice that the power levels are added where they overlap? Use 3 MC4000 and then let one handle x, one y, and then one that just adds the 2 power values together over XBUS.
Coin bell machine:
Convert the coin mechanism to XBUS using a MC4000 + DX300, that just sends the coin values over XBUS to the MC6000. As you have to be able to dispense change while the bell is ringing, use a MC4000 to convert XBUS into a bell signal. The rest is just 2 MC6000, one for handling the payment and one to handle the change.
Sandwich machine:
use a PGA33X6 to do a binary 2-to-3 one-at-a-time converter. Then use a DX300, that will now map to 4 outputs via the PGA33X6, one MC6000 and one MC4000 to make it. Here a MC4000 is required for code size, just use XBUS to tell the MC4000 to start, when the MC6000 reached the end of code.
Carbine illuminator.
Use a MC4000 as a radar controller. Then a MC6000 that just receives raw distance values over XBUS and does the hard work. A DX300 for the flood light saves on pins.
Random doll:
Use 2 ROMs and 2 MC4000, to create a 2-page adressable ROM. Use a MC6000 for the core logic. Remember that you need to send the adress value 2 times as one of the MC4000 will "eat up" the XBUS value.
Plant watering robot:
Have one core logic - MC6000, that sends desired position over XBUS. Then a position controller, MC6000, and then a motor controller, MC4000. The motor controller just receives 1 or -1 over XBUS and pulses the motor accordingly. Note that you need a XBUS feedback between the two MC6000 to tell the MC6000 when it can use its tools.
Fail-safe radio switch:
Use 2 MC6000 and a DX300. One that just reads the radio signals, and sends commands, inclusive a "turn off all" command, when time is out. Another that keeps track of which devices are on and off (using the dst command), and sends commands accordingly.
Electricity meter router:
Use 2 MC6000 and one MC4000. One MC6000 reads the header, and will decide where the packet should go, the MC4000 just forwards the rest of packet, and then a MC6000 that assembles the packet and sends it out. TIP: It doesn't matter if you send garbage out of the high-in, meter-in and low-in ports, so just wire them in parallel.
Chinese oracle thing:
Use 2 MC6000 and 2 DX300. each pair is controlling one half of display each.
Scale:
Use 2 MC6000, one that handles the weight and tare function, and sends the tar:ed value over XBUS. The other one handles on/off and showing weight on display. Code size in the first MC6000 makes it enough for a MC4000, but you need 2 registers, one for permanent storage of the tare value and one in acc to do subtraction.
Cryptocurrency ATM:
Use 3 MC6000's, a DX300 and one RAM. The first MC6000 reads the card reader, then depoists the card number in RAM. Then pulls a simple pin high, to tell the second MC6000 to start counting bills. This pin is pulled low when card is ejected. The second MC6000 just adds bills into acc and then sends the total bill value over XBUS to the third MC6000 when the pin is pulled low. The third MC6000 reads the RAM (from the other adress/data pair, the bill counter does NOT need to know the card number!) , sends it verbatim over network, and then sends the sum received from the second MC6000.
Pollution sensing window:
For the window, its enough to have two MC4000, a RAM and a NOT gate. The first MC4000 which constantly write into a RAM, beginning from the top when its full. The second MC4000 constantly reads from the RAM, summing the values, which may not be above or equal to 400. and then controls the window. A NOT gate is logic here to avoid having to init the chip with a high value as the chip is already full, and the signal should be low to close, and window should be default open.
Traffic light:
use 1 MC4000, one MC4000X, one DX300 and 2 MC6000. The MC4000X functions as a adressable phase-setting ROM, so you query it over XBUS by sending the phase ID (0-3) and get the phase length back. All the phase dials are connected to this. The second MC4000 keeps track of which phase the light is in. And then one MC6000 that does the core logic, and one MC6000 that just translates 0-3 into the respective phases, and 4 into "all off".
Meat 3d printer:
Use one MC6000, one ROM, one DX300 and one MC4000. The MC6000 acts as a core logic, decoding the keypad, and then just sends the print over XBUS to the MC4000. The MC4000 just forwards the values to the DX300 and keeps track on how long the extruder should be on. The bacon print can be hardcoded without a ROM.
Door lock:
Use 2 MC6000, 1 AND, one MC4000, and one RAM., the first MC6000 that will learn the card into the RAM, then the second MC6000 that will grant the access if a customer card is swiped, and the MC4000 will accept staff cards. The AND allows you to use a ON pin that is switched off upon a incorrect card digit, to evaluate access. Then you always pulse the lock pin. If the card number match (the ON pin was not turned off), access will be given.
Ocean monitoring system:
Use 2 MC6000, 2 RAM, and 3 MC4000X. The MC6000's pair with the RAMs to read sensor values and populate RAM, rolling RAM backwards. Then connect the MC4000Xs to the RAMs. When receiving some data over XBUS, have them dump the RAM content over another XBUS output. Connect both XBUS outputs of these to the transmitter. Then have a receiving MC4000X, which compares the ID, and if right, sends some garbage either to the MC4000X attached to the sonar RAM, or the MC4000X attached to the magnetic RAM, depending on sensor ID. Note that the MC4000X comparing the ID does *NOT* need to be involved in the transmit path.
Spoiler-blocking headphones:
use one MC4000 that will act as a latching "audio switch", one MC6000 that will do the core logic, and one ROM. And also a DX300 to convert the override button to XBUS, as you will have no analog pins on the MC4000 left.
The rest I have not managed to complete.
Hope this points in a good direction.
That's pretty impressing actually.
Wow.
And did you look into programming after that? I'm sure you would enjoy it.
Also, the lack of a swp instruction is silly, though so far I haven't really needed it. Even so, that doesn't mean it shouldn't be there. It's omition limits what you can do with the game, making it less powerful and thus lowering its value. Another example is the fact that bridges can't be rotated to be horizontal, which is just plain dumb. There should also be a bridge variant that can cross 2 wires instead of just one. Maybe there is one I haven't unlocked yet, but I don't know.
Being a game designer first and foremost is about considering how every aspect of your design will affect players, something many designers don't do very well... It's about building an experience for players with as few unnecessary limitations as possible. I personally dislike limitations because it decreases what players can do with the game, which is bad. You don't have to sacrifice like this by making the game less powerful for the sake of difficulty (which by the way is not required to have an awesome game anyway).
Furthermore, this shrinks the game's overall lifespan. Look at the great sandbox games like Minecraft. Why has that game lasted so long? Because its so open-ended. Shenzhen does have a sandbox mode, but that is still pretty limited by the board size. Most people's computers can handle more than that quite easily. Even though Minecraft is years old, its redstone mechanics still blow Shenzhen out of the water in terms of how powerful they are.
The problem is that Shenzhen nerfs the heck out of itself with limited board space in the sandbox, which is very questionable design considering it certainly makes no sense. Nor does the notes component, which wastes space on your board... It may have been smarter to have a notepad tab you could open to type notes into or something. The limited board space makes the notes component next to useless... There is so much more you could do with this game. For example, besides supporting larger boards, you could make it possible to have multiple circuit boards and connect them together. You could also simply add scrollbars to that screen to support the larger space needed for that.
You'd still have limitations possibly, but its workable. Or you could let the player create as much as they want until they're computer slows down. lol. That would probably be the better approach as it gives more power to the player if their PC has fast enough hardware to do what they're trying to do. You could also mediate that a bit by making use of multithreading, perhaps one thread for each board and limit the number of boards you could have or something like that. So there are definitely interesting possibilities that this game has totally missed.
It just makes no sense when developers neuter their own game. Another example is MHRD, which currently has a very dumb limitation in it. Basically you create hardware components using a simple hardware description language to eventually build a CPU. The painfully dumb limitiation is that you can't create your own custom designs using your components... MHRD is still being updated so hopefully that is planned and just hasn't made it in yet, because there's no way you could actually not think of a feature that obvious lol.