PC Play Tic Tac Toe in Terraria!

[Tub]

Hello,

so I went a little overboard with the new mechanisms. I'm now a few dozen platinum coins poorer, two of my female NPCs closed shop and went to Vegas, and here's my new room. All hand-crafted within the game, no mods or TEdit.


How does it look?
(warning: 550kB gif animation)

I have no friends why did I even build this...


What does it do?
Players take turns pushing a switch on their little switchboard to signify a move. If the move is valid, the corresponding field in the big display lights up as X or O. Invalid moves are ignored.

When a winning move is played the winner is announced in the chat, and a few torches light up.

The big switch in the middle resets the board to start a new game.


What does it not do?
Currently, it does not stop the game after someone won. I tried hooking something up, but for some reason that created puffy smoke and didn't work. I need to investigate further.

Also, the winner's torches are not epic enough. I considered sparklers, but they cannot be toggled off when the next game starts. I briefly considered pelting the loser with flame traps, but that's not really something I want to build in my home. I'm only playing against myself. Why would I set fire to myself...
Then I considered a win-counter, but there's not enough room left to wire up a proper display.
Ideas are welcome!


What do I need to build one?
166 AND Gates
2 OR Gates
216 Lamps
74 Faulty Lamps
12 Junction Boxes
and a few thousand wires.


And where do I need to put all these things?
I'll try to write up a proper guide as time permits. Due to space constraints, I have overlapping wires and inconsistent wire colors all over the place. I doubt it's readable without annotations..
But here's a wiring screenshot anyway. Do not try to debug this.


Can I download the world somewhere?
I built this in my home world, which I don't want to share. Though if you ask nicely, I might install TEdit and try to copy/paste it into a new world.


Enjoy,
Tub


No seriously I'm all alone down here why won't someone play with me. I bet Sally and Ada would love to see this when they're back from Vegas. I guess I'll just sit in this corner and wait...

 

[Niranufoti]

For the "stopping the game after a player won" thing, I'd recommend transistors (I know, I recommend those for everything) - you could hook the victory torch wires together with an OR gate and connect that gate's output to the bases of 18 transistors (one for each of the 2x3x3 input switches). When a player flicks a switch to place their X or O in a field, that signal would have to pass through one of those transistors first, and when a player has currently won, they'd be inactive, allowing no farther moves.

Also - those wire colors look pretty consistent to me.

 

[Statue of Libroty]

Nice! I was trying to do something like this earlier, but gave up when I couldn't figure out the display. Lemme work through the image, here...

I really like the reset mechanism you used -- looks like you keep track of what tiles have been played by whom with faulty logic gates, and use that (and the wires to the display) to clear everything. The using green for both player one and the reset mechanism, but yellow for player two -- I wouldn't call that inconsistent wire colour, to be honest. The red and blue that goes to the win condition checker is more important, and having P1 and P2 grouped up and reset on the side is perfectly logical.

The win condition tracker is kind of neat, too. Hardcoded the 8 different win conditions for both players, just ANDing three tiles in a line to see if any player has won yet. It looks like it should be possible to announce if there's a tie, too! Would be pretty simple to add, I bet.

The turn tracker is also pretty cool. Just a bunch of diodes that sends a signal to another diode, which sends the signals to a bunch of faulty logic gates in turn. I enjoy how there's two lamps on the AND gate so you can keep your wire colour consistency

As for how to resolve the smoke -- I've been working on figuring out how gates work with time in game (simultaneous signals and stuff), and smoke tends to appear when there's an issue with synchronous stuff. I've figured out that there's sometimes a need for a "delay" gate if there's too many chained gates.

Here's a good delay gate:

All it does is take a yellow wire input and give a yellow wire output. Really, all that matters is that the signal passes through a gate -- you can use an AND gate diode as a delay gate.

Put a few delay gates (no more than four) on the yellow turn tracker wire before it reaches the turn tracker at the bottom, then hook up the red and blue victory wires to the turn tracker. Have the reset wire travel down to turn one of the players' turns back on so people can play when a new game starts.

I tested this out with a small mockup (not a full copy of your build, just a few relevant wires and gates), and it seemed to work fine.
[doublepost=1464207749,1464207529][/doublepost]

For the "stopping the game after a player won" thing, I'd recommend transistors (I know, I recommend those for everything) - you could hook the victory torch wires together with an OR gate and connect that gate's output to the bases of 18 transistors (one for each of the 2x3x3 input switches). When a player flicks a switch to place their X or O in a field, that signal would have to pass through one of those transistors first, and when a player has currently won, they'd be inactive, allowing no farther moves.

Also - those wire colors look pretty consistent to me.

Evidently it took me a while to post that. It looks like Tub is already using transistors to make sure players only play on their turn, and tried to do exactly what you said (as the dangling wires just below the reset lever show).

 

[Sonnette]

Instead of torches for the winner, you could surround the players in painted lamps and whichever player wins' lamps light up.

Coming up with alternate uses for things ftw!

 

[Statue of Libroty]

Well, evidently the problem is a lot harder than I thought.

So, if you don't mind smoke, you don't need a delay gate here -- just connect the red victory wire to the blue turn thingy, do something funky with the reset wire, and everything works out fine.

But if you really want to get rid of the smoke, it's a lot more difficult. Every gate in a chain seems to do its computation in the same tick (or, at least, take the same number of ticks to get to the result). In order to get rid of smoke, every signal that ends up at the same gate that originated from the same tick must pass through the same number of gates before arriving. Since the signal to the turn tracker diverges into two different gate chains as soon as it hits the win checker, and the win checker has a variable number of gates (between two and four), I'm afraid I have no idea how to resolve this besides using an actual delay, like a dart trap directly into a pressure plate.

 

[Tub]

For the "stopping the game after a player won" thing, I'd recommend transistors (I know, I recommend those for everything)

Oh, I know about transistors, there are 74 transistors right there in the screenshot. They're awesome and should be recommended for everything they can be used for.
That specific instance needs AND logic though.
[red player can move] = [it's red player's turn] AND NOT [blue has won]

The problem seems to be that in a single move, both inputs change - blue has won, and the turn moves from blue to red. This causes the AND to emit smoke.

you could hook the victory torch wires together with an OR gate and connect that gate's output to the bases of 18 transistors (one for each of the 2x3x3 input switches).

Yeah, I already have one such transistor row below each switchboard. It works fine to disable playing out of turn, but as soon as I try to AND turn order and winning conditions, I get smoke.
I could add a second row of transistors and check turn order and winning conditions separately, but that would require re-wiring the whole cellar. As I refuse to use TEdit, I'm going to investigate some alternatives before making drastic changes. But those are tasks for another day.

The using green for both player one and the reset mechanism, but yellow for player two -- I wouldn't call that inconsistent wire colour, to be honest. The red and blue that goes to the win condition checker is more important, and having P1 and P2 grouped up and reset on the side is perfectly logical.

My initial plan was to use red for player 1, blue for player 2 and yellow for reset. I also did not intend for those horizontal red/blue wires in the upper left; that information was supposed to go down to the center display, then further down back into the logic circuits. But I soon realized that keeping red/blue/yellow would have made everything a lot bigger, and I had already painted myself in a corner by putting the center X/Os too close to each other. Also, manually digging, draining and walling huge caves is tedious.
It's a shame though, it would have been a lot easier to explain and understand what I'm doing there.

The win condition tracker is kind of neat, too. Hardcoded the 8 different win conditions for both players, just ANDing three tiles in a line to see if any player has won yet. It looks like it should be possible to announce if there's a tie, too! Would be pretty simple to add, I bet.

The easiest logic would be [9 turns were made] AND NOT [Red has won] AND NOT [Blue has won]. Tracking if 9 turns were made seems non-trivial though. A simple column like for the win conditions does not work when checking for either the blue or red line. I'd need 9 OR gates, all connected to a AND gate, and that needs space.
I could also build a turn counter, but AFAIK those things are difficult to reset. I'll need to research those.

The turn tracker is also pretty cool. Just a bunch of diodes that sends a signal to another diode, which sends the signals to a bunch of faulty logic gates in turn. I enjoy how there's two lamps on the AND gate so you can keep your wire colour consistency

Oh, you can just remove those two AND gates and connect all three yellow wires. It'll work. The colors are consistent because those were a single wire once.
The AND gates were meant to AND the winning conditions (using the two dangling red/blue wires nearby). But as said, if you connect them, you get smoke and then you need to cut wires, insert switches, and manually reset the whole turn order logic.

I'm going to try your suggestion about delays though. Maybe it only smokes if the second input arrives after the AND has already fired, and I simply need to sync up both inputs to arrive roughly at the same time. We'll see. The signal paths for the winning conditions travel through one, two or three gates before arriving at the OR gates though, so a perfect sync won't be possible.

/edit: ah, you already checked. Thank you. I don't want to use dart traps (they make noises!), so I'll have to find another solution.

 

[Statue of Libroty]

Also, manually digging, draining and walling huge caves is tedious.

I recently had to clear an arena for Plantera on my main world. Sticky bombs are a godsend, but it's still a pain.

The easiest logic would be [9 turns were made] AND NOT [Red has won] AND NOT [Blue has won]. Tracking if 9 turns were made seems non-trivial though. A simple column like for the win conditions does not work when checking for either the blue or red line. I'd need 9 OR gates, all connected to a AND gate, and that needs space.
I could also build a turn counter, but AFAIK those things are difficult to reset. I'll need to research those.

I believe the easiest logic would be [All tiles are occupied] AND NOT [Red has won] AND NOT [Blue has won], since you've already made sure that each tile can be played once. The difficulty would be the "AND NOT" part, since gate chains don't behave nicely with time. There may be further smoke in your future if you decide to do it!

Oh, you can just remove those two AND gates and connect all three yellow wires. It'll work. The colors are consistent because those were a single wire once.
The AND gates were meant to AND the winning conditions (using the two dangling red/blue wires nearby). But as said, if you connect them, you get smoke and then you need to cut wires, insert switches, and manually reset the whole turn order logic.

I'm going to try your suggestion about delays though. Maybe it only smokes if the second input arrives after the AND has already fired, and I simply need to sync up both inputs to arrive roughly at the same time. We'll see. The signal paths for the winning conditions travel through one, two or three gates before arriving at the OR gates though, so a perfect sync won't be possible.

/edit: ah, you already checked. Thank you. I don't want to use dart traps (they make noises!), so I'll have to find another solution.

Yeah, smoke is a real pain. There might be a way, if you can somehow wire the horizontal red and blue wires to go through the same number of gates before hitting the diodes on the left, but that would require considerably more space, and probably look ridiculously messy.

 

[Bahamut2001]

Would this work as a stop when the game was won?
Or am I just showing you something you've already tried?

 

[Tub]

I haven't disassembled the game code, but after a few more tests, the golden rule seems to be:
A gate may only emit a single signat per game tick. Instead of a second signal, it emits smoke.

This is true for all kind of gates, including transistors and diodes. You've read that right: you cannot even add a diode to a wire that shall carry multiple signals in a single game tick.

/edit: this was meanwhile confirmed by NiraExecuto in a new thread.


In my case, the smoke happens on the blue AND gate when red wins (and vice versa). First, the turn moves to blue, causing blue's AND gate to turn to TRUE, then the game logic detects that red has won, turning the AND gate back OFF again. Poof, smoke.

Using some additional diodes in the leftmost yellow wire, I ensured that the victory logic triggers first (the AND gate stays OFF), then the turn switches (the AND gate still stays OFF), thus no smoke.
However, I then used the reset lever and poof! More smoke. Resetting toggles every single marked square, toggling turn order once for each marked square. Because of that, there is no way I can add anything but transistor lamps at the end of that yellow wire. No lamps connected to proper gates, no faulty lamps, no diodes, nothing. Even the diodes meant for delay will start to smoke.

This all turns out to be a lot more complicated than I anticipated. I have one more idea, but that's complicated. Maybe I'll find time on the weekend.

Would this work as a stop when the game was won?

Thanks for the suggestion, but that is subject to the same smoke rules. I'm sure it works fine with manual button pushing, but it'll start smoking when multiple signals per game tick appear.

 

[ZeroGravitas]

And where do I need to put all these things?

Laughed so hard, lol!

warning: 550kB gif animation

I'd not worry tooo much about Gif size (the logo letters at the top of the main page add up to about 5MB!). You could upload to Gfycat and have an embed (with playback controls) that's compressed video format too.

No seriously I'm all alone down here why won't someone play with me.

Heh, difficult. I hope circuits of this level of complexity work in multiplayer... If not, maybe you'll just have to program your own AI opponent.

Anyway. Brilliant build, very entertaining showcase, and good job stimulating discussion into logic gate mechanics, getting everyone figuring out solutions.

A gate may only emit a single signat per game tick. [...] confirmed by NiraExecuto in a new thread.

Just for reference: http://forums.terraria.org/index.php?threads/order-of-operations-smoke-and-how-to-prevent-it.44020/

 

[Tub]

So I decided to go the "simple" route and add a second line of transistors to the bottom, moving all those crossing wires three tiles down. The upper row still checks whose turn it is, while the lower row checks if the game is not yet decided. When someone has won, no more moves can be made, but the next player's pedestral still lights up. Can't be helped though.

Heh, difficult. I hope circuits of this level of complexity work in multiplayer...

Actually, I lied. I do have one friend, who I bought terraria with. We just played a few games together, and everything seems to work just fine. At least on a LAN, I didn't test high-latency connections. Still, I'd assume any wiring to be handled server-side in a deterministic way, so it shouldn't break.

Now all important features are done, I'm happy with the results, there's nothing more to add, the project is finished.

If not, maybe you'll just have to program your own AI opponent.

What... you... I... damn. You are evil, you know that?

That being said, I don't think it'd be particularly interesting.

I can just hook up a timer through some randomized faulty gates, essentially randomly pushing the blue player's nine buttons. As invalid moves are ignored, random button mashing will work just fine to simulate a a low-skilled opponent. I can add a little skill by giving center and corners higher chances to be pushed.

Or I could do something similar to the existing victory-logic to determine the next move based on a lookup table. That would lead to a lot of wires, but none of them would be really interesting or show any new concepts or insights. The opponent would have perfect play, but be perfectly deterministic. In other words: boring.

No. Nice bait, but I'm not going there


All that's left is some cleanup, more screenshots and a few explanations. I hope to find enough time tomorrow.

 

[Niranufoti]

Now all important features are done, I'm happy with the results, there's nothing more to add, the project is finished.

there's nothing more to add, the project is finished.

nothing more to add

Bull. Make it as compact as possible. Trim all unnecessary whitespace. Ignore complaints from anyone who can't handle the logic. If those peasants can't understand your wiring, they don't deserve to.
Bonus points if it occasionally smokes without causing any problems.
(pleasefallforitpleasefallforitpleasefallforit)